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后端程序中比較核心的模塊，同時也可以根據自己的需求去定制一些模塊。