容器 OOMKilled 问题频发，如何通过监控进行预防和快速定位？

OOMKilled 是内存不足时内核直接“杀进程”的结果。麻烦在于：进程被杀的瞬间，应用往往来不及写日志，单看应用日志常常是“一片空白”。这时必须靠监控指标来还原现场。

关键监控指标

重点关注 container_memory_working_set_bytes：

• 它反映的是容器实际活跃使用的内存，比传统的 RSS 更准确（RSS 不含 page cache 等，容易低估）；
• 当它持续接近 memory limit 时，就存在 OOM 风险，应该提前预警。

与其被动等 OOM，不如主动告警

配置告警规则，在内存使用率持续超过 90% 时就触发警告，而不是等到 OOM 事件发生后才响应。这能把“救火”变成“防火”。

一个常见的展示坑

排查时除了看 kubectl describe 事件里的 OOMKilled，还要关注指标在 Pod 重启后的曲线表现。

有个已知的展示问题：Pod 重启后，新旧容器的数据会在图表里叠加，导致内存总和看起来“超过 limit”。这其实是查询聚合方式造成的假象——需要调整查询，按 container 和 id 分组，才能看到真实的单容器内存曲线。

小结

OOM 看 container_memory_working_set_bytes，提前 90% 告警；图表里“超 limit”的异常多半是新旧容器叠加的展示问题，分组查询即可还原真相。