# Introduction

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

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

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

open-falcon的目標是做最開放、最好用的網際網路企業級監控產品。

# Highlights and features

• 強大靈活的資料採集 ：自動發現，支援falcon-agent、snmp、支援使用者主動push、使用者自定義外掛支援、opentsdb data model like（timestamp、endpoint、metric、key-value tags）
• 水平擴充套件能力
  ：支援每個週期上億次的資料採集、告警判定、歷史資料儲存和查詢
• 高效率的告警策略管理 ：高效的portal、支援策略模板、模板繼承和覆蓋、多種告警方式、支援callback呼叫
• 人性化的告警設定 ：最大告警次數、告警級別、告警恢復通知、告警暫停、不同時段不同閾值、支援維護週期
• 高效率的graph元件 ：單機支撐200萬metric的上報、歸檔、儲存（週期為1分鐘）
• 高效的歷史資料query元件 ：採用rrdtool的資料歸檔策略，秒級返回上百個metric一年的歷史資料
• dashboard ：多維度的資料展示，使用者自定義Screen
• 高可用 ：整個系統無核心單點，易運維，易部署，可水平擴充套件
• 開發語言 ： 整個系統的後端，全部golang編寫，portal和dashboard使用python編寫。

# Architecture

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

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

– 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

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

hostA的磁碟空間，小於5%，就告警。一般的伺服器上，都會有兩個主要的分割槽，根分割槽和home分割槽，在zabbix裡面，就得加兩條規則；如果是hadoop的機器，一般還會有十幾塊的資料盤，還得再加10多條規則，這樣就會痛苦，不幸福，不利於自動化。

open-falcon，採用和opentsdb相同的資料格式：metric加多組key value tags，舉兩個例子：

通過這樣的資料結構，我們就可以從多個維度來配置告警，配置dashboard等等。

備註：endpoint是一個特殊的tag。

# Data collection

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。

# Alerting

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

heartbeat sever不僅僅是單純的載入MySQL中的內容，根據模板繼承、模板項覆蓋、報警動作覆蓋、模板和hostGroup繫結，計算出最終關聯到每個endpoint的告警策略，提供給judge元件來使用。

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

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

# Query

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

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

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

# Dashboard

dashboard首頁，使用者可以以多個維度來搜尋endpoint列表，即可以根據上報的tags來搜尋關聯的endpoint。

使用者可以自定義多個metric，新增到某個screen中，這樣每天早上只需要開啟screen看一眼，服務的執行情況便盡在掌握了。

當然，也可以檢視清晰大圖，橫座標上zoom in/out，快速篩選反選。總之使用者的“使用效率”是第一要務。

# Web portal

一個高效的portal，對於提升使用者的“使用效率”，加成很大，平時大家都這麼忙，能給各位SRE、Devs減輕一些負擔，那是再好不過了。

這是host group的管理頁面，可以和服務樹結合，機器進出服務樹節點，相關的模板會自動關聯或者解除。這樣服務上下線，都不需要手動來變更監控，大大提高效率，降低遺漏和誤報警。

一個最簡單的模板的例子，模板支援繼承和策略覆蓋，模板和host group繫結後，host group下的機器會自動應用該模板的所有策略。

當然，也可以寫一個簡單的表示式，就能達到監控的目的，這對於那些endpoint不是機器名的場景非常方便。

新增一個表示式也是很簡單的。

# Storage

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

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

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

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

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

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

“`

// 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)

“`

對於原始資料，transfer會打一份到hbase，也可以直接使用opentsdb，transfer支援往opentsdb寫入資料。

# Committers

• laiwei: https://github.com/laiwei 來煒沒睡醒@微博 / [email protected]微信
• 秦曉輝: https://github.com/ulricqin [email protected]微博 [email protected]微信

# Contributors

• 近期我們會把絕大數的元件整理到 http://github.com/open-falcon ， 期待大家一起貢獻，推動，做最開放、最好用的企業級監控系統。

# TODO

• metric的聚合
• 環比、同比報警判定
• 流量的突升突降判定

# License

Copyright 2014-2015 Xiaomi, Inc.

Licensed under the Apache License,

Version 2.0:

http://www.apache.org/licenses/LICENSE-2.0