小米運(yùn)維—互聯(lián)網(wǎng)企業(yè)級(jí)監(jiān)控系統(tǒng)實(shí)踐
Introduction
監(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è)界有很多開源的實(shí)現(xiàn)可供選擇。當(dāng)公司剛剛起步,業(yè)務(wù)規(guī)模較小,運(yùn)維團(tuán)隊(duì)也剛剛建立的初期,選擇一款開源的監(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)的容量和用戶的“使用效率”成了最為突出的問(wèn)題。
監(jiān)控系統(tǒng)業(yè)界有很多杰出的開源監(jiān)控系統(tǒng)。我們?cè)谠缙?,一直在用zabbix,不過(guò)隨著業(yè)務(wù)的快速發(fā)展,以及互聯(lián)網(wǎng)公司特有的一些需求,現(xiàn)有的開源的監(jiān)控系統(tǒng)在性能、擴(kuò)展性、和用戶的使用效率方面,已經(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ì)開發(fā)了小米的監(jiān)控系統(tǒng):open-falcon。
open-falcon的目標(biāo)是做最開放、最好用的互聯(lián)網(wǎng)企業(yè)級(jí)監(jiān)控產(chǎn)品。
Highlights and features
強(qiáng)大靈活的數(shù)據(jù)采集:自動(dòng)發(fā)現(xiàn),支持falcon-agent、snmp、支持用戶主動(dòng)push、用戶自定義插件支持、opentsdb data model like(timestamp、endpoint、metric、key-value tags)
水平擴(kuò)展能力:支持每個(gè)周期上億次的數(shù)據(jù)采集、告警判定、歷史數(shù)據(jù)存儲(chǔ)和查詢
高效率的告警策略管理:高效的portal、支持策略模板、模板繼承和覆蓋、多種告警方式、支持callback調(diào)用
人性化的告警設(shè)置:最大告警次數(shù)、告警級(jí)別、告警恢復(fù)通知、告警暫停、不同時(shí)段不同閾值、支持維護(hù)周期
高效率的graph組件:?jiǎn)螜C(jī)支撐200萬(wàn)metric的上報(bào)、歸檔、存儲(chǔ)(周期為1分鐘)
高效的歷史數(shù)據(jù)query組件:采用rrdtool的數(shù)據(jù)歸檔策略,秒級(jí)返回上百個(gè)metric一年的歷史數(shù)據(jù)
dashboard:多維度的數(shù)據(jù)展示,用戶自定義Screen
高可用:整個(gè)系統(tǒng)無(wú)核心單點(diǎn),易運(yùn)維,易部署,可水平擴(kuò)展
開發(fā)語(yǔ)言: 整個(gè)系統(tǒng)的后端,全部golang編寫,portal和dashboard使用python編寫。
Architecture
open-falcon architecture
備注:虛線所在的aggregator組件還在設(shè)計(jì)開發(fā)階段。
每臺(tái)服務(wù)器,都有安裝falcon-agent,falcon-agent是一個(gè)golang開發(fā)的daemon程序,用于自發(fā)現(xiàn)的采集單機(jī)的各種數(shù)據(jù)和指標(biāo),這些指標(biāo)包括不限于以下幾個(gè)方面,共計(jì)400多項(xiàng)指標(biāo)。
● CPU相關(guā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)開始采集各項(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/agent
Data model
Data Model是否強(qiáng)大,是否靈活,對(duì)于監(jiān)控系統(tǒng)用戶的“使用效率”至關(guān)重要。比如以zabbix為例,上報(bào)的數(shù)據(jù)為hostname(或者ip)、metric,那么用戶添加告警策略、管理告警策略的時(shí)候,就只能以這兩個(gè)維度進(jìn)行。舉一個(gè)最常見的場(chǎng)景:
hostA的磁盤空間,小于5%,就告警。一般的服務(wù)器上,都會(huì)有兩個(gè)主要的分區(qū),根分區(qū)和home分區(qū),在zabbix里面,就得加兩條規(guī)則;如果是hadoop的機(jī)器,一般還會(huì)有十幾塊的數(shù)據(jù)盤,還得再加10多條規(guī)則,這樣就會(huì)痛苦,不幸福,不利于自動(dòng)化(當(dāng)然zabbix可以通過(guò)配置一些自動(dòng)發(fā)現(xiàn)策略來(lái)搞定這個(gè),不過(guò)比較麻煩)。
open-falcon,采用和opentsdb相同的數(shù)據(jù)格式:metric、endpoint加多組key value tags,舉兩個(gè)例子:
- {
- metric: load.1min,
- endpoint: open-falcon-host,
- tags: srv=falcon,idc=aws-sgp,group=az1,
- value: 1.5,
- timestamp: `date +%s`,
- counterType: GAUGE,
- step: 60
- }
- {
- metric: net.port.listen,
- endpoint: open-falcon-host,
- tags: port=3306,
- value: 1,
- timestamp: `date +%s`,
- counterType: GAUGE,
- step: 60
- }
通過(guò)這樣的數(shù)據(jù)結(jié)構(gòu),我們就可以從多個(gè)維度來(lái)配置告警,配置dashboard等等。
備注:endpoint是一個(gè)特殊的tag。#p#
Data collection
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是我們開發(fā)的高性能告警判定組件,graph是我們開發(fā)的高性能數(shù)據(jù)存儲(chǔ)、歸檔、查詢組件,opentsdb是開源的時(shí)間序列數(shù)據(jù)存儲(chǔ)服務(wù)??梢酝ㄟ^(guò)transfer的配置文件來(lá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。
Alerting
報(bào)警判定,是由judge組件來(lái)完成。用戶在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)決定是否滿足報(bào)警條件,如果滿足條件,則會(huì)發(fā)送給alarm,alarm再以郵件、短信、米聊等形式通知相關(guān)用戶,也可以執(zhí)行用戶預(yù)先配置好的callback地址。
用戶可以很靈活的來(lái)配置告警判定策略,比如連續(xù)n次都滿足條件、連續(xù)n次的最大值滿足條件、不同的時(shí)間段不同的閾值、如果處于維護(hù)周期內(nèi)則忽略 等等。
Query
到這里,數(shù)據(jù)已經(jīng)成功的存儲(chǔ)在了graph里。如何快速的讀出來(lái)呢,讀過(guò)去1小時(shí)的,過(guò)去1天的,過(guò)去一月的,過(guò)去一年的,都需要在1秒之內(nèi)返回。
這些都是靠graph和query組件來(lái)實(shí)現(xiàn)的,transfer會(huì)將數(shù)據(jù)往graph組件轉(zhuǎn)發(fā)一份,graph收到數(shù)據(jù)以后,會(huì)以rrdtool的數(shù)據(jù)歸檔方式來(lái)存儲(chǔ),同時(shí)提供查詢RPC接口。
query面向終端用戶,收到查詢請(qǐng)求后,會(huì)去多個(gè)graph里面,查詢不同metric的數(shù)據(jù),匯總后統(tǒng)一返回給用戶。
Dashboard
dashboard首頁(yè),用戶可以以多個(gè)維度來(lái)搜索endpoint列表,即可以根據(jù)上報(bào)的tags來(lái)搜索關(guān)聯(lián)的endpoint。
open-falcon dashboard homepage
用戶可以自定義多個(gè)metric,添加到某個(gè)screen中,這樣每天早上只需要打開screen看一眼,服務(wù)的運(yùn)行情況便盡在掌握了。
open-falcon dashboard screen
當(dāng)然,也可以查看清晰大圖,橫坐標(biāo)上zoom in/out,快速篩選反選。總之用戶的“使用效率”是第一要?jiǎng)?wù)。
open-falcon big graph#p#
Web portal
一個(gè)高效的portal,對(duì)于提升用戶的“使用效率”,加成很大,平時(shí)大家都這么忙,能給各位SRE、Devs減輕一些負(fù)擔(dān),那是再好不過(guò)了。
這是host group的管理頁(yè)面,可以和服務(wù)樹結(jié)合,機(jī)器進(jìn)出服務(wù)樹節(jié)點(diǎn),相關(guān)的模板會(huì)自動(dòng)關(guān)聯(lián)或者解除。這樣服務(wù)上下線,都不需要手動(dòng)來(lái)變更監(jiān)控,大大提高效率,降低遺漏和誤報(bào)警。
open-falcon portal HostGroup
一個(gè)最簡(jiǎn)單的模板的例子,模板支持繼承和策略覆蓋,模板和host group綁定后,host group下的機(jī)器會(huì)自動(dòng)應(yīng)用該模板的所有策略。
open-falcon template
當(dāng)然,也可以寫一個(gè)簡(jiǎn)單的表達(dá)式,就能達(dá)到監(jiān)控的目的,這對(duì)于那些endpoint不是機(jī)器名的場(chǎng)景非常方便。

open-falcon expression
添加一個(gè)表達(dá)式也是很簡(jiǎn)單的。
open-falcon add an expression
Storage
對(duì)于監(jiān)控系統(tǒng)來(lái)講,歷史數(shù)據(jù)的存儲(chǔ)和高效率查詢,永遠(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ù)要更新。
寫操作多:一般的業(yè)務(wù)系統(tǒng),通常都是讀多寫少,可以方便的使用各種緩存技術(shù),再者各類數(shù)據(jù)庫(kù),對(duì)于查詢操作的處理效率遠(yuǎn)遠(yuǎn)高于寫操作。而監(jiān)控系統(tǒng)恰恰相反,寫操作遠(yuǎn)遠(yuǎn)高于讀。每個(gè)周期幾千萬(wàn)次的更新操作,對(duì)于常用數(shù)據(jù)庫(kù)(MySQL、postgresql、mongodb)都是無(wú)法完成的。
高效率的查:我們說(shuō)監(jiān)控系統(tǒng)讀操作少,是說(shuō)相對(duì)寫入來(lái)講。監(jiān)控系統(tǒng)本身對(duì)于讀的要求很高,用戶經(jīng)常會(huì)有查詢上百個(gè)meitric,在過(guò)去一天、一周、一月、一年的數(shù)據(jù)。如何在1秒內(nèi)返回給用戶并繪圖,這是一個(gè)不小的挑戰(zhàn)。
open-falcon在這塊,投入了較大的精力。我們把數(shù)據(jù)按照用途分成兩類,一類是用來(lái)繪圖的,一類是用戶做數(shù)據(jù)挖掘的。
對(duì)于繪圖的數(shù)據(jù)來(lái)講,查詢要快是關(guān)鍵,同時(shí)不能丟失信息量。對(duì)于用戶要查詢100個(gè)metric,在過(guò)去一年里的數(shù)據(jù)時(shí),數(shù)據(jù)量本身就在那里了,很難1秒之類能返回,另外就算返回了,前端也無(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)存5year
- 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寫入數(shù)據(jù)。
Committers
laiwei: https://github.com/laiwei 來(lái)煒沒(méi)睡醒@微博 / hellolaiwei@微信
秦曉輝: https://github.com/ulricqin Ulricqin@微博 cnperl@微信
Contributors
近期我們會(huì)把絕大數(shù)的組件整理到 http://github.com/open-falcon , 期待大家一起貢獻(xiàn),推動(dòng),做最開放、最好用的企業(yè)級(jí)監(jiān)控系統(tǒng)。
TODO
metric的聚合
環(huán)比、同比報(bào)警判定
流量的突升突降判定