Open-falcon原理介紹

open-falcon是小米開(kāi)源的監(jiān)控工具。open-falcon有三種安裝方式，一種是單機(jī)安裝（分后端和前端安裝，建議各一臺(tái)服務(wù)器）、一種是Docker安裝、最后一種是在多臺(tái)機(jī)器上分布式安裝。

重點(diǎn)：本案介紹第一種，單機(jī)安裝（其實(shí)是分兩臺(tái)服務(wù)器，一臺(tái)安裝后端服務(wù)、一臺(tái)是安裝前端服務(wù)）。

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

open-falcon監(jiān)控一般是用各種插件。

架構(gòu)圖：

open-falcon官網(wǎng)架構(gòu)圖

互聯(lián)網(wǎng)上圖

組件描述表：

工作原理：

Falcon-agent（客戶端）：

每臺(tái)服務(wù)器，都有安裝falcon-agent，falcon-agent是一個(gè)golang開(kāi)發(fā)的daemon程序，用于自發(fā)現(xiàn)的采集單機(jī)的各種數(shù)據(jù)和指標(biāo)，這些指標(biāo)包括不限于以下幾個(gè)方面，共計(jì)200多項(xiàng)指標(biāo)。

????CPU相關(guān)

????磁盤(pán)相關(guān)

????IO

????Load

????內(nèi)存相關(guān)

????網(wǎng)絡(luò)相關(guān)

????端口存活、進(jìn)程存活

????ntp offset（插件）

????某個(gè)進(jìn)程資源消耗（插件）

????netstat、ss 等相關(guān)統(tǒng)計(jì)項(xiàng)采集

????機(jī)器內(nèi)核配置參數(shù)

只要安裝了falcon-agent的機(jī)器，就會(huì)自動(dòng)開(kāi)始采集各項(xiàng)指標(biāo)，主動(dòng)上報(bào)，不需要用戶在server做任何配置（這和zabbix有很大的不同），這樣做的好處，就是用戶維護(hù)方便，覆蓋率高。當(dāng)然這樣做也會(huì)server端造成較大的壓力，不過(guò)open-falcon的服務(wù)端組件單機(jī)性能足夠高，同時(shí)都可以水平擴(kuò)展，所以自動(dòng)多采集足夠多的數(shù)據(jù)，反而是一件好事情，對(duì)于SRE和DEV來(lái)講，事后追查問(wèn)題，不再是難題。

另外，falcon-agent提供了一個(gè)proxy-gateway，用戶可以方便的通過(guò)http接口，push數(shù)據(jù)到本機(jī)的gateway，gateway會(huì)幫忙高效率的轉(zhuǎn)發(fā)到server端。

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

Transfer（傳輸者）：

falcon-agent將數(shù)據(jù)上報(bào)給transfer，它們之間建立的長(zhǎng)鏈接。

transfer，接收客戶端發(fā)送的數(shù)據(jù)，做一些數(shù)據(jù)規(guī)整，檢查之后，轉(zhuǎn)發(fā)到多個(gè)后端系統(tǒng)去處理。在轉(zhuǎn)發(fā)到每個(gè)后端業(yè)務(wù)系統(tǒng)的時(shí)候，transfer會(huì)根據(jù)一致性hash算法，進(jìn)行數(shù)據(jù)分片，來(lái)達(dá)到后端業(yè)務(wù)系統(tǒng)的水平擴(kuò)展。

transfer 提供jsonRpc接口和telnet接口兩種方式，transfer自身是無(wú)狀態(tài)的，掛掉一臺(tái)或者多臺(tái)不會(huì)有任何影響，同時(shí)transfer性能很高，每分鐘可以轉(zhuǎn)發(fā)超過(guò)500萬(wàn)條數(shù)據(jù)。

transfer目前支持的業(yè)務(wù)后端，有三種，judge、graph、opentsdb。judge是我們開(kāi)發(fā)的高性能告警判定組件，graph是我們開(kāi)發(fā)的高性能數(shù)據(jù)存儲(chǔ)、歸檔、查詢(xún)組件，opentsdb是開(kāi)源的時(shí)間序列數(shù)據(jù)存儲(chǔ)服務(wù)?？梢酝ㄟ^(guò)transfer的配置文件來(lái)開(kāi)啟。

transfer的數(shù)據(jù)來(lái)源，一般有三種：

????falcon-agent采集的基礎(chǔ)監(jiān)控?cái)?shù)據(jù)

????falcon-agent執(zhí)行用戶自定義的插件返回的數(shù)據(jù)

????client library：線上的業(yè)務(wù)系統(tǒng)，都嵌入使用了統(tǒng)一的perfcounter.jar，對(duì)于業(yè)務(wù)系統(tǒng)中每個(gè)RPC接口的qps、latency都會(huì)主動(dòng)采集并上報(bào)

說(shuō)明：上面這三種數(shù)據(jù)，都會(huì)先發(fā)送給本機(jī)的proxy-gateway，再由gateway轉(zhuǎn)發(fā)給transfer。

Judge集群（告警判斷）：

falcon-agent將數(shù)據(jù)上報(bào)給transfer后，transfer轉(zhuǎn)發(fā)給Judge集群，使用一致性hash做數(shù)據(jù)分片。一個(gè)實(shí)例只處理一部分?jǐn)?shù)據(jù)。

Graph集群（數(shù)據(jù)存儲(chǔ)、規(guī)定、查詢(xún)接口）：

falcon-agent將數(shù)據(jù)上報(bào)給transfer后，transfer轉(zhuǎn)發(fā)給Graph集群，使用一致性hash做數(shù)據(jù)分片。一個(gè)實(shí)例只處理一部分?jǐn)?shù)據(jù)。rrdtool的數(shù)據(jù)歸檔方式存儲(chǔ)，同時(shí)提供RPC接口。

Alarm（告警）：

Judge判斷后，放到redis隊(duì)列。alarm從redis隊(duì)列讀取報(bào)警事件做處理，該發(fā)短信發(fā)短信、該發(fā)郵件發(fā)郵件，該回調(diào)接口就回調(diào)。告警合并也在alarm里面做的，專(zhuān)門(mén)發(fā)送報(bào)警的sender模塊，告警合并依賴(lài)的links模塊。

Query：

因?yàn)镚raph做過(guò)分片處理，query要采用和transfer一致的一致性hash數(shù)據(jù)分片。對(duì)外提供一個(gè)http接口。query是go寫(xiě)的后端模塊。

Dashborad：

在dashborad里面查詢(xún)監(jiān)控?cái)?shù)據(jù)，是python做的web。

Portal：

portal是python做的web，配置監(jiān)控策略，然后寫(xiě)入數(shù)據(jù)庫(kù)。

Heartbeat server：

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

數(shù)據(jù)存儲(chǔ)：

對(duì)于監(jiān)控系統(tǒng)來(lái)講，歷史數(shù)據(jù)的存儲(chǔ)和高效率查詢(xún)，永遠(yuǎn)是個(gè)很難的問(wèn)題！

????數(shù)據(jù)量大：目前我們的監(jiān)控系統(tǒng)，每個(gè)周期，大概有2000萬(wàn)次數(shù)據(jù)上報(bào)（上報(bào)周期為1分鐘和5分鐘兩種，各占50%），一天24小時(shí)里，從來(lái)不會(huì)有業(yè)務(wù)低峰，不管是白天和黑夜，每個(gè)周期，總會(huì)有那么多的數(shù)據(jù)要更新。

????寫(xiě)操作多：一般的業(yè)務(wù)系統(tǒng)，通常都是讀多寫(xiě)少，可以方便的使用各種緩存技術(shù)，再者各類(lèi)數(shù)據(jù)庫(kù)，對(duì)于查詢(xún)操作的處理效率遠(yuǎn)遠(yuǎn)高于寫(xiě)操作。而監(jiān)控系統(tǒng)恰恰相反，寫(xiě)操作遠(yuǎn)遠(yuǎn)高于讀。每個(gè)周期幾千萬(wàn)次的更新操作，對(duì)于常用數(shù)據(jù)庫(kù)（MySQL、postgresql、mongodb）都是無(wú)法完成的。

????高效率的查：我們說(shuō)監(jiān)控系統(tǒng)讀操作少，是說(shuō)相對(duì)寫(xiě)入來(lái)講。監(jiān)控系統(tǒng)本身對(duì)于讀的要求很高，用戶經(jīng)常會(huì)有查詢(xún)上百個(gè)meitric，在過(guò)去一天、一周、一月、一年的數(shù)據(jù)。如何在1秒內(nèi)返回給用戶并繪圖，這是一個(gè)不小的挑戰(zhàn)。

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

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

//?1分鐘一個(gè)點(diǎn)存?12小時(shí)
c.RRA("AVERAGE",?0.5,?1,?720)

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

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

//?3小時(shí)一個(gè)點(diǎn)存3個(gè)月
c.RRA("AVERAGE",?0.5,?180,?766)
c.RRA("MAX",?0.5,?180,?766)
c.RRA("MIN",?0.5,?180,?766)

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

對(duì)于原始數(shù)據(jù)，transfer會(huì)打一份到hbase，也可以直接使用opentsdb，transfer支持往opentsdb寫(xiě)入數(shù)據(jù)。