小米運維—互聯(lián)網(wǎng)企業(yè)級監(jiān)控系統(tǒng)實踐
Introduction
監(jiān)控系統(tǒng)是整個運維環(huán)節(jié)，乃至整個產(chǎn)品生命周期中最重要的一環(huán)，事前及時預(yù)警發(fā)現(xiàn)故障，事后提供翔實的數(shù)據(jù)用于追查定位問題。監(jiān)控系統(tǒng)作為一個成熟的運維產(chǎn)品，業(yè)界有很多開源的實現(xiàn)可供選擇。當(dāng)公司剛剛起步，業(yè)務(wù)規(guī)模較小，運維團隊也剛剛建立的初期，選擇一款開源的監(jiān)控系統(tǒng)，是一個省時省力，效率最高的方案。之后，隨著業(yè)務(wù)規(guī)模的持續(xù)快速增長，監(jiān)控的對象也越來越多，越來越復(fù)雜，監(jiān)控系統(tǒng)的使用對象也從最初少數(shù)的幾個SRE，擴大為更多的DEVS，SRE。這時候，監(jiān)控系統(tǒng)的容量和用戶的“使用效率”成了最為突出的問題。
監(jiān)控系統(tǒng)業(yè)界有很多杰出的開源監(jiān)控系統(tǒng)。我們在早期，一直在用zabbix，不過隨著業(yè)務(wù)的快速發(fā)展，以及互聯(lián)網(wǎng)公司特有的一些需求，現(xiàn)有的開源的監(jiān)控系統(tǒng)在性能、擴展性、和用戶的使用效率方面，已經(jīng)無法支撐了。
因此，我們在過去的一年里，從互聯(lián)網(wǎng)公司的一些需求出發(fā)，從各位SRE、SA、DEVS的使用經(jīng)驗和反饋出發(fā)，結(jié)合業(yè)界的一些大的互聯(lián)網(wǎng)公司做監(jiān)控，用監(jiān)控的一些思考出發(fā)，設(shè)計開發(fā)了小米的監(jiān)控系統(tǒng)：open-falcon。
open-falcon的目標(biāo)是做最開放、最好用的互聯(lián)網(wǎng)企業(yè)級監(jiān)控產(chǎn)品。
Highlights and features
強大靈活的數(shù)據(jù)采集：自動發(fā)現(xiàn)，支持falcon-agent、snmp、支持用戶主動push、用戶自定義插件支持、opentsdb data model like(timestamp、endpoint、metric、key-value tags)
水平擴展能力：支持每個周期上億次的數(shù)據(jù)采集、告警判定、歷史數(shù)據(jù)存儲和查詢
高效率的告警策略管理：高效的portal、支持策略模板、模板繼承和覆蓋、多種告警方式、支持callback調(diào)用
人性化的告警設(shè)置：最大告警次數(shù)、告警級別、告警恢復(fù)通知、告警暫停、不同時段不同閾值、支持維護周期
高效率的graph組件：單機支撐200萬metric的上報、歸檔、存儲(周期為1分鐘)
高效的歷史數(shù)據(jù)query組件：采用rrdtool的數(shù)據(jù)歸檔策略，秒級返回上百個metric一年的歷史數(shù)據(jù)
dashboard：多維度的數(shù)據(jù)展示，用戶自定義Screen
高可用：整個系統(tǒng)無核心單點，易運維，易部署，可水平擴展
開發(fā)語言： 整個系統(tǒng)的后端，全部golang編寫，portal和dashboard使用python編寫。
Architecture
open-falcon architecture
備注：虛線所在的aggregator組件還在設(shè)計開發(fā)階段。
每臺服務(wù)器，都有安裝falcon-agent，falcon-agent是一個golang開發(fā)的daemon程序，用于自發(fā)現(xiàn)的采集單機的各種數(shù)據(jù)和指標(biāo)，這些指標(biāo)包括不限于以下幾個方面，共計400多項指標(biāo)。
● CPU相關(guān)
● 磁盤相關(guān)
● IO
● Load
● 內(nèi)存相關(guān)
● 網(wǎng)絡(luò)相關(guān)
● 端口存活、進(jìn)程存活
● ntp offset(插件)
● 某個進(jìn)程資源消耗(插件)
● netstat、ss 等相關(guān)統(tǒng)計項采集
● 機器內(nèi)核配置參數(shù)
只要安裝了falcon-agent的機器，就會自動開始采集各項指標(biāo)，主動上報，不需要用戶在server做任何配置(這和zabbix有很大的不同)，這樣做的好處，就是用戶維護方便，覆蓋率高。當(dāng)然這樣做也會server端造成較大的壓力，不過open-falcon的服務(wù)端組件單機性能足夠高，同時都可以水平擴展，所以自動多采集足夠多的數(shù)據(jù)，反而是一件好事情，對于SRE和DEV來講，事后追查問題，不再是難題。
另外，falcon-agent提供了一個proxy-gateway，用戶可以方便的通過http接口，push數(shù)據(jù)到本機的gateway，gateway會幫忙高效率的轉(zhuǎn)發(fā)到server端。
falcon-agent，可以在我們的github上找到 : https://github.com/open-falcon/agent
Data model
Data Model是否強大，是否靈活，對于監(jiān)控系統(tǒng)用戶的“使用效率”至關(guān)重要。比如以zabbix為例，上報的數(shù)據(jù)為hostname(或者ip)、metric，那么用戶添加告警策略、管理告警策略的時候，就只能以這兩個維度進(jìn)行。舉一個最常見的場景：
hostA的磁盤空間，小于5%，就告警。一般的服務(wù)器上，都會有兩個主要的分區(qū)，根分區(qū)和home分區(qū)，在zabbix里面，就得加兩條規(guī)則;如果是hadoop的機器，一般還會有十幾塊的數(shù)據(jù)盤，還得再加10多條規(guī)則，這樣就會痛苦，不幸福，不利于自動化(當(dāng)然zabbix可以通過配置一些自動發(fā)現(xiàn)策略來搞定這個，不過比較麻煩)。
open-falcon，采用和opentsdb相同的數(shù)據(jù)格式：metric、endpoint加多組key value tags，舉兩個例子：
- {
- 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
- }
通過這樣的數(shù)據(jù)結(jié)構(gòu)，我們就可以從多個維度來配置告警，配置dashboard等等。
備注：endpoint是一個特殊的tag。#p#
Data collection
transfer，接收客戶端發(fā)送的數(shù)據(jù)，做一些數(shù)據(jù)規(guī)整，檢查之后，轉(zhuǎn)發(fā)到多個后端系統(tǒng)去處理。在轉(zhuǎn)發(fā)到每個后端業(yè)務(wù)系統(tǒng)的時候，transfer會根據(jù)一致性hash算法，進(jìn)行數(shù)據(jù)分片，來達(dá)到后端業(yè)務(wù)系統(tǒng)的水平擴展。
transfer 提供jsonRpc接口和telnet接口兩種方式，transfer自身是無狀態(tài)的，掛掉一臺或者多臺不會有任何影響，同時transfer性能很高，每分鐘可以轉(zhuǎn)發(fā)超過500萬條數(shù)據(jù)。
transfer目前支持的業(yè)務(wù)后端，有三種，judge、graph、opentsdb。judge是我們開發(fā)的高性能告警判定組件，graph是我們開發(fā)的高性能數(shù)據(jù)存儲、歸檔、查詢組件，opentsdb是開源的時間序列數(shù)據(jù)存儲服務(wù)?？梢酝ㄟ^transfer的配置文件來開啟。
transfer的數(shù)據(jù)來源，一般有三種：
● falcon-agent采集的基礎(chǔ)監(jiān)控數(shù)據(jù)
● falcon-agent執(zhí)行用戶自定義的插件返回的數(shù)據(jù)
● client library：線上的業(yè)務(wù)系統(tǒng)，都嵌入使用了統(tǒng)一的perfcounter.jar，對于業(yè)務(wù)系統(tǒng)中每個RPC接口的qps、latency都會主動采集并上報
說明：上面這三種數(shù)據(jù)，都會先發(fā)送給本機的proxy-gateway，再由gateway轉(zhuǎn)發(fā)給transfer。
Alerting
報警判定，是由judge組件來完成。用戶在web portal來配置相關(guān)的報警策略，存儲在MySQL中。heartbeat server 會定期加載MySQL中的內(nèi)容。judge也會定期和heartbeat server保持溝通，來獲取相關(guān)的報警策略。
heartbeat sever不僅僅是單純的加載MySQL中的內(nèi)容，根據(jù)模板繼承、模板項覆蓋、報警動作覆蓋、模板和hostGroup綁定，計算出最終關(guān)聯(lián)到每個endpoint的告警策略，提供給judge組件來使用。
transfer轉(zhuǎn)發(fā)到j(luò)udge的每條數(shù)據(jù)，都會觸發(fā)相關(guān)策略的判定，來決定是否滿足報警條件，如果滿足條件，則會發(fā)送給alarm，alarm再以郵件、短信、米聊等形式通知相關(guān)用戶，也可以執(zhí)行用戶預(yù)先配置好的callback地址。
用戶可以很靈活的來配置告警判定策略，比如連續(xù)n次都滿足條件、連續(xù)n次的最大值滿足條件、不同的時間段不同的閾值、如果處于維護周期內(nèi)則忽略 等等。
Query
到這里，數(shù)據(jù)已經(jīng)成功的存儲在了graph里。如何快速的讀出來呢，讀過去1小時的，過去1天的，過去一月的，過去一年的，都需要在1秒之內(nèi)返回。
這些都是靠graph和query組件來實現(xiàn)的，transfer會將數(shù)據(jù)往graph組件轉(zhuǎn)發(fā)一份，graph收到數(shù)據(jù)以后，會以rrdtool的數(shù)據(jù)歸檔方式來存儲，同時提供查詢RPC接口。
query面向終端用戶，收到查詢請求后，會去多個graph里面，查詢不同metric的數(shù)據(jù)，匯總后統(tǒng)一返回給用戶。
Dashboard
dashboard首頁，用戶可以以多個維度來搜索endpoint列表，即可以根據(jù)上報的tags來搜索關(guān)聯(lián)的endpoint。
open-falcon dashboard homepage
用戶可以自定義多個metric，添加到某個screen中，這樣每天早上只需要打開screen看一眼，服務(wù)的運行情況便盡在掌握了。
open-falcon dashboard screen
當(dāng)然，也可以查看清晰大圖，橫坐標(biāo)上zoom in/out，快速篩選反選?？傊脩舻?ldquo;使用效率”是第一要務(wù)。
open-falcon big graph#p#
Web portal
一個高效的portal，對于提升用戶的“使用效率”，加成很大，平時大家都這么忙，能給各位SRE、Devs減輕一些負(fù)擔(dān)，那是再好不過了。
這是host group的管理頁面，可以和服務(wù)樹結(jié)合，機器進(jìn)出服務(wù)樹節(jié)點，相關(guān)的模板會自動關(guān)聯(lián)或者解除。這樣服務(wù)上下線，都不需要手動來變更監(jiān)控，大大提高效率，降低遺漏和誤報警。
open-falcon portal HostGroup
一個最簡單的模板的例子，模板支持繼承和策略覆蓋，模板和host group綁定后，host group下的機器會自動應(yīng)用該模板的所有策略。
open-falcon template
當(dāng)然，也可以寫一個簡單的表達(dá)式，就能達(dá)到監(jiān)控的目的，這對于那些endpoint不是機器名的場景非常方便。
open-falcon expression
添加一個表達(dá)式也是很簡單的。
open-falcon add an expression
Storage
對于監(jiān)控系統(tǒng)來講，歷史數(shù)據(jù)的存儲和高效率查詢，永遠(yuǎn)是個很難的問題!
數(shù)據(jù)量大：目前我們的監(jiān)控系統(tǒng)，每個周期，大概有2000萬次數(shù)據(jù)上報(上報周期為1分鐘和5分鐘兩種，各占50%)，一天24小時里，從來不會有業(yè)務(wù)低峰，不管是白天和黑夜，每個周期，總會有那么多的數(shù)據(jù)要更新。
寫操作多：一般的業(yè)務(wù)系統(tǒng)，通常都是讀多寫少，可以方便的使用各種緩存技術(shù)，再者各類數(shù)據(jù)庫，對于查詢操作的處理效率遠(yuǎn)遠(yuǎn)高于寫操作。而監(jiān)控系統(tǒng)恰恰相反，寫操作遠(yuǎn)遠(yuǎn)高于讀。每個周期幾千萬次的更新操作，對于常用數(shù)據(jù)庫(MySQL、postgresql、mongodb)都是無法完成的。
高效率的查：我們說監(jiān)控系統(tǒng)讀操作少，是說相對寫入來講。監(jiān)控系統(tǒng)本身對于讀的要求很高，用戶經(jīng)常會有查詢上百個meitric，在過去一天、一周、一月、一年的數(shù)據(jù)。如何在1秒內(nèi)返回給用戶并繪圖，這是一個不小的挑戰(zhàn)。
open-falcon在這塊，投入了較大的精力。我們把數(shù)據(jù)按照用途分成兩類，一類是用來繪圖的，一類是用戶做數(shù)據(jù)挖掘的。
對于繪圖的數(shù)據(jù)來講，查詢要快是關(guān)鍵，同時不能丟失信息量。對于用戶要查詢100個metric，在過去一年里的數(shù)據(jù)時，數(shù)據(jù)量本身就在那里了，很難1秒之類能返回，另外就算返回了，前端也無法渲染這么多的數(shù)據(jù)，還得采樣，造成很多無謂的消耗和浪費。我們參考rrdtool的理念，在數(shù)據(jù)每次存入的時候，會自動進(jìn)行采樣、歸檔。我們的歸檔策略如下，歷史數(shù)據(jù)保存5年。同時為了不丟失信息量，數(shù)據(jù)歸檔的時候，會按照平均值采樣、最大值采樣、最小值采樣存三份。
- // 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天一個點存5year
- c.RRA("AVERAGE", 0.5, 720, 730)
- c.RRA("MAX", 0.5, 720, 730)
- c.RRA("MIN", 0.5, 720, 730)
對于原始數(shù)據(jù)，transfer會打一份到hbase，也可以直接使用opentsdb，transfer支持往opentsdb寫入數(shù)據(jù)。
Committers
laiwei: https://github.com/laiwei 來煒沒睡醒@微博 / hellolaiwei@微信
秦曉輝: https://github.com/ulricqin Ulricqin@微博 cnperl@微信
Contributors
近期我們會把絕大數(shù)的組件整理到 http://github.com/open-falcon ， 期待大家一起貢獻(xiàn)，推動，做最開放、最好用的企業(yè)級監(jiān)控系統(tǒng)。
TODO
metric的聚合
環(huán)比、同比報警判定
流量的突升突降判定
