容器监控别瞎盯宿主机平均负载，真正要盯的是容器实际CPU限流、内存工作集、OOMKilled次数、Pod重启次数、磁盘I/O突发和网络丢包，再结合副本数与就绪探针失败数一起看。
容器监控指标有哪些才不算瞎看
很多团队把宿主机监控面板直接搬到容器环境，结果CPU平均使用率看着只有20%，Pod却频繁重启，问题不在资源不够，而是看错了指标,下面按四个层级拆开。
CPU指标：限流比例比平均使用率更关键
容器跑在cgroup限制下，CPU分配有request和limit,只看平均CPU使用率会掩盖短时突发被限流的情况。
- CPU使用率：按容器实际消耗除以limit计算，不是除以宿主机核数
- CPU限流（throttling）：cgroup的
cpu.stat里nr_throttled持续增长，说明容器频繁被内核压制 - CPU配额：
kubectl top pods显示的是瞬时值，需结合rate()看趋势
排查场景：Java应用在压测时P99延迟突然升高，节点CPU并不高，登录节点执行cat /sys/fs/cgroup/cpu/cpu.stat，看到nr_throttled持续增长，基本可以判断是CPU limit设小导致限流。
内存指标：working set和OOMKilled是重点
容器内存监控指标不要只看used,分页缓存会干扰判断。
- working set：活跃使用的内存，不含可回收的page cache，最接近应用真实占用
- RSS：常驻内存，包含部分共享内存，多容器对比时容易虚高
- OOMKilled：
kubectl describe pod里Events出现OOMKilled，说明容器超限被杀 - 内存使用率：working set除以limit，持续超过85%就要关注
实操命令：
kubectl top pods --containerskubectl describe pod <pod-name>看Events- 在节点上：
cat /sys/fs/cgroup/memory/memory.usage_in_bytes和memory.stat
磁盘指标：别只看使用率，盯写入放大和inode
容器层使用overlayfs，写时复制会产生额外写入，镜像层越多,写放大越明显。
- 磁盘I/O吞吐
：读/写字节数，突发增长常代表日志爆炸或缓存击穿
- inode使用率：小文件密集应用快速耗尽inode，磁盘空间还剩很多却无法创建文件
- 容器层写入量：通过
docker system df或cAdvisor的container_fs_write_bytes_total查看 - 磁盘使用率：节点级和容器级分开看，节点级满会直接影响所有Pod
网络指标：丢包和重传比总流量更值得告警
网络问题通常表现为延迟升高,而不是流量绝对值异常。
- 接收/发送速率：判断是否打满带宽
- 丢包率：
netstat -s查看packet receive errors，或cAdvisor的container_network_receive_drop_total - TCP重传率：高重传说明网络质量差或连接数打满
- 连接数：ESTABLISHED连接数接近
somaxconn或nf_conntrack满，会出现新建连接失败
容器监控和虚拟机监控区别：照搬老套路容易漏报
很多人问容器监控和虚拟机监控区别在哪，核心一句话：虚拟机监控面向长期运行的单体系统，容器监控面向短生命周期、共享内核、受cgroup限制的批量实例。
| 维度 | 虚拟机监控 | 容器监控 |
|---|---|---|
| 生命周期 | 长，按小时或天聚合 | 短，按分钟甚至秒聚合 |
| CPU限制 | 宿主机或vCPU分配 | cgroup quota，看限流次数 |
| 内存计算 | 可用内存和used | working set与RSS差异大 |
| 磁盘 | 虚拟磁盘使用率 | overlayfs写入放大、inode |
| 重启 | 少，通常意味故障 | 频繁重启可能是正常滚动更新 |
| 监控对象 | 单台主机 | Pod、Deployment、Service、Namespace |
虚拟机监控重点在“这台机器还活着吗”，容器监控重点在“这个副本为什么被杀了、新副本什么时候就绪”，直接把Zabbix那套磁盘使用率、CPU平均负载搬过来,大概率会漏掉OOMKilled和CrashLoopBackOff。
生产环境容器监控方案怎么搭最省心
生产环境容器监控方案建议以Prometheus + Grafana + Alertmanager为主，配合kube-state-metrics和cAdvisor,这套组合在云原生社区已经形成事实标准。
基础采集架构
- cAdvisor：kubelet内置，暴露容器资源指标，Prometheus直接抓取
- kube-state-metrics：暴露Deployment、Pod、StatefulSet等资源对象状态
- node-exporter：采集宿主机磁盘、网络、文件系统指标
- 应用metrics：通过ServiceMonitor或PodMonitor接入业务自定义指标
告警规则设置顺序
先围绕“容器被杀”和“限流”设计告警,再逐步扩展。
- Pod重启次数15分钟内超过2次
- OOMKilled事件产生
- CPU限流时间占比持续较高
- 内存working set占limit比例持续高于85%
- Deployment副本不满足期望数
- 就绪探针失败次数突增
搭建路径
- 用Helm安装
kube-prometheus-stack - 确认cAdvisor采集目标正常，查看
container_cpu_usage_seconds_total指标 - 导入Grafana社区公开面板，按namespace和pod筛选
- 在Alertmanager配置分级通知，先只告警OOMKilled和Pod重启
- 观察一周后，根据实际波动调整阈值
Docker容器监控命令与Kubernetes常用排查路径
日常排障不必每次打开Grafana,命令更快定位问题。
单机Docker环境
docker stats --no-stream：快速查看所有容器CPU、内存、网络docker inspect <container_id> | grep -A 10 Memory：查看内存limit和实际使用docker system df：查看镜像、容器层磁盘占用docker logs --tail 100 <container_id>：配合OOMKilled事件看应用日志
Kubernetes环境
kubectl top pods -n <namespace>：查看Pod和容器资源使用kubectl describe pod <pod-name>：查看Events、状态、重启原因kubectl get events --field-selector reason=OOMKilled -n <namespace>：过滤OOM事件kubectl get pods -n <namespace> --watch：观察Pod状态变化
典型排查链：用户报接口超时→看Grafana发现P99升高→kubectl top pods看CPU不高→kubectl describe pod看到Events里有OOMKilled→查看应用日志发现内存泄漏→调大limit或修复代码。
免费容器监控工具选型对比
免费容器监控工具不少,但适用场景差别很大。
| 工具 | 费用 | 适合场景 | 短板 |
|---|---|---|---|
| cAdvisor | 免费 | 单机容器指标采集 | 无长期存储和告警 |
| Prometheus+Grafana | 开源免费 | 生产环境多维监控 | 需自行维护存储和规则 |
| Netdata | 免费 | 开发环境实时查看 | 多集群聚合能力弱 |
| Zabbix | 开源免费 | 传统运维过渡期 | 容器自动化发现配置较重 |
| 简米云ARMS | 免费额度+按量 | 托管免运维 | 深度依赖云平台 |
生产环境建议优先Prometheus方案，开发环境用docker stats和cAdvisor足够,别一上来就上重型监控。
容器监控最关键的一条：围绕“限制、工作集、重启、限流”四个词设置采集和告警，比死盯宿主机平均指标更有用。 把OOMKilled和CPU throttling当成第一优先级,其他指标往后排。
Q&A：容器监控指标有哪些是必须采集的？
必须采集四类：CPU使用率与限流、内存working set与OOMKilled、Pod重启次数、磁盘I/O与inode使用率,网络指标按业务规模选择性采集。
Q&A：容器监控和虚拟机监控区别会影响告警阈值吗？
会，虚拟机内存使用率80%告警是安全线，容器里working set达到limit的85%往往距离OOMKilled已经很近，应更早告警，CPU也不能只看平均,要看限流时间占比。
Q&A：生产环境容器监控方案需要付费吗？
可以完全免费，使用开源的Prometheus、Grafana、Alertmanager、cAdvisor和kube-state-metrics即可覆盖绝大多数生产场景，只有在需要托管存储、跨地域统一查询或团队缺乏维护人力时,才考虑云厂商托管版Prometheus服务。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/638852.html
