告警收敛是什么
收敛有四种手段，各自解决的问题不同：去重合并同一指纹的重复上报，聚合把窗口内的同类告警合并成一条通知，抑制在上游故障出现时压掉衍生告警，静默在已知窗口内按条件压制。收敛的目标不是「通知越少越好」，而是让每一条通知都能行动——压缩数量的同时不能丢掉定位所需的实例与维度信息。
基本信息
| 去重 | 按告警指纹合并重复上报 |
|---|---|
| 聚合 | group_by 与分组等待窗口配合，合并同类告警 |
| 抑制 | inhibit_rules 处理因果关联的告警 |
| 静默 | 按匹配器在指定时间窗内压制 |
典型使用场景
- 批量实例故障：同一服务多实例同时异常时合并成一条通知
- 依赖链故障：数据库故障时压掉上层服务的衍生告警
- 计划维护：变更窗口内对相关告警临时静默
- 多来源重复：同一问题由多个探测点同时上报时去重
- 值班体验优化：减少重复通知，把注意力留给可行动告警
收敛效果核对口径
收敛效果核对口径
# 去重效果：原始上报条数与实际通知条数的比值
# 比值明显偏高说明指纹设计合理；比值接近 1 说明没起到作用
# 分组粒度：通知里的分组标签能否定位到具体实例
# 只看到服务名而看不到实例，说明分组过粗
# 抑制命中：风暴期间衍生告警是否被有效压下
# 事后统计被抑制的告警数量，确认规则在真实场景生效
# 静默覆盖率：静默时间内是否仍有相关告警发出
# 仍有漏出说明匹配器范围写窄了四种手段分工
| 手段 | 解决的问题 | 配置位置 |
|---|---|---|
| 去重 | 同一告警重复上报 | 内置行为，依赖告警指纹 |
| 聚合 | 同类告警批量爆发 | 路由段的 group_by 与等待参数 |
| 抑制 | 因果关联的衍生告警 | inhibit_rules |
| 静默 | 已知时间窗内的告警 | 静默规则或维护窗口配置 |
判断该用哪种手段有简单规则：重复来源用去重，批量同类用聚合，因果关联用抑制，已知窗口用静默；用错手段会出现「压下去了但不该压」的情况。
收敛参数要能被复核：分组维度、抑制条件与静默记录都应可查，事后才能解释某条告警为什么没有通知出去。