# 通知规则

按标签和级别匹配事件，再决定走哪个媒介、用哪份模板、发给谁。

最后校对于 2026-10-10

这页办完你会得到：一条能用的通知规则——S1 走一个媒介、S3 走另一个， 挂到告警规则上之后事件真的能送出去，并且你在保存之前就已经收到过一条测试消息。

## 1. 新建一条通知规则[​](#1-新建一条通知规则 "1. 新建一条通知规则的直接链接")

**告警通知 → 通知规则**，右上角 **新增**。

![通知规则](https://n9e.github.io/zh/img/docs/notifications/notify-rules.zh.webp)![通知规则](https://n9e.github.io/zh/img/docs/notifications/notify-rules.zh.dark.webp)

表单分三块：**通知配置**（核心）、**基础配置**、**事件处理工作流**（可选）。 先跳过基础配置——名称会在你选完媒介和接收团队之后自动生成。

## 2. 填第一条通知配置[​](#2-填第一条通知配置 "2. 填第一条通知配置的直接链接")

| 字段              | 说明                                                                                                                          |
| ----------------- | ----------------------------------------------------------------------------------------------------------------------------- |
| 通知媒介          | 从已有媒介里选。没有合适的就先去[通知媒介](https://n9e.github.io/zh/docs/notifications/dingtalk-feishu-wecom.md)建一个        |
| 消息模板          | 选完媒介才出现，只列出媒介类型相同的模板；默认自动选中第一个。FlashDuty、PagerDuty 和「回调」类媒介不显示这一项，它们不走模板 |
| 媒介参数          | 随媒介变化：钉钉是 Access Token + Bot Name，企业微信是 Key，回调是 Callback Url                                               |
| 接收人 / 接收团队 | 只有媒介配了「联系方式」才出现（邮件、短信、电话这类）。两者不能同时为空                                                      |

群机器人类的媒介（钉钉、企业微信、飞书卡片）**没有接收人**——消息发到群里， 谁在群里谁收得到；要指定接收人得靠模板里的 @。

预期结果：填完媒介和接收团队，上方的**名称**会自动变成「媒介名-团队名」，可以改。

## 3. 收紧筛选条件[​](#3-收紧筛选条件 "3. 收紧筛选条件的直接链接")

通知配置里有一块折叠的**筛选条件**，四项都是「与」的关系：

| 筛选项   | 留空的含义                                                                     |
| -------- | ------------------------------------------------------------------------------ |
| 适用级别 | **不是不限制，是一条都不匹配**。三个都不勾等于停用这条通知配置                 |
| 适用时段 | 不限制。可以加多组「星期 + 起止时间」，跨零点（如 21:00–09:00）也支持          |
| 适用标签 | 不限制。按事件标签筛，比如 `env=prod`                                          |
| 适用属性 | 不限制。按事件属性筛：业务组、数据源、告警规则、告警等级、是否恢复、机器业务组 |

标签和属性的区别：标签是告警数据自带的维度（`instance`、`job`、你自己打的）， 属性是夜莺给事件加的元信息。

## 4. 保存前先测一下[​](#4-保存前先测一下 "4. 保存前先测一下的直接链接")

每条通知配置右上角有 **通知测试**。两种模式：

* **使用模拟事件**：发一条内置的假事件，**不校验筛选条件**，纯粹验证「地址通不通、密钥对不对」。新环境用这个。
* **选择历史事件**：挑几条真实发生过的事件，会按筛选条件校验一遍，不匹配就直接报错——顺便验证了你的筛选写得对不对。

预期结果：弹窗里显示目标返回的响应，同时你的群/邮箱里真的多出一条消息。 两者缺一都算没通过，详见[端到端测试一条通知](https://n9e.github.io/zh/docs/notifications/test.md)。

## 5. 挂到告警规则上[​](#5-挂到告警规则上 "5. 挂到告警规则上的直接链接")

通知规则自己不会跑。回到 **告警通知 → 规则管理**，编辑一条告警规则， 在 **通知规则** 字段里选中它，保存。

一条告警规则可以挂多条通知规则；一条通知规则也可以被很多告警规则挂。 改通知规则**只对之后产生的事件生效**，不会重发历史事件。

想知道一条通知规则现在被谁用着、发出去过什么，在通知规则列表里点它的名字进详情页， 三个 tab 分别是：**事件列表**（这条规则通知过的事件）、**告警规则**（哪些告警规则挂了它）、 **订阅规则**（哪些订阅用了它）。

## 授权团队决定谁能看到这条规则[​](#授权团队决定谁能看到这条规则 "授权团队决定谁能看到这条规则的直接链接")

**基础配置**里的**授权团队**不是接收人，是权限：只有这些团队里的用户能在列表里 看到、编辑这条规则。管理员能看到全部。

接收人是在通知配置里单独选的，两者不是一回事。

## 事件处理工作流（可选）[​](#事件处理工作流可选 "事件处理工作流（可选）的直接链接")

通知规则上可以挂一条或多条[事件 Pipeline](https://n9e.github.io/zh/docs/events/pipelines.md)，在发送之前对事件 做加工——补标签、改字段，或者直接丢弃。它跑在筛选条件之前，所以工作流写出来的标签， 「适用标签」是能匹配到的。

注意告警规则上也能挂工作流，那一份影响所有下游；这里这一份只影响这条通知规则。

## 几条经验[​](#几条经验 "几条经验的直接链接")

* **按「谁值班 + 多急」拆规则，不要按数据源拆。** 例如 `pay-prod-critical`（S1，电话 + 钉钉）、`pay-prod-warning`（S2，钉钉）、 `default-all`（兜底）。
* **兜底规则要真的存在。** 新建告警规则时忘了选通知规则，事件就只在事件列表里躺着。
* **不要为每个群建一个媒介。** 媒介只描述「怎么发」，群的 token 填在通知规则里。
* **个人免打扰做不到。** 筛选全在规则层，用户没法自己屏蔽某类通知；真有需求就多建一条规则。

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

* 改消息文案：[模板与变量](https://n9e.github.io/zh/docs/notifications/templates.md)
* 让另一个团队也收到同样的事件：[订阅规则](https://n9e.github.io/zh/docs/events/subscriptions.md)
* 变更窗口内别吵：[屏蔽规则](https://n9e.github.io/zh/docs/events/mute-rules.md)
* 规则配好了却收不到：[有告警事件，为什么收不到通知？](https://n9e.github.io/zh/docs/troubleshooting/no-notification.md)