# 订阅规则

让一个团队接收不属于自己的规则产生的事件，用自己的媒介和级别筛选。

最后校对于 2026-10-10

这页办完你会得到：一条订阅规则，让你的团队收到别人业务组的告警， 用**你自己的**通知规则去发，而不用去改人家的配置。

入口：**告警通知 → 规则管理**，顶部切到 **订阅规则** tab（`/alert-subscribes`）。

![订阅规则列表](https://n9e.github.io/zh/img/docs/events/subscriptions.zh.webp)![订阅规则列表](https://n9e.github.io/zh/img/docs/events/subscriptions.zh.dark.webp)

## 1. 新建订阅[​](#1-新建订阅 "1. 新建订阅的直接链接")

点 **新增**。表单顶部先给了三类典型场景，正好是这个功能的全部用途：

* **订阅别人的告警**：依赖的下游服务归别的团队管，但故障会影响我，我想收到它们的 SLI 告警；
* **告警升级兜底**：持续 1 小时未恢复的告警，额外通知一份给团队负责人；
* **全局回调**：所有告警事件都回调一个 Webhook 做自动化。

![订阅规则表单](https://n9e.github.io/zh/img/docs/events/subscribe-form.zh.webp)![订阅规则表单](https://n9e.github.io/zh/img/docs/events/subscribe-form.zh.dark.webp)

## 2. 筛选配置：哪些事件算数[​](#2-筛选配置哪些事件算数 "2. 筛选配置：哪些事件算数的直接链接")

各项之间是「且」，**全部留空表示命中所有告警事件**（表单会黄条提示）。

| 字段                     | 说明                                                          |
| ------------------------ | ------------------------------------------------------------- |
| 数据源类型               | 留空 = 不限                                                   |
| 订阅事件等级             | 必填，至少勾一个。三个都不勾 = 什么都匹配不到                 |
| 订阅告警规则             | 点「选择告警规则」逐条挑别人的规则；不选 = 不按规则限制       |
| 订阅业务组               | 用 `in` / `not in` 指定要订阅哪几个**源业务组**的事件         |
| 订阅事件标签键           | 和屏蔽规则同样的六种操作符：`==` `!=` `=~` `!~` `in` `not in` |
| 订阅事件持续时长超过(秒) | 留空或 0 = 不限制                                             |

**持续时长**是告警升级的关键字段。填 3600 的意思是：事件第一次命中这条订阅时不发， 之后每次匹配都算一遍「本次触发时刻 − 首次命中时刻」，超过 3600 秒才真正走通知。 配一条「超过 1 小时通知给负责人」的订阅，就有了兜底。

订阅是按**标签**过滤的，所以精细订阅的前提是源规则打了合适的标签。 在告警规则的附加标签里补上 `app`、`team` 这类业务维度，订阅侧才筛得动， 见[标签、附加信息与级别](https://n9e.github.io/zh/docs/alerting/labels-severity.md)。

## 3. 通知配置：用谁的通知规则发[​](#3-通知配置用谁的通知规则发 "3. 通知配置：用谁的通知规则发的直接链接")

**通知配置** 段里点 **选择通知规则**，至少选一条——命中的事件按你选的通知规则再通知一次。 不选就等于配了订阅但没人收得到，保存时会拦下来。

这里选的是**你自己的**通知规则，所以媒介、消息模板、适用级别、适用时段全归你定， 源规则的所有者不需要知道有谁订阅了它。写通知规则见[通知规则](https://n9e.github.io/zh/docs/notifications/rules.md)。

最后填 **订阅名称**（会按上面的配置自动生成一个，可改）和 **启用** 开关。

## 4. 保存并验证[​](#4-保存并验证 "4. 保存并验证的直接链接")

底部除了 **创建** 还有 **测试**：拿已经发生过的事件跑一遍这条订阅的匹配条件， 在生效前确认它命中的是你想要的那些。

保存后回到列表，确认 **启用** 是开的。真正验证要等一条符合条件的事件产生—— 去[活跃事件](https://n9e.github.io/zh/docs/events/active-historical.md)打开那条事件的**通知记录**， 应该能看到按你的通知规则发出去的那一条。

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

语义是「**我也想收到符合这些条件的事件**」：

* 源规则原本的接收人**照常**收到他们那份，订阅方**另外**收到一份。 同一个人同时在两边，会收到两份内容相同的通知；
* 订阅产生的这一份**不会再触发一次自愈脚本**——自愈只挂在源规则上跑一次；
* 订阅规则归属你的业务组，但订阅的是**别的**业务组的事件， 两者的关系见[业务组与权限边界](https://n9e.github.io/zh/docs/concepts/business-groups.md)。

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

* **筛不到，先看源事件的真实标签。** 订阅的标签条件是「与」，少一条就过不了。 去活跃事件里打开那条事件，逐项对着看。
* **别忘了「订阅业务组」。** 只写标签条件、不限定源业务组，很容易把全公司同名标签的 事件都订过来。
* **订阅会放大风暴。** 源侧一次爆发几百条，订阅侧就跟着几百条。接收方用团队而不是个人， 并用「持续时长」把短暂抖动挡在外面。
* **停用比删除安全。** 排查「谁在给我发这些」的时候，先把订阅关掉观察一轮，再决定删不删。

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

* 反过来，想让某类告警别吵：[屏蔽规则](https://n9e.github.io/zh/docs/events/mute-rules.md)
* 订阅出来的事件走哪条通知路径：[条件路由](https://n9e.github.io/zh/docs/events/routing.md)
* 各机制的先后顺序：[降噪与路由模型](https://n9e.github.io/zh/docs/concepts/noise-routing.md)
* 订阅了却收不到：[有告警事件，为什么收不到通知？](https://n9e.github.io/zh/docs/troubleshooting/no-notification.md)