告警风暴与抑制是什么
告警风暴通常由依赖树顶部故障引发：数据库或机房级故障一发生，下游几十条告警同时涌出，值班人反而看不到最关键的根因告警。抑制（inhibition）是 Alertmanager 给出的解法之一：定义源告警与目标告警，当源告警处于触发状态时，匹配的目标告警被压制，从而在依赖树顶部掐断传导。指标侧还要配合，用 for 与阈值过滤伪报警、用分组把同一根因的多条告警合并。
基本信息
| 配置位置 | Alertmanager 的 inhibit_rules |
|---|---|
| 关键字段 | source_matchers、target_matchers、equal |
| 配套手段 | 路由 group_by 分组、规则侧 for 与阈值 |
| 验证方式 | amtool 或 Alertmanager 界面查看抑制与静默状态 |
| 权限要求 | 配置文件修改与服务重载 |
典型使用场景
- 机房级故障：机房不可达时抑制该机房所有下游服务的次要告警
- 数据库根因：主库故障时抑制所有依赖它的应用层告警
- 网络分区：核心链路中断时抑制受影响节点的探活类告警
- 发布窗口：变更期间抑制与本次变更直接相关的告警
- 容量事件：存储写满时抑制由此引发的写入失败类告警
抑制规则设计要点
- 用 equal 约束标签（如机房、集群），避免抑制范围跨域扩散
- 源告警要选真正代表根因的那一条，通常最上游、最先发生
- 抑制会掩盖信息，规则要评审留档，避免长期压制形成盲区
- 抑制与静默不同：抑制是条件性自动压制，静默是人工指定时段
- 每次风暴复盘都要回答问题「哪些告警本不该发」，从规则侧减量
抑制与分组示例
抑制与分组示例
inhibit_rules:
- source_matchers: [ 'alertname="DatacenterBlackhole"' ]
target_matchers: [ 'severity=~"critical|warning"' ]
equal: [datacenter] # 仅抑制同一机房内的目标告警
# 分组：把同一根因的多条告警合并成一条通知
route:
group_by: ['alertname', 'cluster', 'service']
group_wait: 30s
group_interval: 5m
repeat_interval: 4h四类降噪手段
| 手段 | 作用范围 | 适用时机 |
|---|---|---|
| for 与阈值 | 指标侧单条规则 | 过滤瞬时抖动 |
| 路由分组 | 同根因多条告警合一 | 同一故障多实例同时告警 |
| 抑制规则 | 依赖树上下游之间 | 顶部故障引发连锁告警 |
| 静默 | 指定标签与时间段 | 计划变更或已知事件 |
把静默当解决办法会掩盖依赖树设计问题：风暴期间临时静默范围开得过大，恢复后忘记撤销，等于长期留下监控盲区。