答案是通过cadvisor和node exporter采集docker宿主机及容器指标，再由prometheus抓取并经grafana可视化，实现零侵入、生产可用的容器引擎健康度监控。
要让 Docker 守护进程的节点监控指标无缝对接 Prometheus，并最终呈现为容器引擎健康度的图形化看板，关键不在“修改 Docker 守护进程本身”，而在于用标准组件采集其暴露的底层指标——Docker 本身不直接提供 Prometheus 格式的 HTTP metrics 接口，但它的运行环境（Linux 主机 + 容器运行时）天然支持通过 cAdvisor 和 Node Exporter 获取完整、准确的节点与容器级指标。
整个链路清晰、稳定、生产可用，无需侵入 Docker 配置或编译源码。
✅ 1. 确保 Docker 主机暴露必要系统指标
Docker 守护进程运行在宿主机上，它对 CPU、内存、磁盘、网络、进程、cgroup 的使用，全部反映在 /proc、/sys 和容器运行时（如 runc）的 cgroup 文件中。
你不需要开启 Docker 的 experimental metrics 功能（已废弃且不稳定），而是依赖 cAdvisor 直接解析这些路径。
- ✅ 确认 Docker 正常运行：
systemctl is-active docker→active - ✅ 确认 cgroups v2 兼容性（推荐）：
stat -fc %T /sys/fs/cgroup→ 应返回cgroup2fs或cgroupfs - ✅ 不需修改
/etc/docker/daemon.json—— 默认配置已足够支撑 cAdvisor 采集
✅ 2. 部署 cAdvisor：专为容器设计的实时指标代理
cAdvisor 是 Google 开发、CNCF 托管的开源工具，原生支持 Docker、containerd，自动发现所有容器并暴露 Prometheus 格式指标（如 container_cpu_usage_seconds_total、container_memory_usage_bytes）。
启动方式（推荐 host network 模式，避免端口映射干扰）：
docker run -d \ --name=cadvisor \ --privileged \ --network=host \ -v /:/rootfs:ro \ -v /var/run:/var/run:ro \ -v /sys:/sys:ro \ -v /var/lib/docker:/var/lib/docker:ro \ -v /dev/disk/:/dev/disk:ro \ gcr.io/cadvisor/cadvisor:v0.47.0
✅ 验证：访问 http://<host-ip>:8080/metrics</host-ip>，应看到大量以 container_ 和 machine_ 开头的指标（如 container_cpu_system_seconds_total）
⚠️ 注意：不要用 --port 参数绑定到非 8080 端口再映射——--network=host 下直接监听 localhost:8080 更可靠
✅ 3. 部署 Node Exporter：补全宿主机维度指标
Docker 守护进程本身是宿主机上的一个进程，它的健康度离不开 OS 层支撑：
-
dockerd进程 CPU/内存占用 - Docker 存储驱动（overlay2）目录 inode 和磁盘使用
- 内核参数（如
net.netfilter.nf_conntrack_count） - systemd 服务状态（
node_systemd_unit_state{unit="docker.service"}）
部署 Node Exporter（同样推荐 host network）：
docker run -d \ --name=node-exporter \ --network=host \ --pid=host \ --user=root \ -v "/proc:/proc:ro" \ -v "/sys:/sys:ro" \ -v "/:/rootfs:ro" \ -v "/etc/localtime:/etc/localtime:ro" \ prom/node-exporter:v1.6.1 \ --path.procfs=/proc \ --path.sysfs=/sys \ --collector.systemd \ --collector.filesystem.ignored-mount-points="^/(sys|proc|dev|host|etc)($|/)"
✅ 验证：curl http://localhost:9100/metrics | grep docker → 应出现 node_systemd_unit_state{unit="docker.service",state="active"} 等指标
✅ 4. 配置 Prometheus 抓取这两类指标
编辑 prometheus.yml，添加两个 job：
global:
scrape_interval: 15s
scrape_configs:
- job_name: 'cadvisor'
static_configs:
- targets: ['localhost:8080'] # cAdvisor 在 host network 下即 localhost:8080
- job_name: 'node'
static_configs:
- targets: ['localhost:9100'] # Node Exporter 同理
✅ 启动 Prometheus 后，在 Web UI（http://<prom-ip>:9090/targets</prom-ip>）确认两个 target 状态为 UP
✅ 查询示例：
-
rate(container_cpu_usage_seconds_total{name=~".+"}[5m])→ 各容器 CPU 使用率 -
node_systemd_unit_state{unit="docker.service"} == 1→ Docker 服务是否 active -
container_memory_usage_bytes{id="/"} / 1024 / 1024→ Docker daemon 自身内存（根 cgroup）
✅ 5. Grafana 看板：聚焦“容器引擎健康度”
导入社区成熟看板（ID 14347 或 893），或自建面板，重点关注以下维度：
Docker 服务稳定性
node_systemd_unit_state{unit="docker.service"} == 1（绿色正常 / 红色异常）守护进程资源压力
process_resident_memory_bytes{job="node", process="dockerd"} / 1024 / 1024（MB）process_cpu_seconds_total{job="node", process="dockerd"}（增长率）容器运行时健康信号
count by (state) (container_last_seen{image!=""})→ Running / Exited / Paused 容器数量分布sum(rate(container_start_time_seconds_total[1h]))→ 每小时容器启动频次（突增可能意味异常重启）底层资源瓶颈
node_filesystem_avail_bytes{mountpoint="/var/lib/docker"} / node_filesystem_size_bytes{mountpoint="/var/lib/docker"} * 100→ Docker 存储空间余量node_cpu_seconds_total{mode="iowait"} / 100→ I/O 等待占比（过高说明磁盘或 overlay2 层卡顿）cgroup 异常信号
container_cpu_cfs_throttled_seconds_total{name=~".+"}→ CPU 节流时间（持续增长说明 CPU limit 设置过严或争抢严重）container_memory_failures_total{scope="container", type="pgmajfault"}→ 内存缺页失败次数（OOM 前兆）
不复杂但容易忽略：真正体现“容器引擎健康度”的，不是单个业务容器的 CPU%，而是 dockerd 进程自身稳定性、存储目录可用性、cgroup 统计一致性、以及容器启停成功率。这套组合（cAdvisor + Node Exporter + Prometheus + Grafana）正是为此而生，零侵入、开箱即用、指标语义清晰。
