噪音的根源是不可行动
告警噪音的根源往往不是数量太多，而是告警不可行动。降噪目标是让每一条到达值班人员的告警都能对应一个明确动作。常用手段有四类：聚合把同类告警合并，抑制屏蔽因果连带的次要告警，去重让同一对象同一原因只发一次，静默则在计划操作窗口内不发。
基本信息
| 聚合维度 | 按服务、集群、错误类型分组 |
|---|---|
| 抑制关系 | 上游故障时抑制下游连带告警 |
| 去重键 | 对象加告警规则，重复出现只更新计数 |
| 静默窗口 | 计划内变更与演练期间按标签静默 |
| 健康指标 | 单位时间内到达值班人员的告警条数 |
典型使用场景
- 批量目标同时异常：聚合为一条带目标数量的通知，而非上千条逐条推送
- 链路故障：上游不可用时抑制下游连带告警，保留根因那一条
- 快速恢复的抖动：用持续时间条件过滤，避免瞬时抖动触发通知
- 计划内操作：变更与演练窗口内静默相关标签，避免预期内告警
- 长期治理：统计高频告警并逐条决定修阈值、加白名单或删除规则
降噪手段对照
| 手段 | 作用 | 误用风险 |
|---|---|---|
| 聚合 | 同类告警合并为一条 | 把不同根因混为一谈 |
| 抑制 | 屏蔽连带告警 | 范围过宽会掩盖真实故障 |
| 去重 | 同一对象同一原因只发一次 | 计数丢失后难判严重程度 |
| 静默 | 指定窗口内不发送 | 忘记解除导致故障被静默 |
聚合与抑制的配置要点
聚合与抑制的配置要点
# 聚合：同类告警合并，控制通知频率
group_by: [service, cluster, alertname]
group_wait: 30s # 首次等待，收集同组告警
group_interval: 5m # 同组后续通知间隔
repeat_interval: 4h # 未恢复时的重复提醒间隔
# 抑制：上游故障期间屏蔽下游连带告警
inhibit_rules:
- source_match: {severity: critical}
target_match: {severity: warning}
equal: [cluster]降噪与漏报是一对反向指标：抑制与聚合过强会掩盖真实故障，因此每次调整后都应用一次已知故障回放验证根因告警仍能到达。降噪的验收标准是根因可见，而不是告警数量下降。
静默与白名单必须有到期时间。无到期时间的静默会在故障期间继续屏蔽通知，把可控的短暂异常拖成长时间不可用，而且排查时很难想到是静默仍在生效。