容器告警规则应该怎么配置？这几条建议帮你避坑

容器告警是监控体系里最容易配置、也最容易配糟的一环。很多人装好Prometheus之后，直接从网上抄一套Prometheus告警规则模板就上了生产，结果要么告警风暴天天响，要么真出事的时候一个通知都收不到。告警规则的本质是把"什么情况算异常"翻译成机器能理解的查询表达式，这个翻译过程需要结合业务特点仔细打磨。本文从指标选择、阈值设定、表达式编写和告警治理四个层面，给出一套可落地的配置建议。

一、先搞清楚容器监控该盯哪些指标

配置告警之前，必须先明确监控对象的核心指标，否则后面的阈值都是空中楼阁。容器环境下通常分为三个层级：节点级、容器级和应用级。节点级关注集群物理资源是否充足，容器级关注单个Pod是否健康，应用级则关注业务逻辑是否正常。

节点级指标包括CPU使用率、内存使用率、磁盘空间、磁盘IO、网络流量等。容器级指标要特别注意一点：container_cpu_usage这类指标反映的是实际用量，但容器更关键的是"是否接近Limit"。一个容器CPU用量只有50%，如果Limit设的是0.5核，那它其实已经饱和了。因此告警应该基于用量与Limit的比值，而不是绝对值。

应用级指标包括HTTP错误率、请求延迟P99、JVM堆内存等。这一层往往最贴近用户感知，优先级也最高。一个常见的失误是把全部精力放在资源告警上，忽略了应用层面的5xx错误，结果用户已经大量报障，监控大屏却一片绿色。

二、CPU与内存告警的阈值和表达式怎么写

CPU告警建议采用"用量占Limit百分比"的方式，并配合持续时间过滤瞬时毛刺。比如容器CPU持续5分钟超过Limit的90%，才触发告警。对应的PromQL表达式如下：

- alert: ContainerCPUHighUsage
  expr: |
    sum by (namespace, pod, container) (
      rate(container_cpu_usage_seconds_total{container!=""}[5m])
    )
    /
    sum by (namespace, pod, container) (
      kube_pod_container_resource_limits{resource="cpu"}
    ) > 0.9
  for: 5m
  labels:
    severity: warning

这里有几个细节值得注意。container!=""用于过滤掉Pod本身的infrastructure container，避免统计重复；rate(...[5m])计算的是5分钟内的平均速率，天然过滤了秒级抖动；for: 5m要求条件持续成立5分钟才真正触发，这两层过滤叠加后，基本可以消灭CPU毛刺导致的误报。

内存告警的思路类似，但内存不像CPU那样可以压缩，超过Limit容器会被直接OOMKill，因此内存告警的容忍时间要更短。建议设置为：内存超过Limit的85%持续3分钟即告警，级别可以定为warning；如果已经出现OOMKilled重启，则直接升级为critical。判断容器是否被OOM杀掉，可以借助kube_pod_container_status_last_terminated_reason这个指标：

- alert: ContainerOOMKilled
  expr: |
    kube_pod_container_status_last_terminated_reason{reason="OOMKilled"} == 1
  labels:
    severity: critical

另外要提醒一点，如果容器没有设置Limit，上面基于Limit的表达式会失效（分母缺失或为0）。所以在配置告警的同时，应该通过准入控制强制所有工作负载设置requests和limits，否则监控体系会有盲区。

三、磁盘、网络与可用性告警的实践要点

磁盘空间告警是老生常谈，但容器环境下有额外的坑。节点磁盘除了系统盘，还承载着容器日志、emptyDir临时卷和镜像层，/var/lib/kubelet目录满了会导致Pod被驱逐。建议设置两级阈值：使用率超过80%为warning，超过90%为critical，并且持续时间设为10分钟以上，因为磁盘增长通常是渐进的，不需要秒级响应。

- alert: NodeDiskFillingUp
  expr: |
    (node_filesystem_avail_bytes{mountpoint="/var/lib/kubelet"}
    / node_filesystem_size_bytes{mountpoint="/var/lib/kubelet"}) * 100 < 20
  for: 10m
  labels:
    severity: warning

网络方面，重点关注节点网络错误和丢包，而不是绝对带宽。带宽高低和业务形态强相关，很难定通用阈值，但网卡的收发包错误数应该是0，一旦大于0就值得排查。可用性告警则建议用kube_pod_status_phase配合重启次数来判断：Pod长时间不处于Running状态，或者kube_pod_container_status_restarts_total在30分钟内增长超过3次，说明容器在反复崩溃，属于典型的crash loop，应配置为critical级别并尽快通知值班人员。

四、告警治理：分级、抑制与静默缺一不可

规则写得再好，如果通知策略混乱，值班同学很快就会对告警免疫。治理的第一步是分级，建议只保留三级：critical表示需要立即处理，warning表示当天处理，info只记录不通知。分级太多的团队，实际执行中往往全部按最高级处理，分级就失去了意义。

第二步是配置抑制规则。典型场景是：当某台节点宕机时，这台节点上的所有容器告警都应该被抑制，只保留节点级告警，否则一次宕机会瞬间产生几十条通知。Alertmanager中的抑制配置示例如下：

inhibit_rules:
- source_match:
    severity: critical
    alertname: NodeDown
  target_match_re:
    severity: warning|critical
  equal: [instance]

第三步是合理使用静默。发布窗口、计划内维护期间，提前设置静默规则，避免发布引起的重启告警干扰判断。但静默要有明确的截止时间和负责人，防止静默之后忘了解除，把真实故障也吞掉了。

最后，告警规则不是配完就一劳永逸的。建议每月做一次告警回顾：统计哪些告警从未触发过（可能是阈值太松，规则形同虚设）、哪些告警触发后没人处理（可能是优先级或描述有问题）、哪些告警反复误报（需要调整表达式）。通过这种持续迭代，告警的精确率会逐步提升，最终达到"每一条告警都值得看"的理想状态。

容器告警规则Prometheus监控Kubernetes告警修改时间：2026-09-05 05:24:40