条件路由

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

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

路由发生在通知规则里

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

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

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

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

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

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

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

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

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

如果分流的动机是「另一个团队也想收到这类告警」，不要去改人家的通知规则，让他们建一条订阅规则——订阅方自己决定筛什么、用哪条通知规则发，规则的所有者完全不用参与。

前三种是「送到哪里」，这一种是「不送」。在事件 Pipeline 里用 事件丢弃 处理器按条件把事件拦下来：

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

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