当你的 Docker 容器从几个扩展到几十个，容器监控工具的选择就直接决定了排障效率。很多团队在容器化初期只关注部署，直到线上出现 CPU 飙升或内存泄漏，才发现对容器内部状态几乎一无所知。本文不罗列工具清单，而是从实际运维问题出发，讲清楚监控什么、怎么采集、以及不同方案之间的取舍。
先回答：Docker 监控到底要看哪些指标？
Docker 本身通过 docker stats 命令能提供 CPU、内存、网络 I/O 和磁盘 I/O 的实时数据，但这些数据是瞬时的，无法反映趋势。生产环境需要的是历史数据和告警能力。通常我们需要两类指标：
- 资源使用指标：CPU 使用率、内存使用量、磁盘读写、网络收发——这些决定容器是否健康运行。
- 应用性能指标：请求延迟、错误率、吞吐量——这些决定业务是否正常。
前者依赖 Docker 的 cgroup 统计，后者则需要从应用内部暴露。一个完整的监控体系必须同时覆盖两者。
Prometheus：最流行的指标采集与存储方案
Prometheus 是一个开源系统监控和告警工具包，最初由 SoundCloud 开发，现在已加入 CNCF。它的核心是拉取模型：Prometheus 定期从目标端点抓取指标，并以时间序列数据存储，每条数据附带时间戳和标签（key-value 对）。这种设计非常适合容器环境，因为容器 IP 会频繁变化，Prometheus 通过服务发现机制动态获取目标。
采集容器指标：cAdvisor 与 node-exporter
要采集 Docker 容器的资源指标，最常用的方式是部署 cAdvisor（Google 开源）或直接使用 Prometheus 的 Docker 插件。cAdvisor 会暴露每个容器的 CPU、内存、网络等指标，并自动发现宿主机上的所有容器。配置上，只需在 Prometheus 的 scrape_configs 中添加 cAdvisor 的端点即可：
scrape_configs:
- job_name: 'cadvisor'
static_configs:
- targets: ['cadvisor:8080']这里需要注意的是，cAdvisor 本身也是一个容器，它需要挂载宿主机的一些目录才能获取真实数据，比如 /var/run/docker.sock 和 /sys。如果权限配置不当，可能采集不到数据或采集到错误数据。
Prometheus 的局限与取舍
Prometheus 非常强大，但它也有自己的适用范围。它是拉取模型，意味着所有目标必须能被网络访问；对于短生命周期任务（如批处理容器），可能来不及采集。另外，Prometheus 是单机存储，虽然支持联邦和远程存储，但大规模场景下需要额外方案。如果你的监控需求只是基础资源，Prometheus + Grafana 已经足够；如果需要追踪和日志，则需要引入其他工具。
OpenTelemetry：统一指标、日志和追踪的标准
OpenTelemetry（OTel）是一个厂商中立的开源可观测性框架，用于生成、采集和导出遥测数据（包括指标、日志和追踪）。它与 Prometheus 的区别在于：OTel 更侧重于标准化，它提供统一的 API 和 SDK，让你可以在应用代码中埋点，然后通过导出器将数据发送到 Prometheus、Jaeger 或任何后端。
为什么要在 Docker 中使用 OTel？
如果只是监控容器资源，Prometheus 已经足够。但当你需要将容器指标与应用性能指标关联时，OTel 的价值就体现出来了。例如，你可以在应用代码中通过 OTel SDK 记录请求延迟，同时采集容器 CPU 使用率，然后在同一个仪表盘上对比分析。OTel 支持多种语言，并且与 Kubernetes 生态集成良好。
OTel Collector 的部署实践
在 Docker 环境中，你可以将 OTel Collector 作为容器运行，它负责接收应用发送的遥测数据，并转发到后端。一个典型的配置是：应用通过 OTLP 协议发送数据到 Collector，Collector 再导出到 Prometheus（对于指标）或 Jaeger（对于追踪）。这种方式的好处是，应用无需关心后端的具体实现，只需要遵循 OTel 标准。
监控工具选型的判断过程与常见误区
很多团队在选择容器监控工具时，容易陷入几个误区：
- 误区一：依赖 docker stats。它只能看当前状态，无法历史回溯，也无法告警。
- 误区二：指标越多越好。采集海量指标会增加存储和检索成本，实际上应该从业务目标反推所需指标。
- 误区三：忽略应用层监控。只监控容器资源，不监控应用性能，导致问题定位困难。
正确的选型思路是：先明确监控目的（故障排查、容量规划、性能优化），再确定指标集，然后选择工具。对于大多数团队，Prometheus + Grafana + cAdvisor 是性价比最高的组合；如果未来需要多集群或复杂追踪，再引入 OTel。
采集配置的实战步骤与失败条件
以 Prometheus + cAdvisor 为例，完整的采集配置包括：
- 启动 cAdvisor 容器，暴露 8080 端口。
- 在 Prometheus 配置文件中添加 scrape job。
- 验证指标是否被抓取（通过 Prometheus 的 Targets 页面）。
- 在 Grafana 中导入容器监控模板。
失败条件通常包括：网络隔离导致无法访问 cAdvisor；cAdvisor 挂载卷缺失导致数据为空；Prometheus 配置文件语法错误导致无法启动。遇到问题时，先检查日志和 Targets 状态。
总结：监控是持续演进的过程
Docker 容器监控不是一蹴而就的，需要根据业务发展不断调整。从基础的资源监控开始，逐步引入应用性能监控和分布式追踪，最终形成一个完整的可观测性体系。记住，工具只是手段，理解指标背后的业务含义才是关键。
参考资料
延伸阅读