01：open-falcon入門篇

open-falcon其餘篇

目錄：

• 1.1 openfalcon介紹
• 1.2 open-falcon架構

1.1 openfalcon介紹     返回頂部

 　　  openfalcon官網： https://book.open-falcon.org/zh/

 　　一、openfalcon特色

　　　　　　1. 數據採集免配置： 無需預約義agent自動發現、支持plugin、支持主動push

　　　　　　2. 容量水平擴展： 生產環境每秒20多萬此數據收集、告警、存儲、繪圖

　　　　　　3. 告警策略易於管理： 支持策略模板、模板繼承和覆蓋、報警接收人爲用戶組

　　　　　　4. 報警事件自動化處理： 觸發閥值以後支持callback，便於嵌入自動化邏輯

　　　　　　5. 人性化告警設置： 支持最大告警次數、告警級別、告警恢復通知、告警暫停、不一樣時段不一樣閥值、支持維護週期、支持報警合併

　　　　　　6. 歷史數據高效查詢： 秒級返回上百個指標一年的歷史數據

　　　　　　7. 架構設計高可用： 整個系統同核心單點、易運維、易部署

　　二、openfalcon與zabbix比優勢

　　　　　　1. 模板支持繼承的同時支持覆蓋策略項

　　　　　　2. 數據採集免配置，節省人力成本

　　　　　　3. 較爲強大的數據模型

　　　　　　4. tag化描述告警策略each(metric=qps project=falcon module=jedge)>100

　　　　　　5. 水平擴展，多IDC支持

1.2 open-falcon架構     返回頂部

            

　　part01：數據採集&上報

　　一、agent（數據採集組件）：golang項目

　　　　　　1. 須要監控的服務器都要安裝falcon-agent，falcon-agent是一個golang開發的daemon程序，用於自發現的採集單機的各類數據和指標

　　　　　　2. agent提供了一個http接口/v1/push用於接收用戶手工push的一些數據，而後經過長鏈接迅速轉發給Transfer。

　　　　　　3. 部署好agent後，能自動獲取到系統的基礎監控指標，並上報給transfer，agent與transfer創建了TCP長鏈接，每隔60秒發送一次數據到transfer。

　　二、 transfer（數據上報）

　　　　　　1. transfer進程負責分發從agent上送的監控指標數據，並根據哈希分片。

　　　　　　2. 將數據分發給judge進程和graph進程，供告警斷定和繪圖。

　　　　　　部署說明：

　　　　　　　　部署完成transfer組件後，請修改agent的配置，使其指向正確的transfer地址。

　　　　　　　　在安裝完graph和judge後，請修改transfer的相應配置、使其可以正確尋址到這兩個組件。

　　part02: 告警

　　三、judge（告警判斷）

　　　　　　1.Judge從Heartbeat server獲取全部的報警策略，並判斷transfer推送的指標數據是否觸發告警。

　　　　　　2. 若觸發了告警，judge將會產生告警事件，這些告警事件會寫入Redis（使用Redis消息隊列）。

　　　　　　3. redis中告警事件，供處理告警事件的Alarm進程轉發告警消息，或是Email，或是手機短信等。

　　　　　　部署說明：

　　　　　　　　Judge監聽了一個http端口，提供了一個http接口：/count，訪問之，能夠得悉當前Judge實例處理了多少數據量。

　　　　　　　　推薦一個Judge實例處理50萬~100萬數據，用個5G~10G內存的服務器。

　　四、Alarm（告警）

　　　　　　https://book.open-falcon.org/zh_0_2/distributed_install/alarm.html

　　　　　　1. Alarm進程監聽Redis中的消息隊列，並將judge產生的告警事件轉發給微信、短信和郵件三種REST接口，REST接口才是具體的發送動做。

　　　　　　2. 另外，關於告警，每條告警策略都會定義不一樣的優先級，Redis中的消息隊列也按優先級劃分。

　　　　　　3. Alarm不只消費告警事件，優先級比較低的報警，其合併邏輯都是在alarm中作，因此目前Alarm進程只能部署一個實例。

　　　　　　4. 已經發送出去的告警事件，Alarm將會負責寫入MySQL。

　　　　　　說明：

　　　　　　　　1）咱們在配置報警策略的時候配置了報警級別，好比P0/P1/P2等等，每一個及別的報警都會對應不一樣的redis隊列 

　　　　　　　　2）alarm去讀取這個數據的時候咱們但願先讀取P0的數據，再讀取P1的數據，最後讀取P5的數據，由於咱們但願先處理優先級高的。

　　　　　　　　3）已經發送的告警信息，alarm會寫入MySQL中保存，這樣用戶就能夠在dashboard中查閱歷史報警。

　　　　　　　　4）針對同一個策略發出的多條報警，在MySQL存儲的時候，會聚類；歷史報警保存的週期，是可配置的，默認爲7天。

　　　　　　注：alarm是個單點。對於未恢復的告警是放到alarm的內存中的，alarm還須要作報警合併，故而alarm只能部署一個實例。後期須要想辦法改進。

　　part03：歸檔&繪圖

　　五、graph（數據存儲&歸檔）

　　　　　　1. graph進程接收從transfer推送來的指標數據，操做rrd文件存儲監控數據。

　　　　　　2. graph也爲API進程提供查詢接口，處理query組件的查詢請求、返回繪圖數據。

　　六、API（提供統一的restAPI操做接口） ：go的後端模塊

　　　　　　1. API組件，提供統一的繪圖數據查詢入口 （提供http接口））。

　　　　　　2. API組件接收查詢請求，根據一致性哈希算法去相應的graph實例查詢不一樣metric的數據，而後彙總拿到的數據，最後統一返回給用戶。

　　　　　　補充說明：

　　　　　　　　部署完成api組件後，請修改dashboard組件的配置、使其可以正確尋址到api組件。

　　　　　　　　請確保api組件的graph列表 與 transfer的配置 一致。

　　八、dashboard（趨勢圖web界面）：python的web項目

　　　　　　1. dashboard是面向用戶的查詢界面，在這裏，用戶能夠看到push到graph中的全部數據，並查看其趨勢圖。

　　　　　　2. dashboard模塊配置 報警策略，並把策略同步給：aggregator、nodata、grafana。

　　九、Aggregator

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

　　十、Nodata

　　　　　　1. nodata用於檢測監控數據的上報異常。

　　　　　　2. nodata和實時報警judge模塊協同工做，過程爲: 配置了nodata的採集項超時未上報數據，nodata生成一條默認的模擬數據；

　　　　　　3. 用戶配置相應的報警策略，收到mock數據就產生報警。

　　　　　　4. 採集項上報異常檢測，做爲judge模塊的一個必要補充，可以使judge的實時報警功能更加可靠、完善。

　　十一、grafana（生成更詳細圖形）

 

　　part04：報警策略配置

　　十二、web portal（報警策略配置）：最新open-falcon中此模塊功能合併到Dashboard模塊中

　　　　　　1. web portal是python寫的django項目，用戶能夠在這裏配置報警策略，存入mysql

　　　　　　2. Portal的數據庫中有一個host表，維護了公司全部機器的信息，好比hostname、ip等等。

　　　　　　3. HBS會將agent發送心跳信息給HBS的時候的hostname、ip等信息告訴HBS，HBS負責更新host表。

　　1三、hbs：Heartbeat server（心跳服務）

　　　　　　1. 功能1： agent發送心跳信息給HBS的時，會把hostname、ip、agent version、plugin version等信息告訴HBS，HBS負責更新web portal 的host表。

　　　　　　2. 功能2： hbs會從從dashboard模塊中獲取 報警策略配置 並緩存到本地，全部Judge從hbs中獲取報警策略