運維監控-Open-Falcon介紹

　　　　　　　　　　　　　　　　　　運維監控-Open-Falcon介紹

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　作者：尹正傑

版權聲明：原創作品，謝絕轉載！否則將追究法律責任。

 

 

一.Open-Falcon 介紹

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

　　監控系統業界有很多傑出的開源監控系統。我們在早期，一直在用zabbix，不過隨着業務的快速發展，以及互聯網公司特有的一些需求，現有的開源的監控系統在性能、擴展性、和用戶的使用效率方面，已經無法支撐了。因此，我們在過去的一年里，從互聯網公司的一些需求出發，從各位SRE、SA、DEVS的使用經驗和反饋出發，結合業界的一些大的互聯網公司做監控，用監控的一些思考出發，設計開發了小米的監控系統：open-falcon。

 

二.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編寫。

 

三.Open-Falcon

 

備注：虛線所在的aggregator組件還在設計開發階段。

每台服務器，都有安裝falcon-agent，falcon-agent是一個golang開發的daemon程序，用於自發現的采集單機的各種數據和指標，這些指標包括不限於以下幾個方面，共計200多項指標。

• CPU相關
• 磁盤相關
• IO
• Load
• 內存相關
• 網絡相關
• 端口存活、進程存活
• ntp offset（插件）
• 某個進程資源消耗（插件）
• netstat、ss 等相關統計項采集
• 機器內核配置參數

只要安裝了falcon-agent的機器，就會自動開始采集各項指標，主動上報，不需要用戶在server做任何配置（這和zabbix有很大的不同），這樣做的好處，就是用戶維護方便，覆蓋率高。當然這樣做也會server端造成較大的壓力，不過open-falcon的服務端組件單機性能足夠高，同時都可以水平擴展，所以自動多采集足夠多的數據，反而是一件好事情，對於SRE和DEV來講，事后追查問題，不再是難題。

另外，falcon-agent提供了一個proxy-gateway，用戶可以方便的通過http接口，push數據到本機的gateway，gateway會幫忙高效率的轉發到server端。

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

 

四.數據模型

 

Data Model是否強大，是否靈活，對於監控系統用戶的“使用效率”至關重要。比如以zabbix為例，上報的數據為hostname（或者ip）、metric，那么用戶添加告警策略、管理告警策略的時候，就只能以這兩個維度進行。舉一個最常見的場景：

 

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

 

open-falcon，采用和opentsdb相同的數據格式：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 } 

 

通過這樣的數據結構，我們就可以從多個維度來配置告警，配置dashboard等等。 備注：endpoint是一個特殊的tag。

 

 

五.數據收集

 

　　transfer，接收客戶端發送的數據，做一些數據規整，檢查之后，轉發到多個后端系統去處理。在轉發到每個后端業務系統的時候，transfer會根據一致性hash算法，進行數據分片，來達到后端業務系統的水平擴展。

 

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

 

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

 

　　transfer的數據來源，一般有三種：

 

1. 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的插件腳本類監控），一般就不算基礎監控的范疇了。

 

 

　　更多資料請參考官網鏈接：http://book.open-falcon.org/zh/intro/.

　　博主推薦閱讀：http://book.open-falcon.org/zh_0_2/faq/