Docker基础镜像不内置监控报警能力，监控必须在运行时通过外部可观测性组件实现；正确做法是基于标准镜像统一接入cAdvisor+Prometheus，暴露指标端口、挂载必要宿主机路径，并复用同一套告警规则。

Docker 基础镜像本身不内置监控报警能力，FROM 指令只是定义构建起点（如 FROM ubuntu:22.04 或 FROM alpine:3.19），它不参与运行时监控。真正的监控报警必须在容器运行阶段、通过外部可观测性组件实现，而非写在 Dockerfile 的 FROM 行里。

换句话说：你不能靠改 FROM xxx 来开启告警，但可以基于该镜像，在部署时统一接入标准监控体系。

---

✅ 正确做法：用标准化方式为所有基于该基础镜像的容器启用监控

只要容器按规范运行（比如暴露指标端点、不限制 cgroup 访问），无论 FROM 是什么，都能被同一套监控栈覆盖。

OpenClaw Docker Setup

在 Linux 上通过 Docker 运行 OpenClaw，并使用 Tailscale 实现远程访问。⚠️ 涉及 sudo、Docker、Tailscale和凭证挂载——请先查阅安全章节...

下载

1. 确保基础镜像支持运行时指标采集

• 使用主流发行版（Ubuntu/Alpine/Debian）即可，无需特殊定制；
• 避免极度精简镜像（如 scratch）——除非你手动注入 /metrics 接口；
• 若业务容器自身暴露 Prometheus 格式指标（如 Spring Boot Actuator、FastAPI /metrics），需在 Dockerfile 中开放对应端口：

  EXPOSE 8080  # 应用端口
  EXPOSE 8081  # metrics 端口（可选）

2. 容器启动时保留必要宿主机路径挂载（关键！）

cAdvisor 需要访问宿主机的 cgroup 和 procfs，否则无法获取真实资源数据。
启动容器时不要加 --read-only 或过度限制 --cap-drop，尤其避免屏蔽以下能力：

• --cap-add=SYS_ADMIN（cAdvisor 必需，部分安全策略要求）
• 挂载 /sys, /proc, /var/run/docker.sock（cAdvisor 依赖）
• 示例安全但可用的运行参数：

  docker run -d \
    --name myapp \
    --volume /sys:/sys:ro \
    --volume /proc:/proc:ro \
    --volume /var/run/docker.sock:/var/run/docker.sock:ro \
    -p 8080:8080 \
    myapp:latest

3. 统一由 cAdvisor + Prometheus 抓取，不依赖镜像内容

• cAdvisor 自动发现所有 Docker 容器，不论其 FROM 是什么；
• Prometheus 通过 job_name: 'cadvisor' 抓取 container_* 指标，例如：
  • container_cpu_usage_seconds_total
  • container_memory_usage_bytes
  • container_network_receive_bytes_total
• 所有容器共享同一套告警规则，比如：

  - alert: ContainerHighMemory
    expr: container_memory_usage_bytes / container_spec_memory_limit_bytes > 0.9
    for: 3m
    labels:
      severity: critical
    annotations:
      summary: "High memory usage in {{ $labels.container }}"

4. 针对无指标暴露能力的镜像，补救方案

如果基础镜像跑的是黑盒二进制（如闭源程序），且不提供 /metrics：

• 用 cAdvisor 采集容器级资源（CPU/内存/网络）已足够做基础告警；
• 配合 node-exporter 补充主机维度指标（如磁盘满、负载高）；
• 如需进程级监控，可在容器内额外运行轻量 exporter（如 process-exporter），或改用 docker stats + 脚本上报。

---

❌ 常见误解与避坑点

• 不要在 FROM 行里写监控逻辑：FROM prometheus/base-image 这类不存在的镜像纯属误导；
• 不要给每个镜像单独装 Prometheus Agent：增加维护成本，违背“外部可观测性”原则；
• 不要依赖 docker logs 做实时告警主通道：日志延迟高、结构松散，应作为辅助手段（配合 Fluentd + Elasticsearch）；
• 避免在 Dockerfile 中硬编码 Alertmanager 地址：告警配置属于部署层，应通过环境变量或配置中心注入。

---

一套配置，管住所有容器——这才是云原生监控的设计本意。