OpenFalcon是由小米的運維團隊開源的一款企業級、高可用、可擴展的開源監控解決方案，，在衆多開源愛好者的支持下，功能越來越豐富，文檔更加的完善，OpenFalcon 已經成爲國內最流行的監控系統之一。小米、美團、金山雲、快網、宜信、七牛、又拍雲、趕集、滴滴、金山辦公、愛奇藝、一點資訊、快牙、開心網、借貸寶、百度、迅雷等公司使用，如果關注招聘網站的話會發現非常多的崗位要求熟悉openfalcon，這也意味着OpenFalcon的使用非常廣泛。還是非常值得花費一些精力去研究一下Openfalcon的架構以及使用等知識。
官網：http://www.open-falcon.org/
GitHub 地址：https://github.com/open-falcon
文檔地址：https://book.open-falcon.org/zh_0_2/
API文檔：http://open-falcon.org/falcon-plus/
Openfalcon是採取了前後端分離的架構，後端用Go語言開發，前端用Python開發。編譯後的後端程序運行時，不再需要Go語言環境，直接將可執行文件拷貝到某臺機器上面運行就可以了，而前端是需要python環境。當機器數量比較大的時候，一般會預先將Agent安裝到機器上(物理機標準化裝機時安裝，虛擬機可以封裝到鏡像中，私有云或者公有云都支持主要都是網絡問題)。當Agent運行時就會上報數據。
Openfalcon架構：
整個後端採用模塊化設計，包含agent、aggregator、alarm、api、gateway、graph、hbs、judge、nodata、transfer等模塊。接下來再介紹一下每個模塊的功能和特點。
(1) agent： 用於採集機器負載監控指標，比如cpu.idle、load.1min、disk.io.util等等，每隔60秒push給Transfer。agent與Transfer建立了長連接，數據發送速度比較快，agent提供了一個http接口/v1/push用於接收用戶手工push的一些數據，然後通過長連接迅速轉發給Transfer。agent是需要部署到所有要被監控的機器上，比如公司有10萬臺機器，那就要部署10萬個agent。agent本身資源消耗很少，不用擔心。小米開源的Agent只包含Linux，汽車之家等公司相繼開源了Windows的Agent。
被監控機Agent提供一個默認監聽的1988端口的HTTP服務，提供了一個UI設計不錯的Web界面，在該頁面上能夠展示內核、運行時間、主機名、負載情況、內存使用，磁盤使用等基礎監控數據。此外還提供了一些接口，通過這些接口獲取一些基礎監控數據。
（2）aggregator 集羣聚合模塊。聚合某集羣下的所有機器的某個指標的值，提供一種集羣視角的監控體驗。這種視角下能更好的體現整個集羣的某個監控指標，但是該模塊目前不是非常完善，我們在生產環境中沒並沒有使用該模塊。
（3）alarm 是處理報警event的，judge產生的報警event寫入redis，alarm從redis讀取處理，報警event的處理邏輯並非僅僅是發郵件、發短信這麼簡單。爲了能夠自動化對event做處理，alarm需要支持在產生event的時候回調用戶提供的接口；有的時候報警短信、郵件太多，對於優先級比較低的報警，希望做報警合併，這些邏輯都是在alarm中做的。
在配置報警策略的時候配置了報警級別，比如P0/P1/P2等等，每個及別的報警都會對應不同的redis隊列 alarm去讀取這個數據的時候希望先讀取P0的數據，再讀取P1的數據，最後讀取P5的數據，因爲希望先處理優先級高的。於是：用了redis的brpop指令。
注意事項：alarm是個單點。對於未恢復的告警是放到alarm的內存中的，alarm還需要做報警合併，故而alarm只能部署一個實例。後期需要想辦法改進。
報警合併：如果某個核心服務掛了，可能會造成大面積報警，爲了減少報警短信數量，我們做了報警合併功能。把報警信息寫入links模塊，然後links返回一個url地址給alarm，alarm將這個url鏈接發給用戶，這樣用戶只要收到一條短信（裏邊是個url地址），點擊url進去就是多條報警內容。
highQueues中配置的幾個event隊列中的事件是不會做報警合併的，因爲那些是高優先級的報警，報警合併只是針對lowQueues中的事件。如果所有的事件都不想做報警合併，就把所有的event隊列都配置到highQueues中即可
（4）api組件，提供統一的restAPI操作接口。比如：api組件接收查詢請求，根據一致性哈希算法去相應的graph實例查詢不同metric的數據，然後彙總拿到的數據，最後統一返回給用戶。具體的可以參考http://api.open-falcon.org 的接口文檔，注意有模板用戶、管理等接口，支持post、get等方法。
（5）gateway 模塊主要是爲了解決機房分區，試用與異地多活、混合雲、多雲環境的解決方案。Falcon多數據中心時，提供數據路由功能。多IDC時，可能面對 "分區到中心的專線網絡質量較差&公網ACL不通" 等問題。這時，可以在分區內部署一套數據路由服務，接收本分區內的所有流量(包括所有的agent流量)，然後通過公網(開通ACL)，將數據push給中心的Transfer。如下圖，
從client端的角度來看，gateway和transfer提供了完全一致的功能和接口。只有遇到網絡分區的情況時，纔有必要使用gateway組件。服務啓動後，可以通過日誌查看服務的運行狀態，日誌文件地址爲./var/app.log。可以通過調試腳本./test/debug查看服務器的內部狀態數據，如 運行 bash ./test/debug 可以得到服務器內部狀態的統計信息。
gateway組件，部署於分區中。單個gateway實例的轉發能力，爲 {1核, 500MB內存, Qps不小於1W/s}；官方建議，一個分區至少部署兩個gateway實例，來實現高可用。在我們內部新加坡、雅加達、華盛頓、深圳、廣州、北京等公有云區域。每個區域部署一個gateway（2C4G），然後分別通過跨區域帶寬將數據回傳到我們上海、杭州IDC內。
（6）graph 是存儲繪圖數據、歷史數據的組件。graph組件 接收transfer組件推送上來的監控數據，同時處理query組件的查詢請求、返回繪圖數據。
（7）hbs(Heartbeat Server) 心跳服務器，公司所有agent都會連到HBS，每分鐘發一次心跳請求。
Portal的數據庫中有一個host表，維護了公司所有機器的信息，比如hostname、ip等等。這個表中的數據通常是從公司CMDB中同步過來的。但是有些規模小一些的公司是沒有CMDB的，那此時就需要手工往host表中錄入數據，這很麻煩。於是我們賦予了HBS第一個功能：agent發送心跳信息給HBS的時候，會把hostname、ip、agent version、plugin version等信息告訴HBS，HBS負責更新host表。
falcon-agent有一個很大的特點，就是自發現，不用配置它應該採集什麼數據，就自動去採集了。比如cpu、內存、磁盤、網卡流量等等都會自動採集。我們除了要採集這些基礎信息之外，還需要做端口存活監控和進程數監控。那我們是否也要自動採集監聽的端口和各個進程數目呢？我們沒有這麼做，因爲這個數據量比較大，彙報上去之後用戶大部分都是不關心的，太浪費。於是我們換了一個方式，只採集用戶配置的。比如用戶配置了對某個機器80端口的監控，我們纔會去採集這個機器80端口的存活性。那agent如何知道自己應該採集哪些端口和進程呢？向HBS要，HBS去讀取Portal的數據庫，返回給agent。
之後我們會介紹一個用於判斷報警的組件：Judge，Judge需要獲取所有的報警策略，讓Judge去讀取Portal的DB麼？不太好。因爲Judge的實例數目比較多，如果公司有幾十萬機器，Judge實例數目可能會是幾百個，幾百個Judge實例去訪問Portal數據庫，也是一個比較大的壓力。既然HBS無論如何都要訪問Portal的數據庫了，那就讓HBS去獲取所有的報警策略緩存在內存裏，然後Judge去向HBS請求。這樣一來，對Portal DB的壓力就會大大減小
hbs是可以水平擴展的，至少部署兩個實例以保證可用性。一般一個實例可以搞定5000臺機器，所以說，如果公司有10萬臺機器，可以部署20個hbs實例，前面架設lvs，agent中就配置上lvs vip即可。
（8）judge Judge用於告警判斷，agent將數據push給Transfer，Transfer不但會轉發給Graph組件來繪圖，還會轉發給Judge用於判斷是否觸發告警。
因爲監控系統數據量比較大，一臺機器顯然是搞不定的，所以必須要有個數據分片方案。Transfer通過一致性哈希來分片，每個Judge就只需要處理一小部分數據就可以了。所以判斷告警的功能不能放在直接的數據接收端：Transfer，而應該放到Transfer後面的組件裏。
Judge監聽了一個http端口，提供了一個http接口：/count，訪問之，可以得悉當前Judge實例處理了多少數據量。推薦的做法是一個Judge實例處理50萬~100萬數據，用個5G~10G內存，如果所用物理機內存比較大，比如有128G，可以在一個物理機上部署多個Judge實例。
（9）nodata 用於檢測監控數據的上報異常。nodata和實時報警judge模塊協同工作，過程爲: 配置了nodata的採集項超時未上報數據，nodata生成一條默認的模擬數據；用戶配置相應的報警策略，收到mock數據就產生報警。採集項上報異常檢測，作爲judge模塊的一個必要補充，能夠使judge的實時報警功能更加可靠、完善。
此功能還是可能會出現較多的誤報現象，例如網絡異常，導致數據無法上傳，這時候就會檢測到數據異常。
（10）transfer transfer是數據轉發服務。它接收agent上報的數據，然後按照哈希規則進行數據分片、並將分片後的數據分別push給graph&judge等組件。
以上內容是falcon後端程序中比較核心的模塊，同時也可以根據自己的需求去定製一些模塊。