002-open-falcon插件

open-falcon插件

邏輯圖

相關插件名稱

transfer

transfer是數據轉發服務。它接收agent上報的數據，而後按照哈希規則進行數據分片、並將分片後的數據分別push給graph&judge等組件。

檢查服務狀態是否正常
curl -s "127.0.0.1:6060/health"
啓動服務
./open-falcon start transfer
中止服務
./open-falcon stop transfer
查看服務
./open-falcon monitor transfer

後續插件的相關查看命令你們觸類旁通

graph

graph是存儲繪圖數據的組件。graph組件 接收transfer組件推送上來的監控數據，同時處理api組件的查詢請求、返回繪圖數據。

api

api組件，提供統一的restAPI操做接口。好比：api組件接收查詢請求，根據一致性哈希算法去相應的graph實例查詢不一樣metric的數據，而後彙總拿到的數據，最後統一返回給用戶

HBS

心跳服務器，公司全部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的壓力就會大大減少。

judge

Judge用於告警判斷，agent將數據push給Transfer，Transfer不但會轉發給Graph組件來繪圖，還會轉發給Judge用於判斷是否觸發告警。 由於監控系統數據量比較大，一臺機器顯然是搞不定的，因此必需要有個數據分片方案。Transfer經過一致性哈希來分片，每一個Judge就只須要處理一小部分數據就能夠了。因此判斷告警的功能不能放在直接的數據接收端：Transfer，而應該放到Transfer後面的組件裏。

Alarm

alarm模塊是處理報警event的，judge產生的報警event寫入redis，alarm從redis讀取處理，並進行不一樣渠道的發送。 報警event的處理邏輯並不是僅僅是發郵件、發短信這麼簡單。爲了可以自動化對event作處理，alarm須要支持在產生event的時候回調用戶提供的接口；有的時候報警短信、郵件太多，對於優先級比較低的報警，但願作報警合併，這些邏輯都是在alarm中作的。 咱們在配置報警策略的時候配置了報警級別，好比P0/P1/P2等等，每一個及別的報警都會對應不一樣的redis隊列 alarm去讀取這個數據的時候咱們但願先讀取P0的數據，再讀取P1的數據，最後讀取P5的數據，由於咱們但願先處理優先級高的。因而：用了redis的brpop指令。 已經發送的告警信息，alarm會寫入MySQL中保存，這樣用戶就能夠在dashboard中查閱歷史報警，同時針對同一個策略發出的多條報警，在MySQL存儲的時候，會聚類；歷史報警保存的週期，是可配置的，默認爲7天。

Nodata

nodata用於檢測監控數據的上報異常。nodata和實時報警judge模塊協同工做，過程爲: 配置了nodata的採集項超時未上報數據，nodata生成一條默認的模擬數據；用戶配置相應的報警策略，收到mock數據就產生報警。採集項上報異常檢測，做爲judge模塊的一個必要補充，可以使judge的實時報警功能更加可靠、完善。

Aggregator

集羣聚合模塊。聚合某集羣下的全部機器的某個指標的值，提供一種集羣視角的監控體驗。

參考文檔： https://blog.csdn.net/qq_27384769/article/details/79569813 https://blog.csdn.net/jorson2000a/article/details/81359804