4年踩坑实录：K8s监控该盯这12个指标

生产环境跑了4年Kubernetes后，一位工程师把监控指标从1000个砍到12个——告警噪音降了80%，真正的问题反而一个没漏。

这不是偷懒，是终于搞懂了K8s可观测性的三层逻辑。

第一层：集群健康——平台还活着吗？

大多数团队的第一反应是监控每个节点的CPU。错了。

单个节点飙到90%可能只是调度不均，集群整体还有余量。真正该告警的是集群级容量：当整体利用率超过80%时，你的扩容缓冲已经告急。

控制面（Control Plane）的四个指标必须单独盯：

API Server请求延迟P99超过1秒，etcd的WAL同步延迟超过100毫秒，调度器有Pod pending超过5分钟，控制器队列深度持续增长——任何一个亮起，都不是"等会儿再看"的事。

etcd那个100ms阈值尤其阴险。磁盘I/O抖动时，它不会直接报错，但整个集群的响应会变慢，像得了慢性病。

第二层：工作负载健康——你的应用还好吗？

这里是最容易踩坑的地方。团队爱监控Pod状态，但Pod是短暂的，工作负载才是真相。

Deployment的可用副本数小于期望状态超过5分钟，或者世代号不匹配——说明滚动更新卡住了，新版本没真正上线。

Pod重启次数增长、OOM被Kill、Pending超过2分钟，这三类告警要配齐。但最有价值的是这个：

「15分钟内重启率大于0，持续15分钟触发」——CrashLoopBackOff的早鸟检测。很多团队等Pod状态变红才响应，那时服务已经中断很久了。

HPA（水平自动伸缩）的两个信号常被忽略：当前副本数等于最大值，说明触顶了；CPU利用率持续高于目标值，说明伸缩策略跟不上负载变化。

第三层：应用性能——用户感受到什么？

前面两层保证平台能跑，这层回答用户爽不爽。

RED方法三件套：每秒请求量、错误率（告警阈值1%）、P99延迟（告警阈值500毫秒）。USE方法补位：CPU请求与限制的比例，看资源利用率是否健康。

错误率超过1%就该叫醒值班的人。不是5%，不是"看情况"——1%意味着每100个用户就有1个遇到问题，在流量高峰时这是灾难。

为什么分层这么重要？

因为每一层的误报成本不同。集群层误报可能让人麻木，但漏报会让整个平台雪崩；工作负载层误报最多，但优化后能提前15分钟发现故障；应用层指标最少，但直接关联业务损失。

那位工程师的原话是：「监控所有指标，等于理解 none of them。」

现在检查你的告警列表。如果同一类问题有三条以上不同阈值的告警，或者某个指标你收到后从未采取行动——删掉它。把认知带宽留给真正会救命的12个。