# 降噪与路由模型

屏蔽规则、订阅、事件 Pipeline、通知规则不是并列的备选，而是按固定先后作用于事件；搞错顺序就会出现配了屏蔽仍收到告警。

最后校对于 2026-10-10

夜莺有四种「对事件动手」的机制，它们**不是并列的**，作用的时机不同。 搞错顺序，就会出现「明明配了屏蔽还是收到告警」「Pipeline 改了标签但路由没跟着变」这类问题。

## 真实顺序[​](#真实顺序 "真实顺序的直接链接")

```
规则判定出一个事件

        │

        ├─① 规则上挂的事件 Pipeline

        │     处理器按顺序执行，可以改标签、补充上下文，也可以直接丢弃事件

        │

        ├─② 屏蔽规则

        │     · 屏蔽事件与通知（默认）→ 事件根本不产生

        │     · 只屏蔽通知           → 事件照常产生和记录，只是不发

        │

        ├─③ 事件落库，订阅规则在这里把事件复制给别的团队

        │

        └─④ 逐条通知规则处理：

              ├─ 通知规则上挂的事件 Pipeline（又一次，和 ① 不是同一个）

              ├─ 按级别、标签、时段匹配

              └─ 选中媒介和消息模板，发送
```

两个容易踩的点：

* **Pipeline 在屏蔽之前跑。** 所以 Pipeline 改写出来的标签，屏蔽规则是能匹配到的。
* **Pipeline 有两处入口**：告警规则上挂一份，通知规则上还能挂一份。 前者影响所有下游，后者只影响这一条通知规则的这一次发送。

## 该用哪一个[​](#该用哪一个 "该用哪一个的直接链接")

| 你想要的效果                   | 用什么                                 |
| ------------------------------ | -------------------------------------- |
| 变更窗口内不要吵               | 屏蔽规则，选「屏蔽事件与通知」         |
| 事件要留档，但这段时间别发     | 屏蔽规则，选「只屏蔽通知」             |
| 某类事件根本不该存在           | 规则上的 Pipeline，用丢弃处理器        |
| 给事件补上负责人、机房这类信息 | Pipeline 的标签富化处理器              |
| 另一个团队也想知道这类告警     | 订阅规则                               |
| S1 打电话、S3 只进群           | 通知规则里按级别配不同媒介             |
| 同一个故障别发一百条           | 屏蔽规则，配合足够长的持续时长过滤毛刺 |

## 屏蔽的两种方式差别很大[​](#屏蔽的两种方式差别很大 "屏蔽的两种方式差别很大的直接链接")

* **屏蔽事件与通知**（默认）：命中后事件**根本不产生**。好处是干净， 代价是这段时间的历史里查不到——事后复盘会缺一块。
* **只屏蔽通知**：事件照常产生、照常记录，只是不发出去，并且会打上标记。 想事后知道「屏蔽期间到底发生了什么」，用这个。

## 订阅不是转发[​](#订阅不是转发 "订阅不是转发的直接链接")

订阅规则的语义是「**我也想收到符合这些条件的事件**」，由订阅方自己配、 自己决定走哪个媒介和级别过滤。规则的所有者不需要知道有谁订阅了它。

这和「在通知规则里多加一个接收人」是两回事：后者要改别人的规则，前者不用。

## 相关[​](#相关 "相关的直接链接")

* [屏蔽规则](https://n9e.github.io/zh/docs/events/mute-rules.md)
* [订阅规则](https://n9e.github.io/zh/docs/events/subscriptions.md)
* [事件 Pipeline](https://n9e.github.io/zh/docs/events/pipelines.md)
* [通知规则](https://n9e.github.io/zh/docs/notifications/rules.md)
* 收不到通知时顺着这条链查：[有告警事件，为什么收不到通知？](https://n9e.github.io/zh/docs/troubleshooting/no-notification.md)