订阅规则

概述

订阅规则 = 把别人业务组的告警事件订阅到自己业务组，用于跨团队的告警协作。

侧栏路径：告警 → 规则管理 → 订阅规则 Tab，URL /alert-subscribes。

适用场景：

• 业务团队订阅基础设施告警：业务团队想了解依赖的 MySQL / Redis / 网络等基础告警，但这些规则归基础设施团队管理；
• 告警升级 / 兜底：原规则配置了 30 分钟超时，超过这个时间还没恢复就升级 — 通过订阅规则的"持续时长"配上一层；
• 重新分派接收人：基础设施告警的原始接收人是基础设施团队，业务团队想让它额外发一份到本组值班；
• 改告警级别：基础设施那边觉得是 S2，业务侧觉得是 S1 — 通过订阅重新分级（不改原规则）。

和屏蔽规则的关系

维度	屏蔽规则	订阅规则
方向	减 — 让告警别发	加 — 让告警多发一份
业务组归属	绑本业务组，过滤本业务组的事件	绑本业务组，但订阅别人业务组的事件
常用动机	止吵、维护窗口	协作、告警升级、跨团队感知

表单字段

订阅规则事件满足所有条件（AND 关系）才会被订阅。

字段	必填	说明
数据源类型	否	想订阅的源类型，不填 = 不限
订阅告警规则	否	指定别人业务组的告警规则 — 不选 = 该数据源类型下所有规则
告警事件等级	否	只订阅特定级别（如只订阅 S1）
订阅事件标签	否	和屏蔽规则的标签筛选一样，6 种操作符（== / =~ / != / !~ / in / not in）
订阅业务组	否	通过 in / not in 选要订阅哪几个源业务组的事件
订阅事件持续时长	否	“事件第一次触发后多久才触发订阅”。配 3600 表示"原事件持续超过 1 小时还没恢复才订阅"，典型的告警升级用法
重新分派 - 告警级别	否	不填 = 沿用原级别；填了 = 订阅后改成新级别再分派
重新分派 - 通知媒介	否	不填 = 沿用原规则的；填了 = 用订阅规则配的媒介
重新分派 - 回调地址	否	同上
订阅接收组	否	订阅的事件发给哪些团队，这是最关键字段 — 不填这条规则相当于没接收人
通知聚合（PLUS）	否	短时间内多条订阅事件合并成一条通知发

实操：跨团队告警共享

场景：业务团队 Pay 订阅基础设施团队的 MySQL 告警 — 只看自家 app=pay-svc 的事件。

1. 进基础设施团队负责的 MySQL 告警规则，确认它在创建时附加了 app=pay-svc 这个标签（关键 — 标签是订阅过滤的依据）；
2. 切到本业务组 Pay，去订阅规则页 → 新增；
3. 字段填：
   • 数据源类型：mysql
   • 订阅事件标签：app == pay-svc
   • 订阅业务组：选基础设施团队的业务组 Infra
   • 订阅接收组：选 Pay 团队的值班组
4. 保存。从这一刻起，Infra 业务组的 MySQL 告警里凡是带 app=pay-svc 的，都会额外发一份给 Pay 团队。

实操：告警升级（超时未恢复升级到老板）

经典升级模式 — 原告警通知开发同事，30 分钟没恢复就升级到组长 + 老板：

1. 假设原告警规则在业务组 A，目标接收组是 dev-team；
2. 在业务组 A 下新建一条订阅规则：
   • 订阅告警规则：选原规则
   • 订阅事件持续时长：1800（30 分钟）
   • 重新分派 - 告警级别：S1（升一级）
   • 订阅接收组：选 manager-team
3. 效果：开发同事 30 分钟内能解决就只收到自己的告警；超过 30 分钟未恢复，订阅规则触发，组长收到 S1 升级版告警。

用"告警附加标签"做精细订阅

订阅规则的强大之处是基于标签做过滤。在原告警规则的"附加标签"里多打几个业务维度标签（如 app=flashcat、team=pay、level=critical），订阅时就能精准筛选。

例如某条 MySQL 告警规则在附加标签里写 app=flashcat，订阅规则用 app == flashcat 过滤，就只订到这一条规则的告警，不被其他 MySQL 告警干扰。

常见问题

Q1：订阅规则会让接收人收到两份告警通知吗？

A：会。原告警规则本身的接收人收到原始通知，订阅规则的接收组另外收到一份。如果同一个用户既在原接收组又在订阅接收组，他会收到两份（虽然内容相同）。注意配置避免给自己人加倍打扰。

Q2：订阅规则没生效，怎么排查？

A：按顺序：

1. 业务组：订阅规则归属本业务组，但订阅的事件来自其他业务组 — 看下"订阅业务组"字段是否选对了源业务组；
2. 标签匹配：订阅事件标签条件全部满足才命中，少一个标签就过不了。去活跃告警看源事件的实际标签，逐项对照；
3. 持续时长：如果配了"订阅事件持续时长"，事件还没持续够时间就不会触发。配 0 = 立即订阅；
4. 订阅接收组：没配接收组等于配了订阅但不发；
5. 告警引擎状态：去 告警引擎 看引擎是否健康。

Q3：通知聚合（PLUS）有什么用？

A：短时间内多条订阅事件合并成一条通知发出。例如 1 分钟内来 20 条 MySQL 慢查询告警，开启聚合后只发 1 条"20 条告警"的通知，避免轰炸。

Q4：订阅规则会"放大"告警风暴吗？

A：会，如果配置不当。注意：

• 接收人用团队而不是个人 — 团队成员可以按需调整；
• 用持续时长避免短暂抖动也触发订阅；
• 大流量场景必开通知聚合（PLUS）。

参考资料

• 屏蔽规则
• 告警规则
• 全局屏蔽（PLUS）
• 活跃告警
• 通知规则