Open-falcon原理介紹

open-falcon是小米開源的監控工具。open-falcon有三種安裝方式，一種是單機安裝（分后端和前端安裝，建議各一臺服務器）、一種是Docker安裝、最后一種是在多臺機器上分布式安裝。

重點：本案介紹第一種，單機安裝（其實是分兩臺服務器，一臺安裝后端服務、一臺是安裝前端服務）。

分布式安裝也很簡單，就是把open-falcon二進制包git下來，每臺服務器只留需要的模塊文件夾和open-falcon執行腳本，然后更改模塊文件夾下配置文件，最后啟動即可。生成環境環境一般建議分布式部署，參考鏈接：https://book.open-falcon.org/zh_0_2/distributed_install/

open-falcon監控一般是用各種插件。

架構圖：

open-falcon官網架構圖

互聯網上圖

組件描述表：

工作原理：

Falcon-agent（客戶端）：

每臺服務器，都有安裝falcon-agent，falcon-agent是一個golang開發的daemon程序，用于自發現的采集單機的各種數據和指標，這些指標包括不限于以下幾個方面，共計200多項指標。

????CPU相關

????磁盤相關

????IO

????Load

????內存相關

????網絡相關

????端口存活、進程存活

????ntp offset（插件）

????某個進程資源消耗（插件）

????netstat、ss 等相關統計項采集

????機器內核配置參數

只要安裝了falcon-agent的機器，就會自動開始采集各項指標，主動上報，不需要用戶在server做任何配置（這和zabbix有很大的不同），這樣做的好處，就是用戶維護方便，覆蓋率高。當然這樣做也會server端造成較大的壓力，不過open-falcon的服務端組件單機性能足夠高，同時都可以水平擴展，所以自動多采集足夠多的數據，反而是一件好事情，對于SRE和DEV來講，事后追查問題，不再是難題。

另外，falcon-agent提供了一個proxy-gateway，用戶可以方便的通過http接口，push數據到本機的gateway，gateway會幫忙高效率的轉發到server端。

falcon-agent，可以在我們的github上找到 : https://github.com/open-falcon/falcon-plus

Transfer（傳輸者）：

falcon-agent將數據上報給transfer，它們之間建立的長鏈接。

transfer，接收客戶端發送的數據，做一些數據規整，檢查之后，轉發到多個后端系統去處理。在轉發到每個后端業務系統的時候，transfer會根據一致性hash算法，進行數據分片，來達到后端業務系統的水平擴展。

transfer 提供jsonRpc接口和telnet接口兩種方式，transfer自身是無狀態的，掛掉一臺或者多臺不會有任何影響，同時transfer性能很高，每分鐘可以轉發超過500萬條數據。

transfer目前支持的業務后端，有三種，judge、graph、opentsdb。judge是我們開發的高性能告警判定組件，graph是我們開發的高性能數據存儲、歸檔、查詢組件，opentsdb是開源的時間序列數據存儲服務。可以通過transfer的配置文件來開啟。

transfer的數據來源，一般有三種：

????falcon-agent采集的基礎監控數據

????falcon-agent執行用戶自定義的插件返回的數據

????client library：線上的業務系統，都嵌入使用了統一的perfcounter.jar，對于業務系統中每個RPC接口的qps、latency都會主動采集并上報

說明：上面這三種數據，都會先發送給本機的proxy-gateway，再由gateway轉發給transfer。

Judge集群（告警判斷）：

falcon-agent將數據上報給transfer后，transfer轉發給Judge集群，使用一致性hash做數據分片。一個實例只處理一部分數據。

Graph集群（數據存儲、規定、查詢接口）：

falcon-agent將數據上報給transfer后，transfer轉發給Graph集群，使用一致性hash做數據分片。一個實例只處理一部分數據。rrdtool的數據歸檔方式存儲，同時提供RPC接口。

Alarm（告警）：

Judge判斷后，放到redis隊列。alarm從redis隊列讀取報警事件做處理，該發短信發短信、該發郵件發郵件，該回調接口就回調。告警合并也在alarm里面做的，專門發送報警的sender模塊，告警合并依賴的links模塊。

Query：

因為Graph做過分片處理，query要采用和transfer一致的一致性hash數據分片。對外提供一個http接口。query是go寫的后端模塊。

Dashborad：

在dashborad里面查詢監控數據，是python做的web。

Portal：

portal是python做的web，配置監控策略，然后寫入數據庫。

Heartbeat server：

心跳服務器，falcon-agent每分鐘都會發送心跳給heartbeat server，上報自己的版本、hostname、ip等。從heartbeat拉取要執行的插件和特殊采集項等。這些信息需要heartbeat訪問 Portal的數據庫要獲取。Judge要做告警判斷，需要先從portal數據庫中讀取報警策略，但是Judge實例比較多，都去讀取數據庫會造成很大壓力，所以可以讓heartbeat成為db cache緩存，heartbeat從數據庫中讀取數據緩存到內存，Judge調用heartbeat的rpc接口，獲取報警策略。

數據存儲：

對于監控系統來講，歷史數據的存儲和高效率查詢，永遠是個很難的問題！

????數據量大：目前我們的監控系統，每個周期，大概有2000萬次數據上報（上報周期為1分鐘和5分鐘兩種，各占50%），一天24小時里，從來不會有業務低峰，不管是白天和黑夜，每個周期，總會有那么多的數據要更新。

????寫操作多：一般的業務系統，通常都是讀多寫少，可以方便的使用各種緩存技術，再者各類數據庫，對于查詢操作的處理效率遠遠高于寫操作。而監控系統恰恰相反，寫操作遠遠高于讀。每個周期幾千萬次的更新操作，對于常用數據庫（MySQL、postgresql、mongodb）都是無法完成的。

????高效率的查：我們說監控系統讀操作少，是說相對寫入來講。監控系統本身對于讀的要求很高，用戶經常會有查詢上百個meitric，在過去一天、一周、一月、一年的數據。如何在1秒內返回給用戶并繪圖，這是一個不小的挑戰。

open-falcon在這塊，投入了較大的精力。我們把數據按照用途分成兩類，一類是用來繪圖的，一類是用戶做數據挖掘的。

對于繪圖的數據來講，查詢要快是關鍵，同時不能丟失信息量。對于用戶要查詢100個metric，在過去一年里的數據時，數據量本身就在那里了，很難1秒之類能返回，另外就算返回了，前端也無法渲染這么多的數據，還得采樣，造成很多無謂的消耗和浪費。我們參考rrdtool的理念，在數據每次存入的時候，會自動進行采樣、歸檔。我們的歸檔策略如下，歷史數據保存5年。同時為了不丟失信息量，數據歸檔的時候，會按照平均值采樣、最大值采樣、最小值采樣存三份。

//?1分鐘一個點存?12小時
c.RRA("AVERAGE",?0.5,?1,?720)

//?5m一個點存2d
c.RRA("AVERAGE",?0.5,?5,?576)
c.RRA("MAX",?0.5,?5,?576)
c.RRA("MIN",?0.5,?5,?576)

//?20m一個點存7d
c.RRA("AVERAGE",?0.5,?20,?504)
c.RRA("MAX",?0.5,?20,?504)
c.RRA("MIN",?0.5,?20,?504)

//?3小時一個點存3個月
c.RRA("AVERAGE",?0.5,?180,?766)
c.RRA("MAX",?0.5,?180,?766)
c.RRA("MIN",?0.5,?180,?766)

//?1天一個點存1year
c.RRA("AVERAGE",?0.5,?720,?730)
c.RRA("MAX",?0.5,?720,?730)
c.RRA("MIN",?0.5,?720,?730)

對于原始數據，transfer會打一份到hbase，也可以直接使用opentsdb，transfer支持往opentsdb寫入數據。