開源監控解決方案OpenFalcon系列(一)

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後端程序中比較核心的模塊，同時也能夠根據本身的需求去定製一些模塊。