企業級監控解決方案 Nightingale

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

Nightingale is a fork of Open-Falcon, and all the core modules have been greatly optimized. It integrates the best practices of DiDi. You can think of it as the next generation of Open-Falcon, and use directly in production environment.

GitHub地址: https://github.com/didi/nightingale

Documentation

Nightingale user manual: https://n9e.didiyun.com/

Compile

mkdir -p $GOPATH/src/github.com/didi
cd $GOPATH/src/github.com/didi
git clone https://github.com/didi/nightingale.git
cd nightingale
# export env[GOPROXY] if your network is not good
# export GOPROXY=https://mirrors.aliyun.com/goproxy/
./control build

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周邊更完善;

聯繫我們 

致謝和說明

  • Open-Falcon 是小米運維團隊開源的企業級監控解決方案,在國內廣泛使用。
  • Nightingale 採用 Apache-2.0 開源協議,Copyright © 滴滴 2020。
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章