Python 告警收敛的规则配置

告警收敛由alertmanager.yml的route块控制，通过group_by、group_wait、group_interval和repeat_interval实现；inhibit_rules仅用于抑制关联告警，与收敛无关。

告警收敛规则写在哪？alertmanager.yml 的 route 和 inhibit_rules 不是同一回事

收敛不是靠抑制（inhibition）实现的，而是靠路由（route）里的 group_by、group_wait、group_interval 和 repeat_interval 配合完成的。很多人一上来就翻 inhibit_rules，结果告警还是刷屏——那是用来“压住另一条告警”的，比如 CPU 高时别再报进程挂了，和收敛无关。

真正控制“多少条告警合并发一次”“隔多久重发”的，全在 route 块里。你改错地方，配再细也没用。

• group_by: ['alertname', 'job']：按字段聚类，相同 alertname + 相同 job 才进同一组；漏掉 instance？那所有实例的同一告警会挤在一起，失去定位能力
• group_wait: 30s：新告警来了先等 30 秒，看有没有同类冒出来；设太短（如 5s）等于没收敛，设太长（如 5m）会让首条告警延迟严重
• group_interval: 5m：组内新增告警后，至少隔 5 分钟才发下一批；它和 repeat_interval（重发周期）容易混淆——后者是“这条告警本身多久重发一次”，前者是“这个组多久攒一波新成员再发”

group_by 漏字段导致收敛失效的典型表现

现象：明明配置了 group_interval: 10m，但每分钟都收到重复告警。打开 Alertmanager Web UI 的 Status 页面，点开一条告警看 Fingerprint，大概率发现：本该归一组的告警，指纹完全不同。

原因几乎全是 group_by 没包含区分维度的标签。比如你的告警带 instance="10.1.2.3:9100"，但 group_by: ['alertname'] ——所有机器的 NodeDown 全被塞进一个组，可 Alertmanager 实际按 labels 全量哈希算指纹，instance 不参与分组，就根本不会合并。

上班人导航

上班人必备的职场办公导航网站

下载

立即学习“Python免费学习笔记（深入）”；

• 查原始告警标签：curl http://am:9093/api/v2/alerts，看 labels 字段实际有哪些键
• 生产环境建议显式列出关键维度：group_by: ['alertname', 'job', 'severity', 'cluster']，别用 ... 或省略
• 如果必须按动态值分组（比如不同业务线不同 team 标签），确保 exporter 或 rule 中已注入该标签，Alertmanager 不会自动补

收敛和静默（silence）混用时的优先级陷阱

静默不阻止告警进入路由树，只决定“这条告警最终要不要发出去”。而收敛发生在路由匹配后的分组阶段。所以：即使你对某类告警建了静默，只要它匹配到某个 route，依然会参与 group_wait 和 group_interval 计算——可能卡住整个组的发送节奏。

比如你静默了 severity="warning"，但 route 是按 alertname 分组的，而 Warning 和 Critical 共享同一个 alertname，那 Critical 告警就得等满 group_wait 才发，因为 Warning 虽被静默，但已入组。

• 检查静默是否跨组生效：在 Alertmanager UI 的 Silences 页，确认 Matchers 是否意外覆盖了不该静默的标签组合
• 更安全的做法：用 continue: true + 子路由把 warning 单独引走，避免和 critical 混组
• 临时调试时，可在 route 里加 debug: true（v0.24+），日志里会打印每条告警的分组路径和等待状态