本文從原理和資料流的角度，介紹夜鶯監控的告警引擎的相關知識，幫助使用者理解告警流程，排查告警問題。
夜鶯監控（Nightingale）的功能側重點是告警引擎，為了做得靈活，整個告警流程涉及到的功能點比較多，本文從原理和資料流的角度，介紹一下相關知識，理解這些知識，對於您使用夜鶯、排查告警問題，都會有幫助。
資料流原理概述
- 使用者在 Web UI 設定告警規則，規則儲存在 DB 中（通常是 MySQL）。
- 告警引擎（
n9e行程內建一個告警引擎，邊緣模式下n9e-edge行程裡也內建告警引擎）從 DB 同步告警規則到記憶體中（通常n9e-edge無法直接讀 DB，是呼叫的中心端n9e的介面取得的告警規則）。 - 告警引擎會為每條告警規則建立一個 goroutine（協程，姑且可以理解為輕量級執行緒），按照使用者在告警規則裡設定的頻率，週期性查詢儲存，對資料做異常判定，最終產生告警事件。
- 產生告警事件後，要先持久化到 DB 中（通常是 MySQL），然後再走後面的通知規則。
- 通知規則包含兩部分，一個是若干事件處理器（比如 relabel、event update、event drop、ai summary 等），另一個是若干告警通知設定（比如 Critical 的告警事件關聯電話、簡訊通知媒介，Warning 的告警事件只關聯郵件媒介）。
告警規則
告警規則核心就是設定一個查詢條件，比如 Prometheus 資料來源就是設定 PromQL，ClickHouse 資料來源就是設定 SQL，然後再設定一個閾值（Prometheus 場景下，閾值包含在 PromQL 中，不需要單獨設定），達到閾值並滿足持續時長，就告警。
告警引擎針對每條規則建立一個 goroutine（協程），週期性地查詢資料來源，判斷是否滿足告警條件。以 Prometheus 資料來源舉例，其原理是：
- 夜鶯週期性呼叫資料來源的
/api/v1/query介面，把當前時間和 PromQL 作為查詢條件傳給這個介面。 - 資料來源如果回傳多條記錄，大概率就要產生多條告警事件，接下來要看持續時長，如果持續時長為 0，立馬產生告警事件，如果持續時長大於 0，就要把這條記錄放到一個快取中，等到持續時長滿足條件後，再產生告警事件，在持續時長過程中，如果後面的執行週期查不到資料了，就會把這條記錄從快取中刪除，也就不會產生告警事件了。
這裡經常遇到的問題是，告警引擎在查詢的時候沒有查到資料，故而無法產生告警事件，但是後面排查的時候發現那個時間點卻是有資料滿足閾值的，百思不得其解，這種情況，可能的原因有兩個：
- 因為監控資料的上報有延遲導致的，在這裡夜鶯只是一個 client，資料來源是 server，資料來源沒有回傳資料，就要去看 server 側的問題，看 server 側的資料為啥沒有回傳，通常是資料有各種因素延遲了。
- 查詢逾時了，日誌檔案裡通常可以看到相關日誌，可以在資料來源設定頁面調大查詢逾時時間，或者排查資料來源為啥回傳慢了，另外硬體方面也可能有問題，比如 client、server 兩邊是否有網路卡丟包。逾時的日誌，可以檢索關鍵字：
alert-${datasource-id}-${alert-rule-id}
其中：
${datasource-id}是資料來源的 ID，在資料來源詳情頁面可以看到${alert-rule-id}是告警規則的 ID，編輯告警規則時，在 URL 中可以看到
告警問題排查時，首先要看是否產生了告警事件，如果產生了告警事件，說明告警規則沒問題，接下來再排查後面通知相關的問題，如果告警事件都沒有產生，那就是告警規則和資料來源的問題，首先要確認告警規則的設定再談其他。
事件持久化
告警事件產生後需要寫入 DB（通常是 MySQL），於是你才能在告警事件列表中看到這個事件。有時會寫失敗，寫失敗的話在日誌裡通常會有體現，排查 WARNING 和 ERROR 日誌即可。
告警規則關聯通知規則
告警事件產生之後，應該走後續的哪個通知規則？即告警規則和通知規則如何建立關聯關係？有兩個辦法建立關聯關係：
- 告警規則裡直接設定通知規則。即這個告警規則產生的所有告警事件，都要走這些通知規則。
- 告警規則裡不配通知規則，而是設定訂閱規則，即：在訂閱規則裡按照各種條件篩選告警事件，篩選到的告警事件，走訂閱規則裡設定的通知規則。
上面兩種方式都可以，前者更直觀，如果沒有特殊需求，推薦使用前者。但是對於一些全域的事件處理，比如我想把夜鶯監控中產生的所有告警事件都走一個 Callback 處理器，此時可以使用訂閱規則，訂閱所有的告警事件，統一關聯一個全域通知規則，在這個全域通知規則裡設定 Callback 處理器。
通知規則設定
下圖是通知規則的編輯頁面，我在圖中標註了各個區塊的作用：
大部分表單項的標題位置，都有一個小問號圖示，滑鼠懸停在上面會有提示資訊，大家可以參考提示資訊來設定。
💡 這個頁面裡包含一些通知測試的按鈕，點擊之後，可以選擇已產生的告警事件做通知規則的測試，便於您快速驗證通知規則是否符合預期。另外要注意，告警事件持久化發生在通知規則之前，所以通知規則裡的各個事件處理器，不會對 DB 中的告警事件產生修改。
事件處理器
💡 事件 Pipeline 並沒有一個單獨的選單入口，作為通知規則的一部分，是在通知規則的編輯頁面裡，點擊「事件處理」區塊的小齒輪圖示可以展開事件處理器的設定側拉板。
事件處理器是一個進階機制，允許您對告警事件做各種處理，比如：
- 對告警事件做 relabel，拆分一些標籤，修改一些標籤等
- 更新告警事件，夜鶯把告警事件傳給第三方（比如 CMDB）介面，第三方可以對告警事件做修改，然後把修改之後的內容回傳，繼續走後續事件處理邏輯，方便與外部系統做打通
- 丟棄告警事件，一些告警事件不需要通知，可以在這裡做複雜的判斷，符合條件的丟棄掉
- 產生 AI 摘要，把告警事件傳給 DeepSeek 等，讓 AI 幫忙產生摘要和解法，把 AI 產生的內容放到事件中，後續透過通知媒介發出來
這裡有兩個概念要注意：
- 事件處理的 Pipeline，就是點擊
通知規則-事件處理右側那個按鈕展開的側拉板，裡邊就是 Pipeline 的列表 - 每個 Pipeline 可以包含多個 Processor（處理器），如果想提高複用性，也可以簡單來搞，每個 Pipeline 只包含一個 Processor。
每個處理器，頁面上都有一個文件說明連結，點擊之後可以查看詳細的文件說明。也可以參考下面兩個連結的資料：
通知設定
這部分在前面已經講解過，這裡不再贅述，請參考：
FAQ
如何匯入 Prometheus 告警規則？
Prometheus 生態有很多人分享了告警規則，比如這個專案：
每個目錄下都是 yaml 格式的告警規則，比如 host-and-hardware 目錄下就是常見的 node-exporter 的告警規則。想要把這些規則直接匯入夜鶯？請參考如下操作。
版本說明
請使用夜鶯 v8.2.0 以上的版本。
匯入步驟
如上截圖。在告警規則頁面選擇匯入，即可匯入 Prometheus 格式的告警規則。注意那個 yaml 格式的規則內容，一開始是 groups，包含多個 group，每個 group 有 name 和 rules，rules 也是一個陣列，裡面是具體的告警規則。夜鶯處理的時候會忽略 group 的 name，直接將 rules 中的內容匯入。
匯入完成之後，通常需要關聯通知規則，才能做告警通知。方法是：批次選中告警規則，然後點擊右上角的更多操作，批次更新告警規則：
在批次更新的彈層裡，欄位選擇為：通知規則，然後選擇對應的通知規則，點擊確定即可，截圖如下：
常見問題
Q1：告警太多漏看怎麼辦？
A：
Q2：怎麼避免告警風暴？
A：
