夜鶯監控（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. 抑制規則的生效範圍，僅限當前業務組

這個其實在頁面上有提示。為了避免誤操作，抑制規則的生效範圍僅限當前業務組。也就是說，抑制規則只能抑制當前業務組下的告警事件，其他業務組下的告警事件不會受影響。

即：抑制規則和告警規則如果在不同業務組下，抑制規則不會對其生效。

如果抑制規則是全域生效的，就會比較危險，比如某個使用者隨便設定了一個告警規則，過濾條件可以符合所有告警事件，那麼公司所有的告警事件都會被抑制。