運維監控工具選擇-open-falcon

1. 參考資料

   詳解十三款運維監控工具 (2017年08月17日)

   開源IT監控系統對比 (2014年9月15日)

2. 選擇結果-- open-falcon

   理由

   國内開源(小米)

   文檔完整

   插件擴充

   開源背景決定其更考慮網際網路特殊需求

   自定義push/插件

   足夠開放

   基本介紹

   falcon /'fælkən/, 獵鷹/隼

   open-falcon.org

   github

   book.open-falcon

   特性

   強大靈活的資料采集：自動發現，支援falcon-agent、snmp、支援使用者主動push、使用者自定義插件支援、opentsdb data model like（timestamp、endpoint、metric、key-value tags）

   水準擴充能力：支援每個周期上億次的資料采集、告警判定、曆史資料存儲和查詢

   高效率的告警政策管理：高效的portal、支援政策模闆、模闆繼承和覆寫、多種告警方式、支援callback調用

   人性化的告警設定：最大告警次數、告警級别、告警恢複通知、告警暫停、不同時段不同門檻值、支援維護周期

   高效率的graph元件：單機支撐200萬metric的上報、歸檔、存儲（周期為1分鐘）

   高效的曆史資料query元件：采用rrdtool的資料歸檔政策，秒級傳回上百個metric一年的曆史資料

   dashboard：多元度的資料展示，使用者自定義Screen

   高可用：整個系統無核心單點，易運維，易部署，可水準擴充

   開發語言： 整個系統的後端，全部golang編寫，portal和dashboard使用python編寫。

3. Open-falcon 元件

   Agent: 采集伺服器負載監控名額, 部署到所有的機器上

   Transfer: 是資料轉發服務。它接收agent上報的資料，然後按照哈希規則進行資料分片、并将分片後的資料分别push給graph&judge等元件

   Graph: 是存儲繪圖資料的元件。graph元件 接收transfer元件推送上來的監控資料，同時處理api元件的查詢請求、傳回繪圖資料

   Api: 提供統一的restAPI操作接口。比如：api元件接收查詢請求，根據一緻性雜湊演算法去相應的graph執行個體查詢不同metric的資料，然後彙總拿到的資料，最後統一傳回給使用者

   HBS(Heartbeat Server): 心跳伺服器，公司所有agent都會連到HBS，每分鐘發一次心跳請求

   Judge: 用于告警判斷，agent将資料push給Transfer，Transfer不但會轉發給Graph元件來繪圖，還會轉發給Judge用于判斷是否觸發告警

   Alarm: 子產品是處理報警event的，judge産生的報警event寫入redis，alarm從redis讀取處理，并進行不同管道的發送

   Task: 監控系統的一個必要的輔助子產品. 定時任務實作.

   Nodata: 用于檢測監控資料的上報異常。nodata和實時報警judge子產品協同工作，過程為: 配置了nodata的采集項逾時未上報資料，nodata生成一條預設的模拟資料；使用者配置相應的報警政策，收到mock資料就産生報警。采集項上報異常檢測，作為judge子產品的一個必要補充，能夠使judge的實時報警功能更加可靠、完善

   Aggregator: 叢集聚合子產品。聚合某叢集下的所有機器的某個名額的值，提供一種叢集視角的監控體驗

   Agent-updater: 每台機器都要部署falcon-agent，如果公司機器量比較少，用pssh、ansible、fabric之類的工具手工安裝問題也不大。但是公司機器量多了之後，手工安裝、更新、復原falcon-agent将成為噩夢

4. 部署演進

   Open-Falon的部署情況，會随着機器量(監控對象)的增加而逐漸演進，描述如下，

初始階段，機器量很小(<100量級)。幾乎無高可用的考慮，所有子服務可以混合部署在1台伺服器上。此時，1台中高配的伺服器就能滿足性能要求。

機器量增加，到500量級。graph可能是第一個扛不住的，拿出來單獨部署；接着judge也扛不住了，拿出來單獨部署；transfer居然扛不住了，拿出來吧。這是系統的三個大件，把它們拆出來後devops可以安心一段時間了。

機器數量再增加，到1K量級。graph、judge、transfer單執行個體扛不住了，于是開始考慮增加到2+個執行個體、并考慮混合部署。開始有明确的高可用要求？除了alarm，都能搞成2+個執行個體的高可用結構。再往後，機器繼續不停的增加，性能問題頻現。好吧，見招拆招，Open-Falcon支援水準擴充、表示毫無壓力。

機器量達到了10K量級，這正是我們現在的情況。系統已經有3000+萬個采集項。transfer部署了20個執行個體，graph部署了20個執行個體，judge擴到了60個執行個體(三大件混合部署在20台高配伺服器上,judge單機多執行個體)。query有5個執行個體、平時很閑；hbs也有5個執行個體、很閑的樣子；dashborad、portal、uic都有2個執行個體；alarm、sender、links仍然是bug般的單執行個體部署(這幾個子服務部署在10左右台低配伺服器上，資源消耗很小)。graph的db已經和portal、uic的db執行個體分開了，因為graph的索引已經達到了5000萬量級、混用會危及到其他子系統。redis仍然是共享、單執行個體。這是我們的使用方式，有不合理的地方、正在持續改進。

機器上100K量級了。不好意思、木有經曆過。目測graph索引、hbs将成為系統較為頭疼的地方，Open-Falcon的系統運維可能需要1個勞動力來完成。