订阅规则

夜莺监控（Nightingale）中的订阅规则，其菜单入口在：告警-规则管理-订阅规则TAB。

为何有此设计 #

夜莺的告警规则中，可以直接配置通知规则，很直观，这个告警规则产生的告警事件就走这个通知规则。Datadog、Open-Falcon 都是类似这样的设计，基本是够用的。但是如果你了解 Zabbix、Prometheus，你会发现，它们产生告警事件之后，要发给谁，其实走的是一个后续订阅的逻辑，即：

• 告警规则中，只定义查询条件、阈值等，即告警规则仅是负责事件产生，至于如何通知、通知给谁，告警规则不管这些
• 用户使用订阅的机制，从所有告警事件中做筛选，对这些筛到的告警事件，指定相关的通知规则（通知给谁、如何通知）

这种方式实际上更灵活，缺点就是不够直观。夜莺呢？两种方式都支持，对于普通用户，优先建议使用“在告警规则中直接配置通知规则”的方式，把“订阅规则”，用在一些相对少见的场景，比如：

• 我的服务依赖了其他服务，这些服务不归我管（这些服务的告警规则通知给它们的负责人，而不是通知给我），但是这些服务如果故障，可能会影响我的服务，所以我希望订阅这些服务的 SLI 相关的告警事件（这是社区某些用户提到的需求场景，虽然写在这里，但是笔者实际不认可请你自行斟酌，笔者认为，每个服务都应该制作一个仪表盘，仪表盘里罗列了依赖的其他服务的 SLI 数据，自己的服务出故障时，应该统一去看这个仪表盘来判断是自身的问题还是依赖的下游服务的问题）
• 某些通用告警规则产生的告警事件，希望分发给不同的人，此时没法在告警规则中直接绑定通知规则，此时可以搭配订阅规则来实现
• 一些全局的操作，比如全局回调，可以通过订阅规则来实现。比如希望：对于系统产生的任何一条告警事件，都要回调某个 Webhook 地址，此时可以配置一个全局的订阅规则，匹配所有的告警事件，然后配置一个 Webhook 通知规则。

💡 请认真阅读上面这段文字，理解订阅规则的设计初衷。非常非常非常重要。

配置方法 #

订阅规则包含三部分配置：

• 名称：订阅规则的名称，建议使用有意义的名称，让别人一眼看到就知道这个订阅规则是干什么用的，方便维护
• 筛选配置：各个维度筛选告警事件，注意，是筛选告警事件，筛选到的这些告警事件，就会走下面的通知规则
• 通知规则：筛选到的告警事件，走这些通知规则

整体逻辑比较清晰，其中筛选配置的配置项较多，下面逐一介绍。

• 数据源类型：用于筛选告警事件是经由哪个数据源类型产生的
• 数据源：用于筛选告警事件是经由哪个数据源产生的
• 事件等级：用于筛选告警事件的级别，可以选择多个级别，默认全选，相当于 severity in ("Info", "Warning", "Critical")，全选其实就相当于在“事件等级”这个维度上不做筛选过滤
• 订阅告警规则：用于筛选告警事件是哪个告警规则产生的
• 业务组：用于筛选告警事件是哪个业务组产生的，告警事件肯定是某个告警规则触发的，所以告警事件的业务组就是告警规则所属的业务组（当前版本是v8.0.0，后续会考虑优化这个地方，后续会同时考虑告警事件中的机器所属的业务组）
• 事件标签：用于筛选告警事件的标签，注意运算符的用法，具体解释放在下面
• 订阅事件持续时长：右侧有个小问号的 icon，提供了这个功能的使用说明，这里不再赘述。

上面的各个筛选条件，不同的条目之间整体是 and 的关系，其中事件标签这部分可以配置多个过滤条目，不同条目之间也是 and 的关系，如果你想匹配多个标签值，可以使用 in 操作符，或者使用正则表达式 =~。

对于运算符，具体解释如下：

• == 匹配某个具体的标签值，只能填写一个，如果想同时匹配多个，应该使用 in 操作符
• =~ 填写正则表达式，灵活匹配标签值
• in 匹配多个标签值，类似 SQL 里的 in 操作
• not in 不匹配的标签值，可填写多个，类似 SQL 里的 not in 操作，用于排除多个标签值
• != 不等于，用于排除特定的某个标签值
• !~ 正则不匹配，填写正则，匹配这个正则的标签值都将被排除，类似 PromQL 中的 !~

场景举例：订阅所有时序告警 #

比如我想订阅所有时序指标相关的告警，然后统一走一个 Webhook 通知规则，用于一些自动化处理逻辑。此时可以配置数据源类型为 Prometheus，事件级别全选，然后其他所有过滤条件都不配置。