告警收敛由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+），日志里会打印每条告警的分组路径和等待状态
group_by 该写啥。线上跑着的 alertmanager.yml，十次收敛失效有八次是因为 group_by 和实际告警标签对不上。 
