最近公司需要開(kāi)發(fā)一個(gè)監(jiān)控預(yù)警平臺(tái)，剛好負(fù)責(zé)這一塊，小米開(kāi)源監(jiān)控平臺(tái)整體表現(xiàn)還是差強(qiáng)人意的，故使用該平臺(tái)，我也記錄一下學(xué)習(xí)歷程。

以下介紹來(lái)自于官方文檔和互聯(lián)網(wǎng)相關(guān)資料自我總結(jié)歸納

一、介紹

監(jiān)控系統(tǒng)是整個(gè)運(yùn)維環(huán)節(jié)，乃至整個(gè)產(chǎn)品生命周期中最重要的一環(huán)，事前及時(shí)預(yù)警發(fā)現(xiàn)故障，事后提供翔實(shí)的數(shù)據(jù)用于追查定位問(wèn)題。監(jiān)控系統(tǒng)作為一個(gè)成熟的運(yùn)維產(chǎn)品，業(yè)界有很多開(kāi)源的實(shí)現(xiàn)可供選擇。當(dāng)公司剛剛起步，業(yè)務(wù)規(guī)模較小，運(yùn)維團(tuán)隊(duì)也剛剛建立的初期，選擇一款開(kāi)源的監(jiān)控系統(tǒng)，是一個(gè)省時(shí)省力，效率最高的方案。之后，隨著業(yè)務(wù)規(guī)模的持續(xù)快速增長(zhǎng)，監(jiān)控的對(duì)象也越來(lái)越多，越來(lái)越復(fù)雜，監(jiān)控系統(tǒng)的使用對(duì)象也從最初少數(shù)的幾個(gè)SRE，擴(kuò)大為更多的DEVS，SRE。這時(shí)候，監(jiān)控系統(tǒng)的容量和用戶(hù)的“使用效率”成了最為突出的問(wèn)題。

監(jiān)控系統(tǒng)業(yè)界有很多杰出的開(kāi)源監(jiān)控系統(tǒng)。我們?cè)谠缙冢恢痹谟脄abbix，不過(guò)隨著業(yè)務(wù)的快速發(fā)展，以及互聯(lián)網(wǎng)公司特有的一些需求，現(xiàn)有的開(kāi)源的監(jiān)控系統(tǒng)在性能、擴(kuò)展性、和用戶(hù)的使用效率方面，已經(jīng)無(wú)法支撐了。

因此，我們?cè)谶^(guò)去的一年里，從互聯(lián)網(wǎng)公司的一些需求出發(fā)，從各位SRE、SA、DEVS的使用經(jīng)驗(yàn)和反饋出發(fā)，結(jié)合業(yè)界的一些大的互聯(lián)網(wǎng)公司做監(jiān)控，用監(jiān)控的一些思考出發(fā)，設(shè)計(jì)開(kāi)發(fā)了小米的監(jiān)控系統(tǒng)：open-falcon。

二、特點(diǎn)

1、強(qiáng)大靈活的數(shù)據(jù)采集：自動(dòng)發(fā)現(xiàn)，支持falcon-agent、snmp、支持用戶(hù)主動(dòng)push、用戶(hù)自定義插件支持、opentsdb data model like（timestamp、endpoint、metric、key-value tags）

2、水平擴(kuò)展能力：支持每個(gè)周期上億次的數(shù)據(jù)采集、告警判定、歷史數(shù)據(jù)存儲(chǔ)和查詢(xún)

3、高效率的告警策略管理：高效的portal、支持策略模板、模板繼承和覆蓋、多種告警方式、支持callback調(diào)用

4、人性化的告警設(shè)置：最大告警次數(shù)、告警級(jí)別、告警恢復(fù)通知、告警暫停、不同時(shí)段不同閾值、支持維護(hù)周期

5、高效率的graph組件：?jiǎn)螜C(jī)支撐200萬(wàn)metric的上報(bào)、歸檔、存儲(chǔ)（周期為1分鐘）

6、高效的歷史數(shù)據(jù)query組件：采用rrdtool的數(shù)據(jù)歸檔策略，秒級(jí)返回上百個(gè)metric一年的歷史數(shù)據(jù)

7、dashboard：多維度的數(shù)據(jù)展示，用戶(hù)自定義Screen

8、高可用：整個(gè)系統(tǒng)無(wú)核心單點(diǎn)，易運(yùn)維，易部署，可水平擴(kuò)展

9、開(kāi)發(fā)語(yǔ)言： 整個(gè)系統(tǒng)的后端，全部golang編寫(xiě)，portal和dashboard使用python編寫(xiě)。

三、架構(gòu)

每臺(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)，不需要用戶(hù)在server做任何配置（這和zabbix有很大的不同），這樣做的好處，就是用戶(hù)維護(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，用戶(hù)可以方便的通過(guò)http接口，push數(shù)據(jù)到本機(jī)的gateway，gateway會(huì)幫忙高效率的轉(zhuǎn)發(fā)到server端。

四、數(shù)據(jù)模型

Data Model是否強(qiáng)大，是否靈活，對(duì)于監(jiān)控系統(tǒng)用戶(hù)的“使用效率”至關(guān)重要。比如以zabbix為例，上報(bào)的數(shù)據(jù)為hostname（或者ip）、metric，那么用戶(hù)添加告警策略、管理告警策略的時(shí)候，就只能以這兩個(gè)維度進(jìn)行。舉一個(gè)最常見(jiàn)的場(chǎng)景：

hostA的磁盤(pán)空間，小于5%，就告警。一般的服務(wù)器上，都會(huì)有兩個(gè)主要的分區(qū)，根分區(qū)和home分區(qū)，在zabbix里面，就得加兩條規(guī)則；如果是hadoop的機(jī)器，一般還會(huì)有十幾塊的數(shù)據(jù)盤(pán)，還得再加10多條規(guī)則，這樣就會(huì)痛苦，不幸福，不利于自動(dòng)化（當(dāng)然zabbix可以通過(guò)配置一些自動(dòng)發(fā)現(xiàn)策略來(lái)搞定這個(gè)，不過(guò)比較麻煩）。

五、數(shù)據(jù)收集

transfer，接收客戶(hù)端發(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)源，一般有三種：

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

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

3、client library：線(xiàn)上的業(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。

基礎(chǔ)監(jiān)控是指只要是個(gè)機(jī)器(或容器)就能加的監(jiān)控，比如cpu mem net io disk等，這些監(jiān)控采集的方式固定，不需要配置，也不需要用戶(hù)提供額外參數(shù)指定，只要agent跑起來(lái)就可以直接采集上報(bào)上去； 非基礎(chǔ)監(jiān)控則相反，比如端口監(jiān)控，你不給我端口號(hào)就不行，不然我上報(bào)所有65535個(gè)端口的監(jiān)聽(tīng)狀態(tài)你也用不了，這類(lèi)監(jiān)控需要用戶(hù)配置后才會(huì)開(kāi)始采集上報(bào)的監(jiān)控（包括類(lèi)似于端口監(jiān)控的配置觸發(fā)類(lèi)監(jiān)控，以及類(lèi)似于mysql的插件腳本類(lèi)監(jiān)控），一般就不算基礎(chǔ)監(jiān)控的范疇了。

六、 預(yù)警

報(bào)警判定，是由judge組件來(lái)完成。用戶(hù)在web portal來(lái)配置相關(guān)的報(bào)警策略，存儲(chǔ)在MySQL中。heartbeat server 會(huì)定期加載MySQL中的內(nèi)容。judge也會(huì)定期和heartbeat server保持溝通，來(lái)獲取相關(guān)的報(bào)警策略。

heartbeat sever不僅僅是單純的加載MySQL中的內(nèi)容，根據(jù)模板繼承、模板項(xiàng)覆蓋、報(bào)警動(dòng)作覆蓋、模板和hostGroup綁定，計(jì)算出最終關(guān)聯(lián)到每個(gè)endpoint的告警策略，提供給judge組件來(lái)使用。

transfer轉(zhuǎn)發(fā)到j(luò)udge的每條數(shù)據(jù)，都會(huì)觸發(fā)相關(guān)策略的判定，來(lái)決定是否滿(mǎn)足報(bào)警條件，如果滿(mǎn)足條件，則會(huì)發(fā)送給alarm，alarm再以郵件、短信、米聊等形式通知相關(guān)用戶(hù)，也可以執(zhí)行用戶(hù)預(yù)先配置好的callback地址。

用戶(hù)可以很靈活的來(lái)配置告警判定策略，比如連續(xù)n次都滿(mǎn)足條件、連續(xù)n次的最大值滿(mǎn)足條件、不同的時(shí)間段不同的閾值、如果處于維護(hù)周期內(nèi)則忽略 等等。

另外也支持突升突降類(lèi)的判定和告警。

七、API

到這里，數(shù)據(jù)已經(jīng)成功的存儲(chǔ)在了graph里。如何快速的讀出來(lái)呢，讀過(guò)去1小時(shí)的，過(guò)去1天的，過(guò)去一月的，過(guò)去一年的，都需要在1秒之內(nèi)返回。

這些都是靠graph和API組件來(lái)實(shí)現(xiàn)的，transfer會(huì)將數(shù)據(jù)往graph組件轉(zhuǎn)發(fā)一份，graph收到數(shù)據(jù)以后，會(huì)以rrdtool的數(shù)據(jù)歸檔方式來(lái)存儲(chǔ)，同時(shí)提供查詢(xún)RPC接口。

API面向終端用戶(hù)，收到查詢(xún)請(qǐng)求后，會(huì)去多個(gè)graph里面，查詢(xún)不同metric的數(shù)據(jù)，匯總后統(tǒng)一返回給用戶(hù)。

八、面板

前端頁(yè)面展示

九、存儲(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ì)于讀的要求很高，用戶(hù)經(jīng)常會(huì)有查詢(xún)上百個(gè)meitric，在過(guò)去一天、一周、一月、一年的數(shù)據(jù)。如何在1秒內(nèi)返回給用戶(hù)并繪圖，這是一個(gè)不小的挑戰(zhàn)。

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

對(duì)于繪圖的數(shù)據(jù)來(lái)講，查詢(xún)要快是關(guān)鍵，同時(shí)不能丟失信息量。對(duì)于用戶(hù)要查詢(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ì)按照平均值采樣、最大值采樣、最小值采樣存三份。

在下一小節(jié)，我將簡(jiǎn)單介紹一下open-falcon的安裝和使用

總結(jié)

以上是生活随笔為你收集整理的一、小米开源监控平台open-falcon介绍的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。