談起當下監控，Prometheus 無疑是最火的專案，如果只是監控機器、網路裝置，Zabbix 尚可一戰，如果既要監控裝置又要監控應用程式、Kubernetes 等基礎設施，Prometheus 就是最佳選擇。甚至有些開源專案，已經內建支援了 Prometheus 協議的指標暴露，比如新版本的 Zookeeper、新版本的 RabbitMQ、Nginx vts 等等。Prometheus 的影響力可見一斑。
很多場景裡講到的 Prometheus 這個詞，其實已經不僅僅是 Prometheus 專案本身了，而是 Prometheus 生態，包括 Prometheus 定義的指標格式、傳輸協議、查詢語言、各類 Exporter 採集器、各類相容的儲存等。
在 Prometheus 生態裡，採集可以使用各類 Exporter，儲存可以使用 VictoriaMetrics，看圖可以使用 Grafana，看起來已經非常完備了，為啥又冒出一個“夜鶯（Nightingale）”的開源專案，還聲稱和 Prometheus 無縫對接？本文嘗試探討一二。
夜鶯介紹
從夜鶯官網摘出一段夜鶯專案介紹：
夜鶯監控是一款開源雲原生觀測分析工具，採用 All-in-One 的設計理念，集資料採集、視覺化、監控告警、資料分析於一體，與雲原生生態緊密整合，提供開箱即用的企業級監控分析和告警能力。夜鶯於 2020 年 3 月 20 日，在 github 上釋出 v1 版本，已累計迭代 100 多個版本。
夜鶯最初由滴滴開發和開源，並於 2022 年 5 月 11 日，捐贈予中國計算機學會開源發展委員會（CCF ODC），為 CCF ODC 成立後接受捐贈的第一個開源專案。夜鶯的核心研發團隊，也是 Open-Falcon 專案原核心研發人員，從 2014 年（Open-Falcon 是 2014 年開源）算起來，也有 10 年了，只為把監控這個事情做好。
- 後端程式碼：https://github.com/ccfos/nightingale
- 前端程式碼：https://github.com/n9e/fe
看完專案介紹，只能知道夜鶯是一個監控系統，到底和 Prometheus 有哪些差異點，暫時沒有看出來。別急，我們先來看看 Prometheus 的問題。
Prometheus 的問題
Prometheus 的採集、儲存、看圖都已經解決的挺好了。唯獨就是告警，對某些公司來講，可能會有如下痛點：
- 一個公司有很多套 Prometheus，規則分散在多個 yaml 中不方便管理
- 希望能有一套易用的、許可權隔離的 UI，把監控能力開放給全公司各個團隊並讓他們自服務，別啥事都來找監控團隊
- 直接使用 Promql 查詢資料、配置告警規則要求有點高，能否內建一些規則庫、查詢語句，讓知識可沉澱，讓普通使用者也能開箱即用
- 告警規則希望能夠更靈活一些，比如支援不同的規則不同的生效時間，能夠內建提供一些告警自愈的機制等等
夜鶯就是為此而生的。其實夜鶯老版本是自成體系的，脫胎自 Open-Falcon，但是隨著 Prometheus 大勢起來，夜鶯就開始擁抱 Prometheus 生態了。可以把夜鶯看做是時序資料的告警引擎。當然，夜鶯也提供看圖、儀表盤的能力，甚至可以檢視 Elasticsearch、Loki、TDEngine 的資料，不過當前現狀就是夜鶯的告警能力大家用的最多，儀表盤大都仍然使用 Grafana 居多。典型的夜鶯使用的架構如下：
可以用夜鶯完全替代 Prometheus 嗎？
其實不是替代的關係，是協同的關係。在夜鶯看來，Prometheus 主要是作為時序庫使用，除了 Prometheus 這個時序庫，還可以選擇 VictoriaMetrics、Thanos、M3DB、TDEngine 等其他時序庫。夜鶯呢，則只是作為一個時序庫的告警引擎，既可以對接 Prometheus，也可以對接其他時序庫，使用者在夜鶯裡統一管理告警規則，對異常資料做判定，產生告警事件，並做後續分發通知、告警自愈等邏輯。
另外，如果你有多個機房，時序庫分散在多個機房，機房之間的網路不好，即便發生網路割裂你也希望邊緣機房能夠自治不影響告警，夜鶯也非常合適。這種情況夜鶯稱為邊緣機房部署模式，時序庫和告警引擎下沉部署，網路斷了也沒事，網路好的時候還可以在中心端統一檢視資料，統一管理告警規則，其架構圖如下：
上例中，演示了 3 個機房的部署架構，其中機房 A 和中心機房之間網路鏈路很好，機房 B 和中心機房之間的網路鏈路不太好，各個機房都有時序庫。所以，中心機房的夜鶯告警引擎直接處理中心機房和機房 A 的時序庫，機房 B 的時序庫由機房 B 的告警引擎處理，也就是圖中的 n9e-edge，n9e-edge 會從中心機房的夜鶯同步告警規則，然後對本機房的時序庫做告警判定。
這樣一來，即便機房 B 和中心機房之間網路割裂，由於 n9e-edge 記憶體中早就同步到了告警規則，所以機房 B 的告警引擎還是可以正常處理機房 B 的兩個時序庫的告警判定工作。提升了監控系統整體高可用性。
什麼場景用夜鶯而非 Prometheus？
關鍵看你的痛點是什麼。如果現階段使用單點的 Prometheus 也可以很好的解決你的問題，完全沒必要換，在任何公司，技術工具的遷移都是會受到各種阻力的，懂的自然懂。
如果你有告警規則管理的痛點、邊緣機房告警高可用的痛點，那可以嘗試一下夜鶯。任何工具都有自己的優缺點，根據場景選擇。
夜鶯可以接收各類監控系統的告警統一做事件通知嗎？
有些朋友看到夜鶯可以對接各類時序庫，做告警判斷生成告警事件並分發，就想說，那我其他的監控系統產生的告警能否也交給夜鶯去傳送呢？這樣就可以統一管理告警通知模板、聯絡人、認證登入許可權等問題。
實際是不行的。這是一個典型的事件 OnCall 需求，收集各個監控系統（比如 Prometheus、Zabbix、Open-Falcon、藍鯨、各類雲監控、ElastAlert 等）的告警，統一做告警收斂降噪、排班、認領升級、按條件靈活分發等，這個需求要想做好，值得用一個單獨的產品來搞，我們姑且稱這個產品為 OnCall 產品。OnCall 產品和各個監控系統之間的關係是：
即：監控系統（包括各類雲監控）重點把資料採集、儲存、視覺化分析、告警判定這些問題解決好，負責產生告警事件，之後告警事件就交給 OnCall 中心來處理即可，OnCall 中心來負責告警事件的收斂降噪、抑制遮蔽、過濾分發等等諸多事宜。
好的 OnCall 產品都是商業產品，比如 PagerDuty、FlashDuty、Opsgenie 等，大家可以自行 Google，各取所需。
夜鶯比 Prometheus 還多了啥有意思的功能？
這裡我隨便截幾張系統圖，略作介紹。
夜鶯不做採集，可以對接市面上各類採集器，其中，categraf 採集器和夜鶯的對接最為絲滑，使用 categraf 作為採集器的話，可以採集機器的各類元資訊，構建一個輕量的機器層面的 CMDB。
夜鶯內建提供告警自愈的能力，即告警時可以自動到告警的機器上執行指令碼，你可以在指令碼里寫一些自動化的修復邏輯。
夜鶯內建提供了指標檢視，會在 v7 beta3 版本放出，會內建提供很多常用的 promql，點選查詢即可，對小白使用者會極為友好。
小結
已經有 Prometheus 了，為啥還需要夜鶯（Nightingale）？本文算是對這個問題的一個探索性回覆。希望對你有幫助，感謝大家的閱讀。