夜鶯監控（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，事件級別全選，然後其他所有過濾條件都不設定。