屏蔽规则

夜莺监控（Nightingale）中的屏蔽规则（菜单入口：告警-规则管理-屏蔽规则TAB）通常用于下面的场景：

• 提前屏蔽掉预期内的告警，典型的就是做一些维护动作，比如某个机器要重启，提前屏蔽这个机器相关的告警
• 有些问题急忙修复不了，已经知悉，持续告警通知也没意义，就先临时屏蔽掉

原理 #

告警事件经由告警引擎产生后，在持久化到 DB 之前，会先经过屏蔽规则的判断，如果匹配了屏蔽规则，就不会持久化到 DB，更无法通知用户。工作时机如下图：

屏蔽规则，本质上就是配置了一堆过滤条件，用于过滤想要屏蔽的告警事件。如何过滤呢，显然，就是根据告警事件的属性和标签来过滤。比如：

• 事件是哪个数据源产生的
• 事件的级别
• 事件的标签

比如下面的例子：

• 数据源类型：Prometheus，只有数据源类型是 Prometheus 的告警事件，才会被屏蔽
• 数据源：没配，表示不做限制
• 事件等级：三个级别都勾选了，表示所有级别的告警事件都要被屏蔽
• 事件标签：配置了两个标签，相当于：ident in ("10,1.2.3", "10.1.2.4") and rulename =~ "宕机"

上面所有的过滤条件，整体是and 的关系，即所有的条件都命中了某个事件，那个事件才会被屏蔽。

FAQ #

1. 我已经配置了屏蔽规则，相关告警事件为啥还是可以看到？

通常是因为：事件先产生了，才去配置的屏蔽规则。屏蔽规则是事后补救的，不能对已经产生的事件起作用。

2. 事件标签里的多个条件也是 and 关系，但是用户没有理解

如下图，用户在事件标签过滤那里，配置了两个条目，标签 key 都是 ident：

用户的本意是 10.1.2.113 和 10.1.2.114 这俩机器任意一台都要被屏蔽，但是事与愿违，这里是 and 的关系，相当于是：ident = "10.1.2.113" and ident = "10.1.2.114"，显然，这个条件永远不会命中任何事件。实际上，用户应该使用 in 操作符，如下所示：

3. 屏蔽规则的生效范围，仅限当前业务组

这个其实在页面上有提示。为了避免误操作，屏蔽规则的生效范围仅限当前业务组。也就是说，屏蔽规则只能屏蔽当前业务组下的告警事件，其他业务组下的告警事件不会受影响。

即：屏蔽规则和告警规则如果在不同业务组下，屏蔽规则不会对其生效。

如果屏蔽规则是全局生效的，就会比较危险，比如某个用户随便配置了一个告警规则，过滤条件可以匹配所有告警事件，那么公司所有的告警事件都会被屏蔽。