滴滴夜鶯監控釋出 v5 正式版，定位 Prometheus 企業版

大家好，經過幾個月的研發，夜鶯 v5 正式版跟大家見面了，這個版本做了巨大的產品定位調整，不再是一個運維平臺，而是專注監控告警這個細分領域，擁抱 Prometheus 生態，爭取把監控這個事情，做到極致！這是新版的截圖，給大家一個直觀的認識先。

這個版本的功能設計全部是圍繞監控告警來的，比如告警規則、遮蔽規則、訂閱規則的管理，活躍告警、歷史告警的檢視，監控資料檢視，提供不同的看圖視角，監控物件的管理，告警自愈機制，人員許可權等等

為啥開始擁抱 Prometheus 生態呢？

核心是 PromQL 的能力，作為一款完備的監控產品，一定要具備 QL 的能力，否則靈活性將大大降低，之前 Open-Falcon 或者 Nightingale 的老版本，只能通過標籤做匹配，靈活性不好，需要把一些計算邏輯前置到採集側，新版本我們想解決這個問題，但是重複造輪子也不可取，所以就沿用了 PromQL 的能力。

這個版本非常的開放，不止可以和 Prometheus 深度整合，也可以和 Telegraf、Grafana、Grafana-Agent、Datadog-Agent、VictoriaMetrics、M3DB 等良好協同，沒有軟體繫結問題。

與 Open-Falcon 的區別

因為開發 Open-Falcon 和 Nightingale 的是一撥人，所以很多社群夥伴會比較好奇，為何要新做一個監控開源軟體。核心點是 Open-Falcon 和 Nightingale 的差異點實在是太大了，Nightingale 並非是 Open-Falcon 設計邏輯的一個延續，就看做兩個不同的軟體就好。

Open-Falcon 是 14 年開發的，當時是想解決 Zabbix 的一些容量問題，可以看做是物理機時代的產物，整個設計偏向運維視角，雖然資料結構上已經開始設計了標籤，但是查詢語法還是比較簡單，無法應對比較複雜的場景。

Nightingale 直接支援 PromQL，支援 Prometheus、M3DB、VictoriaMetrics 多種時序庫，支援 Telegraf 做監控資料採集，支援 Grafana 看圖，整個設計更加雲原生，雖然也保留了機器歸組的邏輯以應對物理機時代的需求，但是設計上，更傾向於使用標籤來分組，而不是 HostGroup 或者樹形結構。

與 Prometheus 的區別

Nightingale 可以簡單看做是 Prometheus 的一個企業級版本，把 Prometheus 當做 Nightingale 的一個內部元件 - 時序庫，當然，也不是必須的，時序庫除了 Prometheus，還可以使用 VictoriaMetrics、M3DB 等。各種 Exporter 也可以繼續使用，不過我們更推薦使用 All-in-one 的 Telegraf，運維代價會更小一些。

Nightingale 可以接入多個 Prometheus/M3DB/VictoriaMetrics，可以允許使用者在頁面上配置告警規則、遮蔽規則、訂閱規則，在頁面上檢視告警事件，配置告警自愈機制，管理監控物件，配置監控大盤等，就把 Nightingale 看做是 Prometheus 的一個 WEBUI 也是可以的，不過實際上，它遠遠不止是一個 WEBUI，用一下就會深有感觸。

夜鶯 v5 版本架構

夜鶯 v5 的設計非常簡單，核心是 server 和 webapi 兩個模組，webapi 無狀態，放到中心端，承接前端請求，將使用者配置寫入資料庫；server 是告警引擎和資料轉發模組，一般隨著時序庫走，一個時序庫就對應一套 server，每套 server 可以只用一個 server 例項，也可以多個例項組成叢集，server 可以接收 Telegraf 上報的資料，寫入後端時序庫，週期性從資料庫同步告警規則，然後查詢時序庫做告警判斷。每套 server 依賴一個 redis。架構圖如下：

新版本的文件放到了 gitee.io，地址是 https://n9e.gitee.io/ 感謝開源中國提供的平臺，訪問速度挺快的 :)