Docker 容器监控实战指南

容器监控从基础到体系:docker stats 实时资源、健康检查配置、日志采集分析,再到集中化指标/日志/告警平台搭建。规模化容器的可见性方案一篇讲清。

最佳实践
容器模块与编排港口插画

直接回答:容器监控三层——即时查看用 docker stats(CPU/内存/网络/IO 实时流)与 docker inspect;应用健康用 HEALTHCHECK 指令探活;生产体系化监控靠集中采集:指标(cAdvisor/Prometheus 系)+ 日志聚合 + 告警,单机命令只看临场,平台解决持续可见。

docker stats:临场查看

docker stats                    # 全部容器实时资源流
docker stats web db             # 指定容器
docker stats --no-stream        # 快照一次

CPU%、内存用量/限额、网络 IO、块 IO、PID 数——临场定位"谁在吃资源"的第一工具。

健康检查

HEALTHCHECK --interval=30s --timeout=5s --retries=3   CMD curl -f http://localhost:8080/healthz || exit 1

docker ps 显示 healthy/unhealthy;Compose 可以据健康状态控制依赖启动,但不会因 unhealthy 自动重启;Swarm 对服务任务另有故障恢复机制。没有健康检查的容器,"活着"不等于"能用"。

健康命令依赖镜像中存在 curl;不要把健康检查当作性能或业务正确性测试。Kubernetes 不使用镜像的 Docker HEALTHCHECK,须在 Pod 清单中定义探针。

日志分析

docker logs --tail 100 -f web
docker logs --since 10m web

日志驱动选 json-file(默认)配轮转(max-size/max-file 防撑爆磁盘)。需要跨容器查询时,可用观测云 DataKit 日志采集器读取容器日志路径,保留容器和服务标识;排查重启前的错误时,按服务与时间范围检索,避免只看到新容器启动后的输出。

常见问题(FAQ)

Q:docker stats 的数据能存历史吗?
A:不能——它是实时流。历史趋势要采集进时序监控(Prometheus/观测云),stats 只用于临场。

Q:健康检查失败会自动重启吗?
A:单容器不会自动重启(只标记 unhealthy)——Swarm/K8s 才有基于探针的自动替换。单容器的 --restart 仅针对主进程退出,不能修复单纯 unhealthy;应告警并由受控流程处理。

Q:容器内 CPU 指标和宿主机看到的不一样?
A:容器视图受 cgroup 限额影响——JDK/运行时老版本可能看错配额导致线程池配置错误,是否正确识别 cgroup v1/v2 与配额取决于具体运行时和版本。

官方参考

本文依据官方文档整理,示例未在本文中进行运行验证。生产部署需按所用版本、权限和实际负载验证。

延伸阅读

获取专属方案

联系我们

加入社区

微信扫码
加入官方交流群

立即体验

在线开通,按量计费,真正的云服务!

立即开始

选择观测云版本

代码托管平台