路由树是什么
接收端用一棵路由树决定告警往哪里送：根节点给出默认接收器与分组方式，子路由按标签条件分流。告警从根开始逐层匹配，命中的第一个子路由接管它，并由该节点的配置决定分组与通知节奏。
匹配顺序
匹配是自上而下的深度优先：先看父节点的子路由列表，按书写顺序逐个尝试，命中即进入该子树。因此规则要按从具体到宽泛排列，否则前面一条宽泛规则会把后面所有更精确的规则挡在外面，且不会报错。
继续匹配的用途
在匹配到某条子路由之后仍要继续检查后面的兄弟路由，需要显式打开继续匹配开关。它常用在一个告警要同时通知值班与业务群组的场景：既走电话通道，也发到对应团队群，两边都能看到。
基本信息
| 结构 | 根路由加多层子路由，形成树形结构 |
|---|---|
| 匹配依据 | 告警标签与匹配表达式 |
| 默认接收器 | 根节点的接收器作为兜底 |
| 分组配置 | 每个节点可以覆盖分组维度与等待时间 |
| 继承规则 | 子节点未配置的项目从父节点继承 |
典型使用场景
- 按严重级别分流：最高级走电话，其余走即时消息或工单
- 按团队分流：不同团队接收各自负责的告警
- 按环境分流：生产进值班通道，测试环境只留痕
- 同时通知多方：用继续匹配把告警同时送到值班与业务群
- 配合静默与抑制：在路由层区分需要抑制的类别
- 兜底通道：根节点接收器保证没有告警被静默丢弃
路由示例
路由示例
route:
receiver: default-im # 兜底接收器
group_by: [alertname, cluster]
routes:
- matchers: [ 'severity="critical"' ]
receiver: pager # 最高级走电话
- matchers: [ 'team="search"' ]
receiver: search-im
continue: true # 同时继续匹配后面的规则
- matchers: [ 'severity="warning"' ]
receiver: warn-im路由字段
| 字段 | 作用 | 注意 |
|---|---|---|
| 匹配表达式 | 筛选该子路由负责的告警 | 按具体到宽泛排列 |
| 接收器 | 命中后告警发给谁 | 需提前确认通道可用 |
| 分组方式 | 决定通知合并的维度 | 子节点未写则继承父节点 |
| 等待时间 | 首次通知前的等待 | 用于等待同组告警聚齐 |
| 继续匹配 | 命中后是否继续检查兄弟路由 | 开启后会产生多份通知 |
常见配置问题
| 问题 | 后果 | 处理方式 |
|---|---|---|
| 宽泛规则写在前面 | 后续规则永不生效 | 把宽泛规则放到最后 |
| 分组键过细 | 通知数量暴涨 | 按一起处置的维度分组 |
| 接收器不可用 | 告警静默丢失 | 定期核对通道可用性 |
| 覆盖关系混乱 | 实际分组与预期不符 | 先画清整棵树再改配置 |
改动路由的做法
- 改前先画清整棵树，确认每个节点的分组与接收器
- 用查询工具确认某条告警最终会走哪条路径
- 路由改动必须评审，它直接决定告警能否送达
- 为关键级别保留独立通道，不与低级别共用
路由只决定送到哪里，不决定是否触发：阈值与表达式仍在规则文件里，排障时先确认上游是否已经推送告警。
一条没有条件的兜底规则写在前面会吞掉后面所有规则：顺序必须按从具体到宽泛排列，改动后要逐条验证。
路由树的层次不宜过多：三层以上时很容易忘记某条规则被谁覆盖，维护成本会超过它带来的分流收益。