add mute doc

Author: UlricQin

content/zh/docs/usecase/mute.md

@@ -0,0 +1,65 @@
+---
+title: "屏蔽规则"
+description: "夜莺监控（Nightingale）中的屏蔽规则，如何配置屏蔽规则，以及相关的设计初衷。屏蔽规则可以屏蔽告警事件，避免告警事件打扰到用户。"
+date: 2025-06-23T16:50:43.795+08:00
+lastmod: 2025-06-23T16:50:43.795+08:00
+draft: false
+images: []
+menu:
+  docs:
+    parent: "usecase"
+weight: 10050
+toc: true
+---
+
+夜莺监控（Nightingale）中的屏蔽规则通常用于下面的场景：
+
+- 提前屏蔽掉预期内的告警，典型的就是做一些维护动作，比如某个机器要重启，提前屏蔽这个机器相关的告警
+- 有些问题急忙修复不了，已经知悉，持续告警通知也没意义，就先临时屏蔽掉
+
+## 原理
+
+告警事件经由告警引擎产生后，在持久化到 DB 之前，会先经过屏蔽规则的判断，如果匹配了屏蔽规则，就不会持久化到 DB，更无法通知用户。工作时机如下图：
+
+<img src="/img/usecase/mute/01.png" alt="夜莺屏蔽规则工作时机" title="夜莺屏蔽规则工作时机">
+
+屏蔽规则，本质上就是配置了一堆过滤条件，用于过滤想要屏蔽的告警事件。如何过滤呢，显然，就是根据告警事件的属性和标签来过滤。比如：
+
+- 事件是哪个数据源产生的
+- 事件的级别
+- 事件的标签
+
+比如下面的例子：
+
+<img src="/img/usecase/mute/02.png" alt="夜莺屏蔽规则配置示例" title="夜莺屏蔽规则配置示例">
+
+- 数据源类型：`Prometheus`，只有数据源类型是 `Prometheus` 的告警事件，才会被屏蔽
+- 数据源：没配，表示不做限制
+- 事件等级：三个级别都勾选了，表示所有级别的告警事件都要被屏蔽
+- 事件标签：配置了两个标签，相当于：`ident in ("10,1.2.3", "10.1.2.4") and rulename =~ "宕机"`
+
+上面所有的过滤条件，整体是`and` 的关系，即所有的条件都命中了某个事件，那个事件才会被屏蔽。
+
+## FAQ
+
+**1. 我已经配置了屏蔽规则，相关告警事件为啥还是可以看到？**
+
+通常是因为：事件先产生了，才去配置的屏蔽规则。屏蔽规则是事后补救的，不能对已经产生的事件起作用。
+
+**2. 事件标签里的多个条件也是 and 关系，但是用户没有理解**
+
+如下图，用户在事件标签过滤那里，配置了两个条目，标签 key 都是 ident：
+
+<img src="/img/usecase/mute/03.png" alt="夜莺屏蔽规则事件标签配置错误示例" title="夜莺屏蔽规则事件标签配置错误示例">
+
+用户的本意是 `10.1.2.113` 和 `10.1.2.114` 这俩机器任意一台都要被屏蔽，但是事与愿违，这里是 `and` 的关系，相当于是：`ident = "10.1.2.113" and ident = "10.1.2.114"`，显然，这个条件永远不会命中任何事件。实际上，用户应该使用 `in` 操作符，如下所示：
+
+<img src="/img/usecase/mute/04.png" alt="夜莺屏蔽规则事件标签配置正确示例" title="夜莺屏蔽规则事件标签配置正确示例">
+
+**3. 屏蔽规则的生效范围，仅限当前业务组**
+
+这个其实在页面上有提示。为了避免误操作，屏蔽规则的生效范围仅限当前业务组。也就是说，屏蔽规则只能屏蔽当前业务组下的告警事件，其他业务组下的告警事件不会受影响。
+
+即：屏蔽规则和告警规则如果在不同业务组下，屏蔽规则不会对其生效。
+
+如果屏蔽规则是全局生效的，就会比较危险，比如某个用户随便配置了一个告警规则，过滤条件可以匹配所有告警事件，那么公司所有的告警事件都会被屏蔽。