OpenFalcon是一款企業級、高可用、可擴展的開源監控解決方案。
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編寫。
架構
運作流程：
1、目標服務器運行agent
2、agent採集各類監控項數值，傳給transfer
3、transfer校驗和整理監控項數值，做一致性hash分片，傳給對應的judge模塊以驗證是否觸發告警
4、transfer整理監控項數值，做一致性hash分片，傳輸給graph以進行數據的存儲
5、judge根據具體報警策略或閾值進行告警判斷，如觸發告警則組裝告警event事件，寫入緩存隊列。
6、alarm和sender根據event事件中的判定結果，執行event，像用戶組發送短信或郵件。
7、graph收到監控項數據後，將數據存儲成RRD文件格式，進行歸檔，並提供查詢接口。
8、query將調用graph的查詢接口，將監控數據傳送到dashboard以進行頁面展示。
9、dashboard則渲染頁面，展示曲線報表圖等。
10、portal提供頁面供用戶配置機器分組、報警策略、表達式、nodata等配置。
組件
falcon-agent
agent用於採集機器負載監控指標，比如cpu.idle、load.1min、disk.io.util等等，每隔60秒push給Transfer。agent與Transfer建立了長連接，數據發送速度比較快，agent提供了一個http接口/v1/push用於接收用戶手工push的一些數據，然後通過長連接迅速轉發給Transfer。
transfer
transfer是數據轉發服務。它接收agent上報的數據，然後按照哈希規則進行數據分片、並將分片後的數據分別push給graph&judge等組件。
Graph
graph是存儲繪圖數據的組件。graph組件 接收transfer組件推送上來的監控數據，同時處理api組件的查詢請求、返回繪圖數據。
API
api組件，提供統一的restAPI操作接口。比如：api組件接收查詢請求，根據一致性哈希算法去相應的graph實例查詢不同metric的數據，然後彙總拿到的數據，最後統一返回給用戶。
dashboard
dashboard首頁，用戶可以以多個維度來搜索endpoint列表，即可以根據上報的tags來搜索關聯的endpoint。
HBS(Heartbeat)
心跳服務器，公司所有agent都會連到HBS，每分鐘發一次心跳請求。
HBS功能：
1、agent發送心跳信息給HBS的時候，會把hostname,ip,agent version,plugin version等信息告訴HBS,HBS負責更新host表。
2、從mysql中讀取所有主機/分組/模板/告警/策略等信息，一次性加載到內存
Judge需要獲取所有的報警策略，讓Judge去讀取Portal的DB麼？不太好。因爲Judge的實例數目比較多，如果公司有幾十萬機器，Judge實例數目可能會是幾百個，幾百個Judge實例去訪問Portal數據庫，也是一個比較大的壓力。既然HBS無論如何都要訪問Portal的數據庫了，那就讓HBS去獲取所有的報警策略緩存在內存裏，然後Judge去向HBS請求。這樣一來，對Portal DB的壓力就會大大減小。
judge
Judge用於告警判斷，agent將數據push給Transfer，Transfer不但會轉發給Graph組件來繪圖，還會轉發給Judge用於判斷是否觸發告警。
設計初衷：
因爲監控系統數據量比較大，一臺機器顯然是搞不定的，所以必須要有個數據分片方案。Transfer通過一致性哈希來分片，每個Judge就只需要處理一小部分數據就可以了。所以判斷告警的功能不能放在直接的數據接收端：Transfer，而應該放到Transfer後面的組件裏。
Alarm
alarm模塊是處理報警event的，judge產生的報警event寫入redis，alarm從redis讀取處理，並進行不同渠道的發送。
設計初衷：
在配置報警策略的時候配置了報警級別，比如P0/P1/P2等等，每個及別的報警都會對應不同的redis隊列 alarm去讀取這個數據的時候我們希望先讀取P0的數據，再讀取P1的數據，最後讀取P5的數據，因爲我們希望先處理優先級高的。於是：用了redis的brpop指令。
已經發送的告警信息，alarm會寫入MySQL中保存，這樣用戶就可以在dashboard中查閱歷史報警，同時針對同一個策略發出的多條報警，在MySQL存儲的時候，會聚類；歷史報警保存的週期，是可配置的，默認爲7天。
Task
task是監控系統一個必要的輔助模塊。定時任務，實現瞭如下幾個功能：
- index更新。包括圖表索引的全量更新 和 垃圾索引清理。
- falcon服務組件的自身狀態數據採集。定時任務了採集了transfer、graph、task這三個服務的內部狀態數據。
- falcon自檢控任務。
Gateway
Nodata
nodata用於檢測監控數據的上報異常。nodata和實時報警judge模塊協同工作，過程爲: 配置了nodata的採集項超時未上報數據，nodata生成一條默認的模擬數據；用戶配置相應的報警策略，收到mock數據就產生報警。採集項上報異常檢測，作爲judge模塊的一個必要補充，能夠使judge的實時報警功能更加可靠、完善。
Aggregator
集羣聚合模塊。聚合某集羣下的所有機器的某個指標的值，提供一種集羣視角的監控體驗。