Categories
程式開發

滴滴開源夜鶯Nightingale:企業級監控解決方案


滴滴開源又雙叒發布新開源項目啦——夜鶯(Nightingale)是滴滴基礎平台聯合滴滴雲研發和開源的企業級監控解決方案。旨在滿足雲原生時代企業級的監控需求。一起來了解項目詳情吧。

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

滴滴開源夜鶯Nightingale:企業級監控解決方案 1

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

滴滴開源夜鶯Nightingale:企業級監控解決方案 2

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

滴滴開源夜鶯Nightingale:企業級監控解決方案 3

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

滴滴開源夜鶯Nightingale:企業級監控解決方案 4

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

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,可以採集機器常見指標,原生支持日誌監控,支持插件機制,支持業務通過接口直接上報數據;

  • transfe r提供 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,主要存儲的內容包括:用戶信息、團隊信息、樹節點信息、告警策略、監控大盤、屏蔽策略、採集策略、部分組件心跳信息等。

仍在進行中的工作

  • 提供監控指標聚合組件,現在的架構可以解決機器級、模塊級的監控,但是集群維度的監控指標,是需要聚合整個集群的所有模塊、機器的指標,做一些加和、求平均之類的操作,相關聚合組件,我們在緊鑼密鼓的開源過程中;

  • 與 k8s 無縫集成的工作,也在進行之中;

  • 完善更多監控插件,之前Open-Falcon 社區裡的很多插件都是可以直接用的,我們會盡量補充社區沒有的插件,並對社區已有的插件,進行二次整理和維護,讓Nightingale 周邊更完善。

本文轉載自滴滴技術公眾號。

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