一、容器监控的必要性

每次看到生产环境里的容器像热带鱼群般游动时，总想起那些年凌晨三点被资源耗尽告警吵醒的抓狂时刻。容器化部署固然方便，但缺少监控就像开车不看仪表盘——知道会翻车却不知道何时翻车。当容器CPU突然飙高、内存开始泄露时，我们需要比docker stats更专业的工具来诊断这只"黑匣子"。

二、监控铁三角的配合原理

这套组合拳的精髓在于分工明确：cAdvisor是称职的体检医生，24小时采集容器生命体征；Prometheus像严谨的数据秘书，准时记录并归类所有体检报告；Grafana则是会讲故事的数据分析师，把这些数字变成直观的决策图谱。三者通过/metrics端点相互握手，形成完整的监控闭环。

三、cAdvisor的部署与数据采集

3.1 快速启动体检中心

使用官方的Docker镜像快速部署（技术栈：Docker 20.10）：

# 启动时绑定必要设备与端口
docker run \
  --volume=/:/rootfs:ro \
  --volume=/var/run:/var/run:ro \
  --volume=/sys:/sys:ro \
  --volume=/var/lib/docker/:/var/lib/docker:ro \
  --publish=8080:8080 \
  --detach=true \
  --name=cadvisor \
  gcr.io/cadvisor/cadvisor:v0.47.0

启动后访问http://localhost:8080/metrics会看到数十种监控指标在滚动输出，像这样：

# CPU累计使用时间（单位：秒）
container_cpu_usage_seconds_total{container_label_maintainer="NGINX Docker Maintainers"} 1856.72

# 内存工作集大小（单位：字节）
container_memory_working_set_bytes{id="/docker/nginx"} 156123136

3.2 指标数据的秘密花园

cAdvisor采集的指标远不止基础资源数据，还包括：

  • 网络IO统计：container_network_receive_bytes_total
  • 磁盘操作时延：container_fs_io_time_seconds_total
  • OOM事件计数：container_oom_events_total

查看完整指标列表：

curl -s http://localhost:8080/metrics | grep -E '^container_' | sort

四、Prometheus的配置艺术

4.1 数据管家上岗手册

创建prometheus.yml配置文件（技术栈：Prometheus 2.47）：

global:
  scrape_interval: 15s # 每15秒采集一次数据

scrape_configs:
  - job_name: "cadvisor"
    static_configs:
      - targets: ["cadvisor:8080"] # Docker容器名称解析
    metrics_path: /metrics

启动Prometheus容器并挂载配置：

docker run -d \
  -p 9090:9090 \
  -v /path/to/prometheus.yml:/etc/prometheus/prometheus.yml \
  --name=prometheus \
  prom/prometheus:v2.47.0

4.2 查询语言的魔术时刻

在Prometheus的表达式浏览器中尝试这些查询：

# 查询最近5分钟CPU使用率超过80%的容器
sum(rate(container_cpu_usage_seconds_total[5m])) by (container_name) * 100 > 80

# 展示内存使用前五名的容器
topk(5, container_memory_working_set_bytes{image!=""})

进阶预警规则示例：

groups:
- name: container-alert
  rules:
  - alert: HighMemoryUsage
    expr: container_memory_working_set_bytes{container!="POD"} / container_spec_memory_limit_bytes > 0.8
    for: 5m
    labels:
      severity: critical
    annotations:
      summary: "{{ $labels.container }}内存使用超过80%"

五、Grafana的仪表盘魔术

5.1 数据可视化流水线

启动Grafana容器（技术栈：Grafana 10.1）：

docker run -d \
  -p 3000:3000 \
  --name=grafana \
  grafana/grafana:10.1.0

配置数据源的JSON模板：

{
  "name": "Prometheus",
  "type": "prometheus",
  "url": "http://prometheus:9090",
  "access": "proxy",
  "basicAuth": false
}

5.2 搭建专业级监控面板

推荐导入这些现成模板：

  • 容器资源总览：ID 193
  • Docker服务监控：ID 12595
  • 节点资源大盘：ID 1860

自定义内存面板的PromQL示例：

sum(container_memory_working_set_bytes{container_label_com_docker_swarm_service_name=~"$service"}) by (container_label_com_docker_swarm_service_name)

六、实战应用全景图

6.1 典型应用场景

  1. 微服务资源争夺战：定位占用CPU的"元凶容器"
  2. 内存泄漏跟踪：通过RSS内存曲线识别泄露进程
  3. 网络带宽分析：识别异常流量的容器实例
  4. 存储性能优化：分析容器磁盘IO模式

6.2 优劣对比分析

方案优势：

  • 细粒度监控：精确到每个容器的资源足迹
  • 实时预警：秒级响应异常波动
  • 历史回溯：最长可保存数年监控数据
  • 零侵入性：无需修改应用代码

现存挑战：

  • 资源开销：每个节点约多消耗5%资源
  • 配置复杂度：涉及多个组件的协同
  • 存储压力：历史数据存储成本随规模增长

七、避坑指南与进阶路线

7.1 必须绕开的深坑

  • 时间序列爆炸：当单个job出现300+metrics时，需拆分采集任务
  • Docker API版本：新版cAdvisor可能不兼容旧Docker守护进程
  • 数据保留策略：推荐采用TSDB分片存储，按不同保留周期配置

优化后的Prometheus配置示例：

remote_write:
  - url: "http://thanos-receive:19291/api/v1/receive"
    queue_config:
      max_samples_per_send: 5000
      capacity: 10000

7.2 性能调优秘籍

当监控100+节点时建议：

  1. 设置采集间隔分级：关键指标15s，普通指标1m
  2. 启用Prometheus分片：按环境/地域划分采集范围
  3. Grafana面板异步渲染：设置"live → 5s"刷新间隔

八、通向未来的监控之路

这套监控体系的扩展潜力远比想象中更大。当需要监控K8s集群时，只需添加kube-state-metrics组件；要跟踪应用性能时，接入Jaeger等APM工具即可。未来的服务网格监控可以在此基础上添加Istio Mixer的指标采集，构建全栈可观测性。