夜鶯監控（Nightingale）把告警分成告警+通知兩個部分，告警指的是通過規則，週期性判定，最終產生告警事件，通知指的是告警事件的後續 Pipeline 和通知流程。本章節先介紹告警部分，最終能產生告警事件咱就算成功。

告警原理

夜鶯支援兩個告警模式，普通模式和高級模式（高級模式暫未開源，後面也計劃開源）：

• 普通模式：在 PromQL 中設定告警閾值，查詢條件 和 閾值設定 在一起，沒有特殊需求的話就使用普通模式即可，這個模式就和 Prometheus 的告警邏輯是一樣的，效能比較好。不過告警恢復時要想拿到恢復時的值稍微麻煩點
• 高級模式：查詢條件 和 閾值設定 分開，如果有多個查詢條件需要做加減乘除計算，可以使用高級模式，在告警事件的現場值中會將每個查詢條件的值展示出來，在告警恢復時也可以輕鬆拿到恢復時的值

普通模式的原理

普通模式下，夜鶯會根據使用者設定的執行頻率，週期性查詢資料來源，查詢條件就是使用者設定的 PromQL，查詢方式是 instant query，即呼叫的資料來源的 /api/v1/query 介面，查到幾條資料就生成幾條告警事件。比如 PromQL 是 cpu_usage_active > 80，夜鶯拿著這個 PromQL 去查詢時序資料庫，時序資料庫返回的結果肯定是 CPU 利用率大於 80% 的那些資料點，都是觸發了閾值的資料點，所以夜鶯應該生成告警事件。

如果使用者在告警規則裡設定了大於 0 的 持續時長，此時就會更複雜一些，夜鶯會在持續時長內按照執行頻率多次執行查詢，每次都查到某個資料才生成告警；如果 持續時長 置為 0，表示只要有一次查詢到資料，就生成告警。

如果之前生成了告警事件，後來再次查詢時發現沒有資料了，此時就會生成恢復事件，畢竟查不到資料了嘛，就說明時序資料庫裡沒有資料達到閾值條件了，故而時序資料庫不再返回任何資料。針對告警恢復，還有一個高級設定叫 留觀時長，表示在恢復事件生成後，夜鶯會繼續觀察一段時間，如果在留觀時長內又查詢到資料了，就不會生成恢復事件（繼續維持告警狀態）；如果留觀時長內每次都沒有查詢到資料了，才會最終生成恢復事件。

從上文分析來看，告警恢復時，時序資料庫不返回任何資料，所以夜鶯無法拿到恢復時的值，這也是很多使用者在使用普通模式時的一個痛點。夜鶯為此設計了一個方式來解決這個問題，具體可以參考這篇文章《告警恢復時如何拿到恢復時的值？》。

高級模式的原理

高級模式下，閾值條件不放到 PromQL 裡，PromQL 中只寫過濾條件，比如 PromQL：

cpu_usage_active{cpu="cpu-total"}

這樣一來，夜鶯拿著這個 PromQL 去查詢時序資料庫，時序資料庫每次都是返回 CPU 利用率的所有資料點（效能稍差），然後夜鶯再根據使用者設定的 閾值判斷 規則，對返回的資料在記憶體裡進行判斷，如下圖所示：

高級模式和普通模式，關鍵區別是閾值判定是在 PromQL 裡進而交給時序資料庫來做，還是在夜鶯的記憶體裡來做。高級模式下，如果觸發了恢復事件，恢復事件裡的 TriggerValue 會自動填充為恢復時刻的值，相比普通模式，獲取恢復時的值更簡單。

高級模式下，還會出現一個 資料缺失 的判斷邏輯，俗稱 NoData 告警，夜鶯的行為是：週期性查詢資料來源，查到了資料，就塞到記憶體裡，下次再查詢，還查到了，那萬事大吉，如果下次再查時，某條資料沒查到，那這條資料就要告警。

功能說明

了解了原理，我們就來設定一個告警規則，演示一下如何使用夜鶯的指標告警功能。

建立入口

選單入口在 告警-規則管理-告警規則，如下圖所示：

首先要選中左側的業務組，如果沒有任何業務組需要先自行建立一個，因為告警規則可能會很多，需要分門別類管理，也需要權限管控，所以告警規則是和業務組綁定的。

業務組是一個扁平的列表，但是可以渲染成樹形結構。只要在業務組名稱中使用 / 符號，就可以渲染成樹形結構。比如 DBA/MySQL 和 DBA/Redis，就會渲染成上圖的樹形樣式。當然，前提是要在 系統設定-站點設定 選單中設定業務組展示模式為樹形，同時設定業務組分隔符為 /。

下面我們著重講解一下告警規則的各個設定項的含義。

🟢 提示：規則設定頁面，各個 form 表單旁邊都有 tooltip（就是小問號 icon，滑鼠放上去可以看到用法提示），請一定要記得看哪。

基礎設定

• 規則名稱：告警規則的名稱，比如「機器負載高」，規則名稱中可以引用變數，比如 {{ $labels.instance }}，但極為不建議這樣做，因為這樣會導致最終生成的告警事件名稱各異，想要對告警事件做聚合查看時非常不方便。
• 附加標籤：在這裡設定的附加標籤，會追加到生成的告警事件的標籤中，後續可以用於告警事件的聚合和過濾。
• 備註：對告警規則更加詳細的描述，支援設定 $labels 和 $value 等變數。

規則設定

• 資料來源：選擇資料來源類型和篩選條件，用於指定當前這條告警規則生效到哪些資料來源，因為很多公司有多套 Prometheus，這樣可以方便管理規則。
• 告警條件：就是設定 PromQL，可以在 PromQL 中做一些條件篩選和四則運算，比如這個 PromQL：http_api_request_success{region="beijing"} / http_api_request_total{region="beijing"} < 0.995 表示：求取 beijing 這個 region 的所有 HTTP 請求的成功率，如果成功率小於 99.5% 就告警。如果告警引擎通過此 PromQL 查到了資料，說明有異常點產生，如果多次查詢持續異常，最終滿足了持續時間，就會產生一個告警事件。
• 多告警條件和級別抑制：在一條告警規則中，可以新增多個 PromQL 查詢條件，此時會自動出現一個 級別抑制 的功能開關，如果打開了級別抑制開關，兩個條件同時產生告警的話，只會發送高級別的告警，會對低級別的告警進行抑制，減少打擾。
• 執行頻率和持續時長：這倆設定在頁面上都提供了 tooltip，滑鼠放上去可以看到用法提示。執行頻率就相當於 Prometheus 中的 evaluation_interval，持續時長就相當於 Prometheus 中的 for，如果持續時長為 0，表示只要有一次查詢到資料，就生成告警事件。

事件 relabel

這部分頁面上提供了說明文件，請自行查閱。在 Prometheus 中有個 relabel 機制，相信很多人都不陌生（如果之前尚未了解，可以自行 Google 一下，挺有用的一個設計），Prometheus 是針對時序資料做 relabel，夜鶯這裡是針對生成的告警事件做 relabel。

舉個場景例子，比如原本有個標籤是 instance=10.1.2.3:9090，可以通過 relabel 提取其中的 IP 資訊，生成一個新的標籤 ident=10.1.2.3，夜鶯裡的告警自癒功能是需要從告警事件中提取機器資訊的，實際就是提取的 ident 標籤的值，通過 relabel 提取機器資訊寫入 ident 標籤，方便後續做告警自癒（當前，前提是你在 Categraf 裡設定的 hostname="$ip"）。

生效設定

這部分也在頁面提供了使用說明，請自行查閱。這塊最重點的設定是生效時間段，比如某個告警規則只在白天生效，另一個告警規則只在晚上生效，就可以通過生效時間段來設定。

通知設定

老版本是在告警規則裡直接設定告警接收人和通知媒介，如果要批次修改則比較費勁。新版本把通知邏輯提取出來，抽象為通知規則，來處理告警事件產生之後的所有邏輯。後面會對通知規則做詳細介紹。

通知設定部分，其他各個欄位均有 tooltip，滑鼠放上去可以看到用法提示，這裡就不再贅述了。

告警自癒，即：告警產生之後自動去告警的機器（或指定的特定中控機）執行特定的指令碼。所謂的告警的機器，這個資訊從哪裡取？就是取自告警事件的 ident 標籤，那具體執行哪個自癒指令碼呢？就是通過通知設定下面的 告警自癒 欄位來指定。

附加資訊，就類似 Prometheus 告警規則中的 Annotations，告警事件生成之後，夜鶯會把這些附加資訊追加到告警事件中，後續可以在訊息範本中引用，最終在釘釘、飛書、郵件等通知中展示。

實操演示

為了盡快產生告警事件，我這裡設定了一個必然會觸發的 PromQL：

cpu_usage_active > 0

🟢 cpu_usage_active 這個指標是 Categraf 採集的，表示 CPU 利用率，CPU 利用率顯然必然會大於 0，所以這個規則很快就可以觸發告警事件。如果你沒有使用 Categraf，就沒有這個指標了，請使用你自己的時序資料庫中的指標來做測試。

上例中，為了加速產生告警事件，我把執行頻率設定為 15s，把持續時長設定為 0，這樣一來，夜鶯每 15s 就會查詢一次資料來源，如果查到了資料就會生成告警事件。

稍等片刻，即可發現告警規則左側的狀態欄位，變成一個紅色的驚嘆號，表示觸發了告警事件，點擊之後在側拉板可以看到這個規則產生的相關告警事件。當然，你也可以在告警事件選單看到當前的活躍告警（未恢復的告警稱為活躍告警）和所有歷史告警。

上面的第一條告警事件就是剛剛測試的，其他的事件是之前測試的，不用關心哈。告警事件產生了，說明告警規則設定的沒問題，後面就是設定通知規則了，指定什麼樣的告警事件發給誰，通過什麼通知媒介（電話、簡訊、郵件、飛書、釘釘、企微等，稱為通知媒介）來發。