告警风暴本质是监控系统在故障扩散或配置失当下短时产生大量重复、关联或低价值告警，解决关键在于让告警更“聪明”：分组收敛、时间窗口收敛、抑制与级别压制、人工审批型收敛四步协同。
告警风暴本质是监控系统在故障扩散或配置失当情况下，短时间内产生大量重复、关联或低价值告警，导致运维人员注意力被淹没、关键问题反被掩盖。解决它不靠压低告警总数，而靠让告警更“聪明”——该合并的合并，该抑制的抑制，该延后的延后。
分组收敛：让同类告警只发一次
这是最基础也最关键的收敛手段。核心是合理设置 group_by 标签，决定哪些告警算“一类”。
- 推荐起点用 ['alertname', 'job']：既不会把50台机器的宕机缩成一条“api-server down”，也不会为每台机器单独发通知刷屏
- 如果业务按环境隔离（如 prod/staging），记得把 env 标签加进 group_by，否则不同环境的同名告警会被错误合并
- 避免把 instance 放进 group_by，除非你明确需要逐台通知；它更适合放在 alert 的 labels 里用于详情展示
- 配合 group_wait: 10s 和 group_interval: 10s，让系统有缓冲时间收拢同一组内的新告警再统一发送
时间窗口收敛：过滤短时毛刺和高频抖动
针对同一指标在极短时间内反复触发的情况，比如网络抖动引发的连续 ping 失败。
- 设置 for: 5m（基础设施类）或 for: 2m（业务SLI类）：确保告警真正持续存在，不是瞬时异常
- 在告警规则中启用触发条件“5个周期内满足3次”，相当于软性防抖，比单纯依赖 for 更灵活
- 对进程端口类告警，可配置“同主机30分钟内多条归并”，避免发布变更未屏蔽时满屏端口告警
抑制与级别压制：抓住根本原因，屏蔽衍生噪音
很多告警是连锁反应。CPU打满 → 进程卡死 → 接口超时 → 用户报障。只看最后一环，会错过根因。
- 高级别告警自动抑制同源低级别告警：例如 host_down 触发后，该主机上所有 process_down、http_timeout 告警不再发出
- 利用设备/指标依赖关系：配置父设备（如交换机）与子设备（如服务器）的依赖，父设备失联时，子设备告警自动静默
- 对已进入自愈流程的告警，5分钟内同类新告警可跳过处理，防止重复干预
人工审批型收敛：应对大规模异常场景
当系统级故障（如机房断电、批量发布失败）导致告警井喷时，全自动收敛可能误杀关键信号，此时需人机协同。
- 配置规则如“同机房2分钟内10条以上 ping/agent 告警”，触发后电话通知值班人，30分钟内人工确认是否收敛
- 若超时未响应，默认执行收敛，避免告警持续轰炸
- 审批通过后，后续30分钟内相同规则的事件全部归入同一收敛事件，便于统一排查和复盘
