滴滴內部監控系統 Nightingale 開源啦

夜鶯（Nightingale）是滴滴基礎平臺聯合滴滴雲研發和開源的企業級監控解決方案。旨在滿足雲原生時代企業級的監控需求。Nightingale 在產品完成度、系統高可用、以及使用者體驗方面，達到了企業級的要求，可滿足不同規模使用者的場景，小到幾臺機器，大到數十萬都可以完美支撐。兼顧雲原生和裸金屬，支援應用監控和系統監控，外掛機制靈活，外掛豐富完善，具有高度的靈活性和可擴充套件性。

Nightingale 在 Open-Falcon 的基礎上，結合滴滴內部的最佳實踐，在效能、可維護性、易用性方面做了大量的改進，作為集團統一的監控解決方案，支撐了滴滴內部數十億監控指標，覆蓋了從系統、容器、到應用等各層面的監控需求，周活躍使用者數千。五年磨一劍，取之開源，回饋開源。

Nightingale 採用樹狀節點導航，我們稱之為物件樹。物件樹本質上是一種對監控物件的分組管理機制，方便查詢和檢視監控物件，以及對監控物件設定監控策略等管理動作。 一棵典型的樹可從上到下描述為組織架構關係、產品服務模組關係、機房和機器掛載關係，該導航樹可根據使用者需求自行靈活定製。

監控策略應用到某個節點後，該節點下的所有子節點掛載的所有的機器都會應用這個策略，任何一臺機器觸發相關閾值都會產生告警。

監控大盤的定製做了大幅易用性改進，支援了圖表閾值，支援了圖表分類，新增圖表和排序管理都是所見即所得的方式，巡檢大盤的定製從此不再是困難。

Nightingale 是在 Open-Falcon 的基礎上衍化發展而來，Open-Falcon 作為國內使用最廣泛的監控解決方案之一，為 Nightingale 的設計開發提供了大量的借鑑意義。

與 Open-Falcon 的不同點

• 告警引擎重構：Open-Falcon 的告警策略，在監控資料推送上來的同時會觸發策略判斷，這種「推」的模式優勢是策略的判斷時效性非常高，但是不利於更高階的告警策略的支援和擴充套件，比如多條件的組合報警就很難支援。Nightingale 轉為推拉結合模式，通過推模式保證大部分策略判斷的效率，通過拉模式支援了與條件告警和 nodata 告警。
• 引入了導航物件樹：將 Open-Falcon 採用的扁平 HostGroup，轉為 Nightingale 的導航物件樹，物件樹本質上是一種對監控物件的分組管理機制，方便查詢和檢視監控物件，以及對監控物件設定監控策略等管理動作。 同時在 Nightingale 中，去除了告警模板的概念，告警策略直接與樹節點繫結，簡化設計，大幅提升靈活度和易用性。
• 索引模組升級換代：Open-Falcon 使用 MySQL 儲存 metrics 的索引資料，在擴充套件性和靈活性上存在瓶頸。Nightingale 根據監控需求，設計開發了全新的記憶體索引模組 index，查詢方式更多樣，查詢效率更高，避免了原來 MySQL 索引資料達到億級別時面臨的維護優化工作。
• 時序資料庫優化：在 Open-Falcon 儲存模組 Graph 的基礎上，引入 Facebook 的 Gorilla 壓縮方案，近期幾個小時的資料採用記憶體儲存，大幅提升資料查詢效率，長期資料仍然使用 rrdtool 資料格式儲存在硬碟上。同時進一步完善了時序資料庫的效能和穩定性。
• 告警引擎高可用改進：告警引擎 judge 模組通過心跳機制做到了故障自動摘除，再也不用擔心單個 judge 當機導致部分策略失效，需要人工介入的問題，index 模組也是採用類似方式保證可用性。
• 原生內建日誌監控功能：Nightingale 客戶端原生內建了日誌匹配和指標抽取能力，在 web 控制檯頁面上支援了日誌匹配規則的配置，同時也支援讀取目標機器特定目錄下的配置檔案的方式，讓業務指標監控更為易用。
• 可運維性增強：將 portal(falcon-plus 中的 api)、uic、dashboard、hbs、alarm 合併為一個模組：monapi，簡化了系統整體部署難度，原來的部分模組間呼叫變成程式內方法呼叫，效能更高。
• 配置檔案中心化：配置檔案做了易用性改造，抽取資料庫通用配置到 mysql.yml，抽取埠例項地址等關聯配置到 address.yml，大批配置在程式碼裡給了預設值，使得配置檔案更清晰，易於維護。

與 Open-Falcon 的相同點

• 資料模型沒有變化，仍然是 metric、endpoint、tags 的組織方式，agent 基本是可以複用的，Nightingale 中的 agent 叫 collector，融合了原來 Open-Falcon 的 agent 和 falcon-log-agent 的邏輯，各種監控外掛也都是可以複用的。
• 資料流向和整體處理邏輯是類似的，仍然使用靈活的推模型，分為資料儲存和告警判斷兩條鏈路。

Nightingale 架構

• collector 即 agent，可以採集機器常見指標，原生支援日誌監控，支援外掛機制，支援業務通過介面直接上報資料；
• transfer 提供 rpc 介面接收 collector 上報的資料，然後通過一致性雜湊，將資料轉發給多臺 tsdb 和多臺 judge；
• tsdb 即 open-falcon 中的 graph 元件，用於儲存歷史資料，支援配置為雙寫模式提升系統容災能力，tsdb 會把監控資料轉發一份給 index 建索引；
• index 是記憶體索引模組，替換原來的 mysql 方案，在記憶體裡構建索引，便於後續資料檢索，在檢索的靈活性和檢索效能方面大幅提升；
• judge 是告警引擎，從 monapi(portal) 同步監控策略，然後對接收到的資料做告警判斷，如滿足閾值，則生成告警事件推送到 redis 佇列；
• monapi(alarm) 從 redis 佇列中讀取 judge 生成的事件，進行二次處理，補充一些元資訊，生成告警訊息，重新推送回 redis 佇列；
• 各傳送元件，比如 mail-sender、sms-sender 等，從 redis 讀取告警訊息，傳送告警，抽象出各類 sender 是為了後續定製方便；
• monapi 整合了原來多個模組的功能，提供介面給 js 呼叫，api 字首為/api/portal，資料查詢走 transfer，去除了 open-falcon 中原來的 query 元件，api 字首為/api/transfer，索引查詢的 api 字首/api/index，於是，在前端統一搭建 nginx，即可通過不同 location 將請求轉發到不同後端；
• 資料庫仍然使用 MySQL，主要儲存的內容包括：使用者資訊、團隊資訊、樹節點資訊、告警策略、監控大盤、遮蔽策略、採集策略、部分元件心跳資訊等；

仍在進行中的工作

1. 提供監控指標聚合元件，現在的架構可以解決機器級、模組級的監控，但是叢集維度的監控指標，是需要聚合整個叢集的所有模組、機器的指標，做一些加和、求平均之類的操作，相關聚合元件，我們在緊鑼密鼓的開源過程中；
2. 與 k8s 無縫整合的工作，也在進行之中；
3. 完善更多監控外掛，之前 Open-Falcon 社群裡的很多外掛都是可以直接用的，我們會盡量補充社群沒有的外掛，並對社群已有的外掛，進行二次整理和維護，讓 Nightingale 周邊更完善；

聯絡我們

• 我們的官網是 https://n9e.didiyun.com，相關文件會首發於此。
• 您可以在 Github 上關注 Nightingale，歡迎您試用和參與社群。
• 您可以通過滴滴雲的夜鶯映象，一鍵安裝和體驗。
• 您也可新增滴滴雲小助手的微信，由小助手拉進互助交流群。

致謝和說明

• Open-Falcon 是小米運維團隊開源的企業級監控解決方案，在國內廣泛使用。
• Nightingale 採用 Apache-2.0 開源協議，Copyright © 滴滴 2020。