凌晨 57 条告警只有 1 条是真事：一次告警治理把噪音压到 6 条的复盘

现象：一次典型的「告警疲劳」

上个月凌晨 02:41，值班群被 57 条告警刷屏。我盯着手机看了 3 分钟，发现真正需要动手的只有 1 条——node-07 的磁盘使用率 96%；剩下 56 条里：

• 22 条是 node-07 上 22 个 Pod 的 OOMKilled（同一个根因的连锁反应）；
• 14 条是 node-07 上各容器的 CPU > 90%（OOM 前的挣扎）；
• 11 条是同一批 Pod 的 liveness probe failed（OOM 后探针超时）；
• 8 条是「重复告警」——Alertmanager 的 repeat_interval 是 5 分钟，磁盘那条从 02:21 起每 5 分钟重发一次。

影响面：当夜 P95 响应时长 8 分 12 秒（平时基线约 2 分钟），因为大家都不敢先动手，怕「还有更大的雷」。事后复盘我给它起了个名字：狼来了效应——不是狼没来，是狼来了 57 次，其中 56 次是狼崽。

根因：告警是「事件」，不是「故障」

很多团队的告警规则写得像监控面板：每个指标一个阈值，阈值一过就喊人。但指标超标是「事件」，需要人动手的才叫「故障」。三者之间缺了一层翻译：

1. 没有根因聚合：node-07 磁盘满了 → 容器写不进去 → OOM / 探针挂 → 上游超时，这是一条因果链，却被拆成 57 条独立告警。Alertmanager 其实有 inhibition（抑制）机制专门干这个，只是大多数人没配。
2. 没有分级：P0（要人半夜起来）和 P3（早上看一眼就行）走同一个群、同一个手机号，等于告诉值班同学「全都急」，结果就是「全都不急」。
3. repeat_interval 默认 5 分钟：一条持续 40 分钟的故障会重发 8 次，刷屏 8 倍。

具体做法（可直接抄）

第一步：先量化噪音。 治理前必须先有数据，否则你不知道自己在治什么。

# 近 30 天各告警的触发次数，按次数降序
topk(20, sum by (alertname) (increase(alerts_total[30d])))

我们跑出来的 Top 5 占了全部告警量的 61%，这就是治理靶子。

第二步：用 group_by 把同一服务的告警合并。

# alertmanager.yml
route:
  group_by: [service, severity]   # 关键：先按 service 聚合
  group_wait: 30s                 # 同组 30s 内一起发
  group_interval: 5m
  repeat_interval: 30m            # 从 5m 调到 30m，重复量直接降 6 倍
  routes:
    - matchers: [severity="P0"]
      receiver: phone-pager
      repeat_interval: 10m        # P0 保持高频重发
    - matchers: [severity="P1"]
      receiver: im-group
    - matchers: [severity="P3"]
      receiver: email-only        # 只发邮件，不打扰

第三步：用 inhibition 表达因果链，这是最关键的一步。

inhibition_rules:
  # 节点磁盘满 → 抑制同节点所有 Pod 的 OOM / 探针告警
  - source_matchers: [alertname="NodeDiskAlmostFull"]
    target_matchers: [alertname=~"PodOOMKilled|PodProbeFailed"]
    equal: [node]
  # 节点宕机 → 抑制其上所有 Pod 告警
  - source_matchers: [alertname="NodeDown"]
    target_matchers: []
    equal: [node]

配完之后，复盘那晚的场景：57 条 → 6 条（1 条磁盘 P0 + 5 条真正独立的 P1），值班群第一次只响了一声。

第四步：给告警加「可执行动作」字段。 告警模板里必须带上 runbook_url 和 affected_resources，我们用了 120 行模板改造，把 P95 响应时长从 8m12s 压回 2m03s——人不怕忙，怕的是不知道先干哪件。

踩过的坑（反直觉的地方）

1. inhibition 的 equal 字段写错，抑制关系会反向失效。我最初写成 equal: [instance]，结果磁盘满的告警反而把 NodeDown 抑制了——因为两者 instance 相同。equal 要选因果方向上稳定的标签（node、service），别用 instance 这种带端口号的。
2. P3 告警只发邮件后，团队开始「邮件已读不回」。我们后来给 P3 加了周汇总，每周一 09:00 发一封「上周 P3 告警 Top 10 + 建议动作」，反而把 P3 的响应率从 12% 提到 68%。
3. group_wait: 30s 对 P0 是灾难。P0 要 0 延迟触达，后来给 P0 单独配了 group_wait: 0s。
4. 不要一次把所有阈值都调高。我们第一版把 CPU 阈值从 90% 调到 98%，结果漏掉了一次真实的「CPU 92% 持续 20 分钟」的慢速故障。阈值是「什么时候该叫」，不是「什么时候算病」。

结论 & 可复用清单

告警治理的本质不是「少告警」，而是让每条告警都对应一个明确的、需要人动手的动作。可复用清单：

• [ ] 用 topk(20, sum by (alertname) (increase(alerts_total[30d]))) 量化噪音 Top 20；
• [ ] 每条 P0/P1 告警必须能回答「现在该做什么」，答不上来的先降级 P3；
• [ ] inhibition 用 node / service 做 equal，别用 instance；
• [ ] repeat_interval 按 severity 分档：P0=10m，P1=30m，P3=4h；
• [ ] 每周复盘「被静默/抑制的告警」里有没有漏掉的真故障（我们的漏报率从 3.2% 降到 0.4%）；
• [ ] 给 P3 加周汇总，别让它沉进邮箱。

一句话总结：告警是给「人」看的，不是给「系统」看的——写得像监控，等于没告。