夜鶯監控Nightingale

【編者的話】滴滴發布新開源項目——夜鶯（Nightingale），是滴滴基礎平台聯合滴滴雲研發和開源的企業級監控解決方案。旨在滿足雲原生時代企業級的監控需求。

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

GitHub 地址： https://github.com/didi/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，主要存儲的內容包括：用戶信息、團隊信息、樹節點信息、告警策略、監控大盤、屏蔽策略、采集策略、部分組件心跳信息等。

仍在進行中的工作

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

致謝和說明

Open-Falcon 是小米運維團隊開源的企業級監控解決方案，在國內廣泛使用。

原文鏈接： https://mp.weixin.qq.com/s/zvHQVBgU2IFUUYyzeDlokw