運維架構服務監控Open-Falcon

一、 介紹

監控系統是整個運維環節，乃至整個産品生命周期中最重要的一環，事前及時預警發現故障，事後提供翔實的資料用于追查定位問題。監控系統作為一個成熟的運維産品，業界有很多開源的實作可供選擇。當公司剛剛起步，業務規模較小，運維團隊也剛剛建立的初期，選擇一款開源的監控系統，是一個省時省力，效率最高的方案。之後，随着業務規模的持續快速增長，監控的對象也越來越多，越來越複雜，監控系統的使用對象也從最初少數的幾個SRE，擴大為更多的DEVS，SRE。這時候，監控系統的容量和使用者的“使用效率”成了最為突出的問題。

監控系統業界有很多傑出的開源監控系統。我們在早期，一直在用zabbix，不過随着業務的快速發展，以及網際網路公司特有的一些需求，現有的開源的監控系統在性能、擴充性、和使用者的使用效率方面，已經無法支撐了。

是以，我們在過去的一年裡，從網際網路公司的一些需求出發，從各位SRE、SA、DEVS的使用經驗和回報出發，結合業界的一些大的網際網路公司做監控，用監控的一些思考出發，設計開發了小米的監控系統：open-falcon。

二、 特點

1、強大靈活的資料采集：自動發現，支援falcon-agent、snmp、支援使用者主動push、使用者自定義插件支援、opentsdb data model like（timestamp、endpoint、metric、key-value tags）

2、水準擴充能力：支援每個周期上億次的資料采集、告警判定、曆史資料存儲和查詢

3、高效率的告警政策管理：高效的portal、支援政策模闆、模闆繼承和覆寫、多種告警方式、支援callback調用

4、人性化的告警設定：最大告警次數、告警級别、告警恢複通知、告警暫停、不同時段不同門檻值、支援維護周期

5、高效率的graph元件：單機支撐200萬metric的上報、歸檔、存儲（周期為1分鐘）

6、高效的曆史資料query元件：采用rrdtool的資料歸檔政策，秒級傳回上百個metric一年的曆史資料

7、dashboard：多元度的資料展示，使用者自定義Screen

8、高可用：整個系統無核心單點，易運維，易部署，可水準擴充

9、開發語言： 整個系統的後端，全部golang編寫，portal和dashboard使用python編寫。

三、 架構

每台伺服器，都有安裝falcon-agent，falcon-agent是一個golang開發的daemon程式，用于自發現的采集單機的各種資料和名額，這些名額包括不限于以下幾個方面，共計200多項名額。

隻要安裝了falcon-agent的機器，就會自動開始采集各項名額，主動上報，不需要使用者在server做任何配置（這和zabbix有很大的不同），這樣做的好處，就是使用者維護友善，覆寫率高。當然這樣做也會server端造成較大的壓力，不過open-falcon的服務端元件單機性能足夠高，同時都可以水準擴充，是以自動多采集足夠多的資料，反而是一件好事情，對于SRE和DEV來講，事後追查問題，不再是難題。

另外，falcon-agent提供了一個proxy-gateway，使用者可以友善的通過http接口，push資料到本機的gateway，gateway會幫忙高效率的轉發到server端。

四、 資料模型

Data Model是否強大，是否靈活，對于監控系統使用者的“使用效率”至關重要。比如以zabbix為例，上報的資料為hostname（或者ip）、metric，那麼使用者添加告警政策、管理告警政策的時候，就隻能以這兩個次元進行。舉一個最常見的場景：

hostA的磁盤空間，小于5%，就告警。一般的伺服器上，都會有兩個主要的分區，根分區和home分區，在zabbix裡面，就得加兩條規則；如果是hadoop的機器，一般還會有十幾塊的資料盤，還得再加10多條規則，這樣就會痛苦，不幸福，不利于自動化（當然zabbix可以通過配置一些自動發現政策來搞定這個，不過比較麻煩）。

五、 資料收集

transfer，接收用戶端發送的資料，做一些資料規整，檢查之後，轉發到多個後端系統去處理。在轉發到每個後端業務系統的時候，transfer會根據一緻性hash算法，進行資料分片，來達到後端業務系統的水準擴充。

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

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

transfer的資料來源，一般有三種：

1、falcon-agent采集的基礎監控資料

2、falcon-agent執行使用者自定義的插件傳回的資料

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

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

基礎監控是指隻要是個機器(或容器)就能加的監控，比如cpu mem net io disk等，這些監控采集的方式固定，不需要配置，也不需要使用者提供額外參數指定，隻要agent跑起來就可以直接采集上報上去； 非基礎監控則相反，比如端口監控，你不給我端口号就不行，不然我上報所有65535個端口的監聽狀态你也用不了，這類監控需要使用者配置後才會開始采集上報的監控（包括類似于端口監控的配置觸發類監控，以及類似于mysql的插件腳本類監控），一般就不算基礎監控的範疇了。

六、 報警

報警判定，是由judge元件來完成。使用者在web portal來配置相關的報警政策，存儲在MySQL中。heartbeat server 會定期加載MySQL中的内容。judge也會定期和heartbeat server保持溝通，來擷取相關的報警政策。

heartbeat sever不僅僅是單純的加載MySQL中的内容，根據模闆繼承、模闆項覆寫、報警動作覆寫、模闆和hostGroup綁定，計算出最終關聯到每個endpoint的告警政策，提供給judge元件來使用。

transfer轉發到judge的每條資料，都會觸發相關政策的判定，來決定是否滿足報警條件，如果滿足條件，則會發送給alarm，alarm再以郵件、短信、米聊等形式通知相關使用者，也可以執行使用者預先配置好的callback位址。

使用者可以很靈活的來配置告警判定政策，比如連續n次都滿足條件、連續n次的最大值滿足條件、不同的時間段不同的門檻值、如果處于維護周期内則忽略 等等。

另外也支援突升突降類的判定和告警。

七、 API

到這裡，資料已經成功的存儲在了graph裡。如何快速的讀出來呢，讀過去1小時的，過去1天的，過去一月的，過去一年的，都需要在1秒之内傳回。

這些都是靠graph和API元件來實作的，transfer會将資料往graph元件轉發一份，graph收到資料以後，會以rrdtool的資料歸檔方式來存儲，同時提供查詢RPC接口。

API面向終端使用者，收到查詢請求後，會去多個graph裡面，查詢不同metric的資料，彙總後統一傳回給使用者。

八、 面闆

九、 存儲

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

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

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

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

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

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