智能告警降噪：别再被一次故障刷出两百条通知

告警风暴从哪来

一次数据库慢查询，可能同时触发五条告警：CPU 使用率告警、慢 SQL 告警、连接数告警、下游服务超时告警、调用方 5xx 告警。五条告警说的其实是同一件事，值班同学却要在群里被 @ 五遍，还得逐条点掉。更糟的是，多数团队的历史告警里，八成是阈值抖动造成的误报——流量高峰 CPU 冲到 85%，过了 30 秒又回落，阈值定死在 80% 就会反复触发。

告警的价值不在「多」，而在「每条都值得处理」。降噪要解决的就三件事：重复、抖动、级联。

三层降噪机制

炬鲸把降噪拆成三层，按顺序执行。

第一层去重：按「指标名 + 标签集合 + 告警规则」生成指纹，相同指纹在窗口期内只发一次，后续到达只更新计数，通知里带上「已触发 N 次」。

第二层聚合：把同一时间窗口内、标签高度重合的告警合成一条，附上涉及的主机或服务列表。比如 20 台机器同时 CPU 告警，合成一条「20 个节点 CPU 使用率超阈值」，而不是 20 条。

第三层抑制与升级：配置依赖关系，A 故障必然导致 B 告警时，只发 A、静默 B；同时给告警分级，P1 告警 10 分钟未确认就自动升级成 P0，走电话外呼。

一个完整配置

alert_noise:
  dedup:
    window: 5m
    fingerprint: [metric, labels, rule_id]
  group:
    window: 10m
    by: [service, region]
    max_events: 50
  inhibition:
    - source: node_down
      target: service_unavailable
      equal: [host]
  escalation:
    - level: P1
      wait: 10m
      to: P0
      notify: [sms, phone]

这段配置的效果：5 分钟内同一告警只发一次；10 分钟窗口内按服务和地域聚合；节点宕机时抑制该节点上所有「服务不可用」告警；P1 告警 10 分钟没人处理，升级成 P0 走电话。

落地建议

先做去重和聚合，见效最快、风险最低，一两天就能把通知量砍掉一半。抑制需要梳理依赖关系，建议先只配「节点宕机 → 服务不可用」这一条最明确的规则。升级链路最后上，先拿 P1 试点，别一上来就让 P2 打手机把人吵醒。

阈值抖动要靠动态基线解决，别指望手工调阈值。给关键指标开启异常检测，用历史 30 天数据学出基线，偏离超过 3 倍标准差才告警，比固定阈值的误报少一个数量级。上线后每周复盘一次「未处理告警」，把没用的规则删掉，比加任何功能都管用。