夜鶯（Nightingale）是一個企業(yè)級監(jiān)控解決方案。旨在滿足云原生時代企業(yè)級的監(jiān)控需求。Nightingale 在產(chǎn)品完成度、系統(tǒng)高可用、以及用戶體驗方面，達到了企業(yè)級的要求，可滿足不同規(guī)模用戶的場景，小到幾臺服務(wù)，大到數(shù)十萬都可以完美支撐。兼顧云原生和裸金屬，支持應(yīng)用監(jiān)控和系統(tǒng)監(jiān)控，插件機制靈活，插件豐富完善，具有高度的靈活性和可擴展性。

Nightingale 在 Open-Falcon 的基礎(chǔ)上，結(jié)合滴滴內(nèi)部的最佳實踐，在性能、可維護性、易用性方面做了大量的改進，作為集團統(tǒng)一的監(jiān)控解決方案，支撐了滴滴內(nèi)部數(shù)十億監(jiān)控指標，覆蓋了從系統(tǒng)、容器、到應(yīng)用等各層面的監(jiān)控需求，周活躍用戶數(shù)千。五年磨一劍，取之開源，回饋開源。

【開源推薦】夜鶯（Nightingale）企業(yè)級監(jiān)控解決方案

Nightingale 采用樹狀節(jié)點導(dǎo)航，我們稱之為對象樹。對象樹本質(zhì)上是一種對監(jiān)控對象的分組管理機制，方便查找和查看監(jiān)控對象，以及對監(jiān)控對象設(shè)置監(jiān)控策略等管理動作。一棵典型的樹可從上到下描述為組織架構(gòu)關(guān)系、產(chǎn)品服務(wù)模塊關(guān)系、機房和機器掛載關(guān)系，該導(dǎo)航樹可根據(jù)用戶需求自行靈活定制。

監(jiān)控策略應(yīng)用到某個節(jié)點后，該節(jié)點下的所有子節(jié)點掛載的所有的機器都會應(yīng)用這個策略，任何一臺機器觸發(fā)相關(guān)閾值都會產(chǎn)生告警。

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

Nightingale 是在 Open-Falcon 的基礎(chǔ)上衍化發(fā)展而來，Open-Falcon 作為國內(nèi)使用最廣泛的監(jiān)控解決方案之一，為 Nightingale 的設(shè)計開發(fā)提供了大量的借鑒意義。

與 Open-Falcon 的不同點

告警引擎重構(gòu)：Open-Falcon 的告警策略，在監(jiān)控數(shù)據(jù)推送上來的同時會觸發(fā)策略判斷，這種「推」的模式優(yōu)勢是策略的判斷時效性非常高，但是不利于更高級的告警策略的支持和擴展，比如多條件的組合報警就很難支持。Nightingale 轉(zhuǎn)為推拉結(jié)合模式，通過推模式保證大部分策略判斷的效率，通過拉模式支持了與條件告警和nodata告警。
引入了導(dǎo)航對象樹：將 Open-Falcon 采用的扁平 HostGroup，轉(zhuǎn)為 Nightingale 的導(dǎo)航對象樹，對象樹本質(zhì)上是一種對監(jiān)控對象的分組管理機制，方便查找和查看監(jiān)控對象，以及對監(jiān)控對象設(shè)置監(jiān)控策略等管理動作。同時在 Nightingale 中，去除了告警模板的概念，告警策略直接與樹節(jié)點綁定，簡化設(shè)計，大幅提升靈活度和易用性。
索引模塊升級換代：Open-Falcon 使用 MySQL 存儲 metrics 的索引數(shù)據(jù)，在擴展性和靈活性上存在瓶頸。Nightingale 根據(jù)監(jiān)控需求，設(shè)計開發(fā)了全新的內(nèi)存索引模塊 index，查詢方式更多樣，查詢效率更高，避免了原來 MySQL 索引數(shù)據(jù)達到億級別時面臨的維護優(yōu)化工作。
時序數(shù)據(jù)庫優(yōu)化：在 Open-Falcon 存儲模塊 Graph 的基礎(chǔ)上，引入 Facebook 的 Gorilla 壓縮方案，近期幾個小時的數(shù)據(jù)采用內(nèi)存存儲，大幅提升數(shù)據(jù)查詢效率，長期數(shù)據(jù)仍然使用 rrdtool 數(shù)據(jù)格式存儲在硬盤上。同時進一步完善了時序數(shù)據(jù)庫的性能和穩(wěn)定性。
告警引擎高可用改進：告警引擎 judge 模塊通過心跳機制做到了故障自動摘除，再也不用擔心單個 judge 宕機導(dǎo)致部分策略失效，需要人工介入的問題，index 模塊也是采用類似方式保證可用性。
原生內(nèi)置日志監(jiān)控功能：Nightingale 客戶端原生內(nèi)置了日志匹配和指標抽取能力，在 web 控制臺頁面上支持了日志匹配規(guī)則的配置，同時也支持讀取目標機器特定目錄下的配置文件的方式，讓業(yè)務(wù)指標監(jiān)控更為易用。
可運維性增強：將 portal (falcon-plus 中的 api)、uic、dashboard、hbs、alarm 合并為一個模塊：monapi，簡化了系統(tǒng)整體部署難度，原來的部分模塊間調(diào)用變成進程內(nèi)方法調(diào)用，性能更高。
配置文件中心化：配置文件做了易用性改造，抽取數(shù)據(jù)庫通用配置到 mysql.yml，抽取端口實例地址等關(guān)聯(lián)配置到 address.yml，大批配置在代碼里給了默認值，使得配置文件更清晰，易于維護。

與 Open-Falcon 的相同點

數(shù)據(jù)模型沒有變化，仍然是 metric、endpoint、tags 的組織方式，agent 基本是可以復(fù)用的，Nightingale 中的 agent 叫 collector，融合了原來 Open-Falcon 的 agent 和 falcon-log-agent 的邏輯，各種監(jiān)控插件也都是可以復(fù)用的。
數(shù)據(jù)流向和整體處理邏輯是類似的，仍然使用靈活的推模型，分為數(shù)據(jù)存儲和告警判斷兩條鏈路。

Nightingale 架構(gòu)

collector即agent，可以采集機器常見指標，原生支持日志監(jiān)控，支持插件機制，支持業(yè)務(wù)通過接口直接上報數(shù)據(jù)；
transfer提供rpc接口接收collector上報的數(shù)據(jù)，然后通過一致性哈希，將數(shù)據(jù)轉(zhuǎn)發(fā)給多臺tsdb和多臺judge；
tsdb即open-falcon中的graph組件，用于存儲歷史數(shù)據(jù)，支持配置為雙寫模式提升系統(tǒng)容災(zāi)能力，tsdb會把監(jiān)控數(shù)據(jù)轉(zhuǎn)發(fā)一份給index建索引；
index是內(nèi)存索引模塊，替換原來的mysql方案，在內(nèi)存里構(gòu)建索引，便于后續(xù)數(shù)據(jù)檢索，在檢索的靈活性和檢索性能方面大幅提升；
judge是告警引擎，從monapi(portal)同步監(jiān)控策略，然后對接收到的數(shù)據(jù)做告警判斷，如滿足閾值，則生成告警事件推送到redis隊列；
monapi(alarm)從redis隊列中讀取judge生成的事件，進行二次處理，補充一些元信息，生成告警消息，重新推送回redis隊列；
各發(fā)送組件，比如mail-sender、sms-sender等，從redis讀取告警消息，發(fā)送告警，抽象出各類sender是為了后續(xù)定制方便；
monapi集成了原來多個模塊的功能，提供接口給js調(diào)用，api前綴為/api/portal，數(shù)據(jù)查詢走transfer，去除了 open-falcon 中原來的query組件，api前綴為/api/transfer，索引查詢的api前綴/api/index，于是，在前端統(tǒng)一搭建Nginx，即可通過不同location將請求轉(zhuǎn)發(fā)到不同后端；
數(shù)據(jù)庫仍然使用MySQL，主要存儲的內(nèi)容包括：用戶信息、團隊信息、樹節(jié)點信息、告警策略、監(jiān)控大盤、屏蔽策略、采集策略、部分組件心跳信息等；

仍在進行中的工作

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