針對 open-falcon 與 nightingale 的調研
一、open-falcon
1.1 組件介紹
1.1.1 agent
> agent用於采集機器負載監控指標，比如cpu.idle、load.1min、disk.io.util等等，每隔60秒push給Transfer。agent與Transfer建立了長連接，數據發送速度比較快，agent提供了一個http接口/v1/push用於接收用戶手工push的一些數據，然后通過長連接迅速轉發給Transfer。
> agent需要部署到所有要被監控的機器上，比如公司有10萬台機器，那就要部署10萬個agent。agent本身資源消耗很少，不用擔心。
1.1.2 transfer
> transfer是數據轉發服務。它接收agent上報的數據，然后按照哈希規則進行數據分片、並將分片后的數據分別push給graph&judge等組件。同時 transfer 也支持將數據轉發給 opentsdb 和 influxdb，也可以轉發給另外一個 transfer。
1.1.3 graph
> graph是存儲繪圖數據的組件。graph組件 接收transfer組件推送上來的監控數據，同時處理api組件的查詢請求、返回繪圖數據。
1.1.4 api
> api組件，提供統一的restAPI操作接口。比如：api組件接收查詢請求，根據一致性哈希算法去相應的graph實例查詢不同metric的數據，然后匯總拿到的數據，最后統一返回給用戶。
1.1.5 dashboard
控制台
1.1.6 hbs
> 心跳服務器，公司所有agent都會連到HBS，每分鍾發一次心跳請求。
> agent發送心跳信息給HBS的時候，會把hostname、ip、agent version、plugin version等信息告訴HBS，HBS負責更新host表
> hbs是可以水平擴展的，至少部署兩個實例以保證可用性。一般一個實例可以搞定5000台機器，所以說，如果公司有10萬台機器，可以部署20個hbs實例，前面架設lvs，agent中就配置上lvs vip即可。
> HBS去獲取所有的報警策略緩存在內存里
1.1.7 judge
> Judge用於告警判斷，agent將數據push給Transfer，Transfer不但會轉發給Graph組件來繪圖，還會轉發給Judge用於判斷是否觸發告警。
> HBS去獲取所有的報警策略緩存在內存里，然后Judge去向HBS請求
1.1.8 alarm
> alarm模塊是處理報警event的，judge產生的報警event寫入redis，alarm從redis讀取處理，並進行不同渠道的發送。
1.1.9 task
task是監控系統一個必要的輔助模塊。定時任務，實現了如下幾個功能：
> index更新。包括圖表索引的全量更新 和 垃圾索引清理。
> falcon服務組件的自身狀態數據采集。定時任務了采集了transfer、graph、task這三個服務的內部狀態數據。
> falcon自檢控任務。
1.1.10 gateway
> 如果您沒有遇到機房分區問題，請直接忽略此組件。
1.1.11 nodata
> nodata用於檢測監控數據的上報異常
> nodata和實時報警judge模塊協同工作，過程為: 配置了nodata的采集項超時未上報數據，nodata生成一條默認的模擬數據；用戶配置相應的報警策略，收到mock數據就產生報警。采集項上報異常檢測，作為judge模塊的一個必要補充，能夠使judge的實時報警功能更加可靠、完善。
1.1.12 aggregator
集群聚合模塊。聚合某集群下的所有機器的某個指標的值，提供一種集群視角的監控體驗。
1.2 流程
二、nightingale
2.1 組件介紹
2.1.1 collector
類似於agent ,可以采集機器常見指標，支持日志監控，支持插件機制，支持業務通過接口直接上報數據
2.1.2 transfer
transfer提供rpc接口接收collector上報的數據，然后通過一致性哈希，將數據轉發給多台tsdb和多台judge
2.1.3 tsdb
原來的graph組件，用於存儲歷史數據，支持配置為雙寫模式提升系統容災能力，tsdb會把監控數據轉發一份給index
2.1.4 index
index是索引模塊，替換原來的mysql方案，在內存里構建索引，便於后續數據檢索，性能大幅提升
2.1.5 judge
judge是告警引擎，從monapi(portal)同步監控策略，然后對接收到的數據做告警判斷，如滿足閾值，則生成告警事件推到redis
2.1.6 monapi(alarm)
> monapi(alarm)從redis讀取judge生成的事件，進行二次處理，補充一些元信息，生成告警消息，重新推回redis
> 寫入event 至mysql
2.1.7 通知消息個組件
各發送組件，比如mail-sender、sms-sender等，從redis讀取告警消息，發送告警，抽出各類sender是為了后續定制方便
2.1.8 monapi
monapi集成了原來多個模塊的功能，提供接口給js調用，api前綴為/api/portal，數據查詢走transfer，干掉了原來的query組件，api前綴為/api/transfer，索引查詢的api前綴/api/index，於是，前面搭建nginx，即可通過不同location將請求轉發到不同后端
2.2 流程
三、對比
3.1 相同點
> nightingale 和 open falcon 再整體流程上較為相似。一些組件只是名稱的變化，功能較為類似
3.2 不同點
> 數據存儲 graph 在nightingale 中被改為了TSDB 內存存儲.提升了數據查詢效率（僅存儲近幾個小時的數據）
> open falcon:alarm 處理報警event 並進行發送; nightingale: monapi(alarm)從redis讀取event處理后重新推回redis，再由各發送組件讀取告警消息發送
> nighthingale 增加了index索引模塊，代替了open falcon mysql方案，由內存中構建索引
> nightingale 將 openfalcon 中的api、uic、dashboard、hbs、alarm 合並為一個模塊 monapi，簡化部署難度
3.3 nightingale官方對比open-falcon的異同
3.3.1 不同點
> 告警引擎重構為推拉結合模式，通過推模式保證大部分策略判斷的效率，通過拉模式支持了nodata告警，去除原來的nodata組件，簡化系統部署難度
> 引入了服務樹，對endpoint進行層級管理，去除原來扁平的HostGroup，同時干掉告警模板，告警策略直接與服務樹節點綁定，大幅提升靈活度和易用性
> 干掉原來的基於數據庫的索引庫，改成內存模式，單獨抽出一個index模塊處理索引，避免了原來MySQL單表達到億級的尷尬局面，索引基於內存之后效率也大幅提升
> 存儲模塊Graph，引入facebook的Gorilla，即內存TSDB，近期幾個小時的數據默認存內存，大幅提升數據查詢效率，硬盤存儲方式仍然使用rrdtool
> 告警引擎judge模塊通過心跳機制做到了故障自動摘除，再也不用擔心單個judge掛掉導致部分策略失效的問題，index模塊也是采用類似方式保證可用性
> 客戶端中內置了日志匹配指標抽取能力，web頁面上支持了日志匹配規則的配置，同時也支持讀取目標機器特定目錄下的配置文件的方式，讓業務指標監控更為易用
> 將portal(falcon-plus中的api)、uic、dashboard、hbs、alarm合並為一個模塊：monapi，簡化了系統整體部署難度，原來的部分模塊間調用變成進程內方法調用，穩定性更好
3.3.2 相同點
> 數據模型沒有變化，仍然是metric、endpoint、tags的組織方式，所以agent基本是可以復用的，Nightingale中的agent叫collector，融合了原來Open-Falcon的agent和falcon-log-agent的邏輯，各種監控插件也都是可以復用的
> 數據流向和整體處理邏輯是類似的，仍然使用靈活的推模型，分為數據存儲和告警判斷兩條鏈路，下一節我們基於架構圖詳細展開
四、調研
4.1、是否能否滿足我們的需求
| cpu | mem | 網絡 | 安全審計 | 采集器是否可擴展 | |
|---|---|---|---|---|---|
| nightingale | ✔ | ✔ | ✔ | ✖ | ✔ |
| open falcon | ✔ | ✔ | ✔ | ✖ | ✔ |
4.2、部署難度
兩者之間的部署難度相近
nightingale 都是用go編寫需額外用到 redis mysql 和nginx代理
open-falcon 后台使用go編寫，前端使用python ,需額外redis 和 mysql
后端程序兩者都可以一鍵啟動多個組件
nightingale 節點的部署 略復雜於 open-falcon
4.3、各組件資源占用(初期)
nightingale :( 虛擬機 centos 1cpu 2G)
cpu mem module
0.2 1.1 /home/go-www/src/github.com/didi/nightingale/n9e-monapi
0.3 1.0 /home/go-www/src/github.com/didi/nightingale/n9e-transfer
0.0 0.8 /home/go-www/src/github.com/didi/nightingale/n9e-tsdb
0.0 0.8 /home/go-www/src/github.com/didi/nightingale/n9e-index
0.0 0.8 /home/go-www/src/github.com/didi/nightingale/n9e-judge
0.4 4.1 /home/go-www/src/github.com/didi/nightingale/n9e-collector
open-falcon :( 虛擬機 centos 1cpu 2G)
cpu mem module
0.0 0.5 /home/work/open-falcon/graph/bin/falcon-graph
0.0 0.5 /home/work/open-falcon/hbs/bin/falcon-hbs
0.0 0.5 /home/work/open-falcon/judge/bin/falcon-judge
0.2 0.4 /home/work/open-falcon/transfer/bin/falcon-transfer
0.0 0.5 /home/work/open-falcon/nodata/bin/falcon-nodata
0.0 0.6 /home/work/open-falcon/aggregator/bin/falcon-aggregator
0.0 0.6 /home/work/open-falcon/agent/bin/falcon-agent
0.2 0.4 /home/work/open-falcon/gateway/bin/falcon-gateway
0.0 0.6 /home/work/open-falcon/api/bin/falcon-api
0.2 0.5 /home/work/open-falcon/alarm/bin/falcon-alarm
4.4、其他對比
# 數據查詢
> nightinge 采用TSDB + mysql 存儲方式，TSDB 會保存近幾個小時的數據，在查詢時這段時間內的數據查詢會很快，當然也會占用到一定的內存（nightingale原文:tsdb是分片的，tsdb來做緩存的話，只需要緩存自己分片的數據，內存占用較少）
> open falcon 查詢數據主要存在在MySQL中，依靠索引查詢，速度相對較慢。
# 活躍度對比
> 從github 上的start fork 和contributors 數 nightingale都遠少於 open-falcon
> nightingale 開源時間短 ,但關注度正成迅猛上升趨勢，相較於open-falcon 的關注度 2015-2018 這段時間是其高峰
4.5、開發難度
> nightinagle 模塊少，流程清晰，易於理解。
> 二次開發的API接口 nightingale 要遠遠少於 open-falcon, 即nightingale 提供的功能要少於open-falcon,相應的也減少了對其他功能關注
> 百度搜索 open-falcon相關的資料明顯多於nightingale。 個人推測在遇到開發難題時，open-falcon可參考的資料較多
> 兩個都是采用go語言編寫
4.6 結論
個人推薦使用 nightingale,理由如下：
> 查詢速度更快，TSDB 保存了近幾個小時的數據。
> 內容相對簡單，流程清晰。
> 整體上延續了open-falcon,但又做了很多的改進。例如改變了原來gragh的數據存貯方式；將原有的 hbs,alerm，dashboard 組合為一個模塊(monapi).
> 開源時間較短，但是發展迅猛
> nightingale 與 open falcon的插件可以復用，api的數量較少， 復雜度不高，開發應較為容易一些
> nightingale 和 open-falcon 都可以滿足我們除安全審計外的需求