分组解决什么问题
分组把维度组合相同的告警合并成一条通知：同一类告警在大量实例上同时出现时，合并能显著降低通知数量。判断维度的标准是值班会不会按同一套动作处置，而不是数据上是否相似。
维度取舍决定体验
分组维度的取舍直接影响使用体验：键太少会让通知笼统到无法定位对象，键太多则退化成逐条通知，收敛效果消失。首次等待时间与重复间隔则控制聚合窗口与后续提醒频率，需要与分组粒度一起调整。
基本信息
| 分组维度 | 按一起处置的维度选取 |
|---|---|
| 首次等待 | 通知发出前等待同组告警聚齐的时间 |
| 重复间隔 | 同一组告警再次通知的间隔 |
| 继承关系 | 子路由未配置时继承父级设置 |
典型使用场景
- 批量实例故障：同类告警合并为一条，避免短信轰炸
- 多集群运维：按集群切分分组，互不串扰
- 团队分流：按服务归属拆分，接收方直接对号入座
- 逐台处置场景：按实例分组，保证处置动作不被合并
- 发布窗口：调整等待时间让同一批变更的告警聚在一起
分组配置
分组配置
route:
group_by: [alertname, cluster, service] # 一起处置的维度
group_wait: 30s # 首次通知前等待同组告警聚齐
group_interval: 5m # 同组内新增告警后的再次通知间隔
repeat_interval: 4h # 未恢复时的重复提醒间隔维度取舍
| 分组维度 | 效果 | 适用场景 |
|---|---|---|
| 仅按告警名 | 同类告警合并为一条 | 批量实例同类故障 |
| 加集群 | 按集群切分通知 | 多集群环境 |
| 加服务 | 按服务归属拆开 | 接收方按服务分工 |
| 包含实例 | 逐台单独通知 | 需要逐台处置的场景 |
调整分组的方法
- 按是否会采取同一套处置动作来判断维度是否该保留
- 首次等待时间与重复间隔要随分组粒度一起调整
- 改完观察通知条数与可读性是否同时改善
分组的目标是让通知可读且可行动：条数少但信息够用，比条数多而每条都缺关键维度更有价值。
分组键覆盖全部标签等于逐条通知，收敛效果完全消失；反过来，含实例标签的分组通常只在需要逐台处置时才有意义。