告警风暴治理：收敛、抑制、静默三件套

告警风暴是怎么来的

凌晨三点，MySQL 主库超时。就这一个故障，触发了「连接池耗尽」「慢查询」「订单服务 5xx」「网关超时」……两百多条告警涌进值班手机，同事根本不知道先看哪条，更别说定位根因。

告警风暴的本质是：一个根因，在多个维度上被重复告警。一个服务挂了，它的上游、下游、它依赖的数据库、它所在的主机，全都会跟着报错。如果每条告警都独立通知，人就被淹没在噪音里，真正有用的信号反而被埋掉。

治理思路不是「少设告警」，而是让告警系统学会识别同一个根因，只通知一次。

收敛：把相关告警合成一条

收敛（grouping）把同一时间窗口内、由同一条规则触发的多条告警合并成一条通知。同一台机器上「CPU 使用率 > 90%」连续触发 30 次，只发一条，附带触发次数和首次触发时间。

alert_rules:
  - name: cpu-high
    condition: cpu_usage > 90
    for: 5m
    grouping:
      by: [host]      # 按主机合并
      window: 10m     # 10 分钟内的触发合并

关键在分组维度。按 host 合并，一台机器出问题只报一次；按 service 合并，一个服务出问题只报一次。维度太粗会漏掉关键信息，太细又退回告警风暴。经验是：业务告警先按 service 收敛，单机资源类告警再按 host 收敛。

抑制：高优先级覆盖低优先级

抑制（inhibition）是当一条高优先级告警触发时，自动压住由它引起的低优先级告警。主机宕机时，「该主机上的服务不可达」没有独立价值，直接抑制掉。

inhibition:
  - source: host-down            # 触发条件
    target: service-unreachable  # 被抑制的告警
    match: [host]                # 按 host 关联

抑制规则要克制。只抑制「必然由上游引起」的告警——比如「主机宕机」抑制「该主机上的服务告警」；不要把两个只是碰巧同名的告警关联起来，否则会把真正的独立故障也压掉，那些恰好是最容易在事故里打你一个措手不及的。

静默：有计划地关闭通知

发版、压测、机房切换都是计划内动作，这段时间的告警大多是噪音。静默（silence）按时间窗口关闭指定告警的通知，但告警本身仍会记录，只是不打扰人。

silence:
  - match: {service: "pay-service"}
    start: "2026-10-12 00:00"
    end: "2026-10-12 04:00"
    comment: "支付服务发版"

静默窗口必须写 comment，复盘时才知道「为什么这段时间没有告警」。没有注释的静默，等于给未来的事故埋雷，因为没人记得它到底是不是有意的。

落地顺序与验收

先上收敛（收益最大、风险最小），再上抑制，最后按需配置静默。验收标准很直接：找一次真实故障，统计「告警条数 / 根因数量」的比值，从几十降到 1~2，就说明降噪生效了。三步走完，一次故障从「两百条告警」变成「一条摘要 + 一个根因」，值班同事三分钟内就能定位问题，而不是花一个小时去翻告警。