告警风暴/告警太多怎么治理？

更新时间：2026-09-19。短答页。一台核心节点宕机可能瞬间触发几十个「CPU 高、进程 Down、磁盘只读、接口超时」，几十条一起推送，值班反而无法判断主次。

一句话回答

治理告警风暴从三层入手：入口只对「需要人立刻行动」的症状告警并提高阈值质量，Alertmanager 用 group_by 聚合同根因、inhibition 让高级别告警压制衍生告警，再用多窗口燃烧率过滤瞬时毛刺、用 silence 处理计划维护，并定期复盘删掉无效告警。

具体手段

1. 先砍告警源：CPU 偶发高、连接数多等「原因指标」不破 SLO 又无需动作，降为 ticket/看板，不 page。判据：触发时是否需要人立刻做事，见告警设计。
2. 分组聚合 group_by：同 service/alertname/集群的多条告警合并成一条通知，详情在 Alertmanager UI 展开，而不是轰炸手机。
3. 抑制 inhibit：「节点 Down」存在时，自动压制该节点上所有实例级告警；「集群不可用」压住服务级。用 equal 标签精确对齐，避免误吞，见 Alertmanager 路由抑制。
4. 多窗口双阈值：短窗口 AND 长窗口都超阈值才告警，瞬时抖动不打扰，燃烧率 14.4/6/3 分 page 与 ticket。
5. 分级 + repeat_interval：page 电话、warning 群消息、info 工单；未恢复告警的重复提醒间隔拉长（如 4h），靠升级而非轰炸。
6. 计划维护用 silence：发布、演练期间临时静默，且必须设过期时间。
7. 周期性复盘：统计每条告警触发次数和有效率，误报多的调阈值或删除；健康的值班「平时很安静」。

一个典型场景

节点 X 宕机
 ├─ NodeDown            ← 根因告警（page）
 ├─ CPU/Disk/内存异常    ┐
 ├─ Pod 被驱逐 ×8       ├─ 被 inhibition 压制（equal: instance/node）
 └─ 多个接口 5xx        ┘
结果：值班只收到 1 条「NodeDown」+ 一条按服务聚合的影响摘要

坑

• 每条监控项都配 page 告警，等于没有告警（全部被忽略）。
• 抑制 equal 标签配太宽，把无关节点的真实告警也吞掉。
• 只聚合不分级，真正紧急的被埋在一堆 warning 里。
• 静默不设到期，发布后长期「失明」。

总结

告警风暴本质是「一个根因产生多条通知 + 低价值告警泛滥」，治理上先把无需行动的原因类告警降级或删除、只对用户症状 page，再用 Alertmanager 的 group_by 按根因聚合、inhibition 让宕机等高级别告警自动压制同对象的衍生告警，配合短长双窗口燃烧率过滤毛刺、severity 分级和拉长 repeat 间隔、维护期带到期的静默，最后通过周复盘统计有效率持续淘汰噪音告警。