# 条件路由

根据标签和级别把事件送到不同的媒介或团队。

最后校对于 2026-10-10

这页办完你会知道：想让「S1 打电话、S3 只进群」「`env=prod` 的走值班群、`env=dev` 的不发」 这类需求落地，该动哪一处配置。

## 路由发生在通知规则里[​](#路由发生在通知规则里 "路由发生在通知规则里的直接链接")

夜莺没有单独的「路由表」。事件产生之后，会逐条走它命中的**通知规则**， 每条通知规则内部又可以有多条 **通知配置**——真正的分流就在这一层。

一条通知配置 = **一个媒介 + 一个消息模板 + 一组接收人 + 一组筛选条件**。 筛选条件不满足就跳过这条配置，其余配置照常。

## 1. 在一条通知规则里按条件分流[​](#1-在一条通知规则里按条件分流 "1. 在一条通知规则里按条件分流的直接链接")

**告警通知 → 通知规则**，编辑一条规则，在 **通知配置** 里点「添加通知配置」， 每加一条就是一个分流出口。每条上的四组条件都留空表示不限制，之间是「与」：

| 条件     | 能做的分流                                                                 |
| -------- | -------------------------------------------------------------------------- |
| 适用级别 | S1 走电话、S2 走短信、S3 走群消息                                          |
| 适用时段 | 按周几 + 时段。白天进群、夜里打电话                                        |
| 适用标签 | 按事件标签，六种操作符和屏蔽规则一样                                       |
| 适用属性 | 按固定的几个属性：业务组、数据源、是恢复事件？、告警规则、级别、机器业务组 |

「S1 打电话、S3 只进群」的最小配置：同一条通知规则里放两条通知配置， 第一条媒介选电话、适用级别只勾 S1；第二条媒介选群机器人、适用级别只勾 S3。

**三个级别一个都不勾等于把这条配置停用**——它什么事件都匹配不到。

「是恢复事件？」这个属性值得单独说：想让恢复通知只发群、不打电话， 在电话那条配置的适用属性里把它排掉，比在模板里判断干净。

## 2. 用多条通知规则分流[​](#2-用多条通知规则分流 "2. 用多条通知规则分流的直接链接")

一条告警规则可以挂多条通知规则。当两拨接收人**关心的事件集合本来就不一样**时， 拆成两条通知规则比在一条里堆通知配置更好维护——各自的授权团队不同，改起来互不影响。

判断标准很简单：同一批人、同一个场景，用通知配置；不同团队各管各的，用不同的通知规则。

## 3. 让别的团队自己订阅[​](#3-让别的团队自己订阅 "3. 让别的团队自己订阅的直接链接")

如果分流的动机是「另一个团队也想收到这类告警」，不要去改人家的通知规则， 让他们建一条[订阅规则](https://n9e.github.io/zh/docs/events/subscriptions.md)——订阅方自己决定筛什么、用哪条通知规则发， 规则的所有者完全不用参与。

## 4. 根本不该发的，在工作流里丢掉[​](#4-根本不该发的在工作流里丢掉 "4. 根本不该发的，在工作流里丢掉的直接链接")

前三种是「送到哪里」，这一种是「不送」。在[事件 Pipeline](https://n9e.github.io/zh/docs/events/pipelines.md) 里用 **事件丢弃** 处理器按条件把事件拦下来：

```
{{ if eq $event.TagsMap.env "dev" }}true{{ end }}
```

挂在**告警规则**上，事件在屏蔽之前就被丢掉，所有下游都看不到它； 挂在**通知规则**上，只影响这一条通知规则的这次发送。

## 选哪一种[​](#选哪一种 "选哪一种的直接链接")

| 你想要的效果                 | 用什么                                                         |
| ---------------------------- | -------------------------------------------------------------- |
| 同一批人，不同级别用不同媒介 | 一条通知规则里的多条通知配置                                   |
| 夜里和白天走不同渠道         | 通知配置的适用时段                                             |
| 不同团队各管一摊             | 多条通知规则                                                   |
| 别人也想收到我的告警         | 订阅规则                                                       |
| 这类事件根本不该发           | 工作流的事件丢弃处理器                                         |
| 变更窗口内暂时别吵           | [屏蔽规则](https://n9e.github.io/zh/docs/events/mute-rules.md) |

## 几个容易踩的点[​](#几个容易踩的点 "几个容易踩的点的直接链接")

* **标签得先存在。** 按 `env` 分流的前提是事件上有 `env` 标签。没有就先在告警规则的 附加标签里补，或者在工作流里[改写出来](https://n9e.github.io/zh/docs/events/relabel-enrich.md)。
* **适用标签匹配的是事件标签，不是规则名。** 想按规则分流，用「适用属性」里的「告警规则」。
* **顺序无关。** 一条通知规则里的多条通知配置是**并列**的，命中几条就发几条， 不是「先匹配到哪条就用哪条」。想互斥就把条件写成互斥的。
* **改完先测。** 通知配置右边有「通知测试」，可以挑一条历史事件或用模拟事件走一遍， 见[验证通知链路](https://n9e.github.io/zh/docs/notifications/test.md)。

## 下一步[​](#下一步 "下一步的直接链接")

* 通知规则本身怎么写：[通知规则](https://n9e.github.io/zh/docs/notifications/rules.md)
* 消息长什么样：[消息模板](https://n9e.github.io/zh/docs/notifications/templates.md)
* 发给了不该发的人：[通知发到了错误的人](https://n9e.github.io/zh/docs/troubleshooting/wrong-routing.md)
* 各机制的先后顺序：[降噪与路由模型](https://n9e.github.io/zh/docs/concepts/noise-routing.md)