本文遵循「知識共享許可協(xié)議 CC-BY-NC-SA 4.0 International」律适，未經(jīng)作者(laiwei)書面許可管怠，不允許用于商業(yè)用途的轉(zhuǎn)載、分發(fā)亏掀、和演繹忱反。

在上一章中，我們介紹和對比了業(yè)界一些杰出的開源監(jiān)控解決方案滤愕。早期温算，我們一直在用Zabbix，不過隨著業(yè)務(wù)的快速發(fā)展间影，以及互聯(lián)網(wǎng)公司特有的一些需求注竿，現(xiàn)有的開源監(jiān)控系統(tǒng)在性能、擴展性和用戶的使用效率方面宇智，已經(jīng)無法支撐了蔓搞。

因此，從公司的一些需求出發(fā)随橘，從各位運維人員喂分、研發(fā)人員的使用經(jīng)驗和反饋出發(fā)，結(jié)合業(yè)界一些大型互聯(lián)網(wǎng)公司監(jiān)控系統(tǒng)的設(shè)計理念机蔗，研發(fā)了Open-Falcon蒲祈，目標(biāo)是做最開放、最好用的互聯(lián)網(wǎng)企業(yè)級監(jiān)控產(chǎn)品（Open-Falcon的詳細(xì)內(nèi)容萝嘁，可以參考http://open-falcon.org）梆掸。

監(jiān)控系統(tǒng)主要有4個功能：數(shù)據(jù)采集、告警牙言、圖表展示和歷史數(shù)據(jù)挖掘酸钦。Open-Falcon也是著重從這4個方面來設(shè)計和開發(fā)的。Open-Falcon具有以下一些特點咱枉。

• 強大靈活的數(shù)據(jù)采集：通過配套的Falcon-agent卑硫，可以自動采集400多個單機指標(biāo)徒恋，也可以通過用戶自定義的插件來增加更多的采集項。用戶可以自己實現(xiàn)采集程序獲取相關(guān)的指標(biāo)欢伏，然后主動推送給監(jiān)控系統(tǒng)入挣，由監(jiān)控系統(tǒng)負(fù)責(zé)后續(xù)的存儲、展示和告警功能硝拧。比如編寫腳本通過SNMP方式獲取網(wǎng)絡(luò)設(shè)備的相關(guān)運行指標(biāo)，并把采集結(jié)果推送給監(jiān)控系統(tǒng)滋恬。
• 良好的水平擴展能力：監(jiān)控系統(tǒng)能通過水平擴展來支撐業(yè)務(wù)的快速發(fā)展。
• 高效率的告警策略管理：高效的用戶配置界面夷恍，支持策略模板媳维，支持模板繼承和覆蓋，支持多種告警方式和回調(diào)動作侄刽。
• 人性化的告警設(shè)置：支持最大告警次數(shù)、告警級別設(shè)置州丹、告警恢復(fù)通知醋安、告警暫停、不同時段不同閾值墓毒，支持維護(hù)周期設(shè)置吓揪，支持告警合并。
• 高效的歷史數(shù)據(jù)查詢：采用RRDtool的數(shù)據(jù)歸檔策略所计，秒級返回上百個指標(biāo)一年的歷史數(shù)據(jù)柠辞。
• 人性化的Dashboard：多維度的數(shù)據(jù)展示，用戶自定義Dashboard等功能主胧。
• 高可用：整個系統(tǒng)無核心單點叭首，易運維，易部署踪栋。

Open-Falcon架構(gòu)

Open-Falcon架構(gòu)示意圖如圖1所示焙格。

圖1 Open-Falcon架構(gòu)示意圖

整個監(jiān)控系統(tǒng)，由Agent夷都、Web-portal眷唉、Heartbeat-server、Dashboard、Transfer冬阳、Judge荣瑟、Graph 等幾個核心組件構(gòu)成。

Agent

做運維摩泪，不怕出問題，怕的是出了問題劫谅，抓不到現(xiàn)場兩眼抹黑见坑。所以荞驴，依靠強大的監(jiān)控系統(tǒng)贯城，收集盡可能多的指標(biāo)能犯，意義重大踩晶。但哪些指標(biāo)才是有意義的呢渡蜻？本著從實踐中來的思想茸苇，各位工程師在長期摸爬滾打中總結(jié)出來的經(jīng)驗最有價值学密。在運維工程師的長期工作實踐中腻暮，我們總結(jié)了在系統(tǒng)運維過程中經(jīng)常會參考的一些指標(biāo)，主要包括以下幾個類別遗增。

• CPU
• Load
• 內(nèi)存
• 磁盤
• IO
• 網(wǎng)絡(luò)相關(guān)
• 內(nèi)核參數(shù)
• netstat/ss命令統(tǒng)計輸出
• 端口采集
• 核心服務(wù)的進(jìn)程存活信息采集
• 關(guān)鍵業(yè)務(wù)進(jìn)程資源消耗
• NTP Offset采集
• DNS解析采集

Agent是一個Daemon程序做修，只要安裝了Falcon-agent的Linux服務(wù)器蔗坯，便會自發(fā)現(xiàn)地采集單機的各種數(shù)據(jù)指標(biāo)宾濒，共計400多個屏箍，基本覆蓋了上面提到的各個類別赴魁。
這些采集好的指標(biāo)颖御，Agent會以一個固定的周期主動上報到服務(wù)端潘拱，并不需要用戶在服務(wù)端做任何配置（這和Zabbix有很大的不同）芦岂。這樣做的好處就是用戶維護(hù)起來方便盔腔，指標(biāo)覆蓋率高弛随，在服務(wù)器上架初始化的時候舀透，就會自動安裝Agent。有了這些詳細(xì)的指標(biāo)走贪，對于運維人員和研發(fā)人員來講坠狡，事后追查問題不再是難題逃沿。當(dāng)然凯亮，這樣做也會給服務(wù)端帶來一些壓力。

另外柠并，Agent提供了一個Proxy-gateway功能臼予，用戶可以方便地通過HTTP的方式，POST自定義的數(shù)據(jù)到本機的Proxy-gateway谅阿，Proxy-gateway會將這些數(shù)據(jù)轉(zhuǎn)發(fā)到服務(wù)端签餐，便于用戶推送數(shù)據(jù)氯檐，并提高整個監(jiān)控系統(tǒng)的穩(wěn)定性冠摄。

Agent支持的這些采集項几缭，都是大量運維人員在長期的工作中總結(jié)出來的年栓，基本能覆蓋常見的一些監(jiān)控需求某抓。但仍然會存在一些特殊的業(yè)務(wù)需求否副，或者不適合在Agent里面內(nèi)置的采集項备禀，對于這些需求，如何更好地進(jìn)行支持呢呻待？我們設(shè)計開發(fā)了插件機制蚕捉。

插件是符合一定規(guī)范的迫淹，由用戶開發(fā)的數(shù)據(jù)采集腳本或者可執(zhí)行程序敛熬，Agent會負(fù)責(zé)周期性地調(diào)度這些插件应民，并將插件運行的輸出推送到監(jiān)控系統(tǒng)诲锹。
插件的工作流程如圖2所示归园。

圖2 插件的工作流程圖

插件是作為一個Git項目（Falcon-plugin）庸诱，通過Git來管理的桥爽。用戶編寫插件聚谁，完成測試之后形导，提交到Falcon-plugin的dev分支朵耕，并發(fā)起一個pull-request阎曹，管理員審核確認(rèn)通過后，會合并到master分支栅贴。所有的Agent都會定期通過git pull來檢查獲取更新檐薯，這樣用戶提交的插件就更新到所有的服務(wù)器了坛缕。通過Git管理插件赚楚，好處就是版本管理和協(xié)作宠页，所有的用戶都可以自由貢獻(xiàn)插件，通過pull-request合并到master分支罩句。

插件更新到服務(wù)器之后，Agent并不會對其進(jìn)行調(diào)度乳愉，因為某些插件只是解決特定的問題蔓姚，并不適合在所有的服務(wù)器上運行坡脐，或者無法正常運行在所有的服務(wù)器上备闲。從安全的角度和產(chǎn)品設(shè)計的角度考慮恬砂，用戶需要在Web-portal上進(jìn)行配置泻骤，哪些機器允許執(zhí)行哪些插件。完成這步操作后演痒，相關(guān)的插件才會被相關(guān)服務(wù)器的Agent自動調(diào)度嫡霞。

數(shù)據(jù)模型

在講述其他組件之前诊沪，有必要先描述一下Open-Falcon的數(shù)據(jù)模型（Data Model）端姚。

數(shù)據(jù)模型是否強大渐裸、是否靈活昏鹃，對于監(jiān)控系統(tǒng)用戶的“使用效率”至關(guān)重要洞渤。比如以Zabbix為例载迄，上報的數(shù)據(jù)格式為hostname（或者IP地址）护昧、metric惋耙、timestamp绽榛、value這4個維度，那么用戶添加告警策略稿械、管理告警策略的時候美莫，就只能以這幾個維度來進(jìn)行厢呵。

舉一個最常見的場景：hostA的磁盤空間襟铭，小于5%，就告警赐劣。在一般的服務(wù)器上魁兼，都會有兩個主要的分區(qū)咐汞，即root分區(qū)和home分區(qū)化撕，在Zabbix中植阴，就得加兩條規(guī)則墙贱；如果是Hadoop服務(wù)所在的機器，一般還會有十幾塊數(shù)據(jù)盤伊脓，還得再加十多條規(guī)則报腔，這樣就會很煩瑣纯蛾，不利于自動化（當(dāng)然翻诉，Zabbix可以通過配置一些自動發(fā)現(xiàn)策略來搞定，不過仍然比較麻煩且不直觀）绅作。

Open-Falcon采用類似于OpenTSDB的數(shù)據(jù)模型俄认，由以下7個字段構(gòu)成眯杏。

• metric：最核心的字段役拴，代表這個數(shù)據(jù)采集項具體度量的是什么東西河闰，比如是內(nèi)存的使用量（memory_used）姜性，還是某個接口調(diào)用的次數(shù)（QPS）部念。
• endpoint：代表metric的主體儡炼，比如metric是內(nèi)存使用量（memory_uesd）乌询，那么endpoint就表示該metric屬于哪臺機器妹田。
• tags：這是一組用逗號分隔的鍵值對鬼佣，用來對metric進(jìn)行進(jìn)一步的描述晶衷，比如service=falcon,location=beijing。
• timestamp：UNIX時間戳驻龟，表示產(chǎn)生該數(shù)據(jù)的時間點翁狐。
• value：整型或者浮點型露懒，代表該metric在指定時間點的值懈词。
• step：整型坎弯，表示該數(shù)據(jù)采集項的匯報周期抠忘，這對于后續(xù)的配置監(jiān)控策略很重要崎脉，必須明確指定囚灼。
• counterType：只能是COUNTER或者GAUGE二選一灶体，前者表示該采集項為計數(shù)器類型蝎抽，后者表示其為原值织中。對于計數(shù)器類型，在告警判定以及圖表展示前殖妇，會被先計算為速率谦趣。

舉兩個例子：

{ 
metric: df.bytes.free.percent, 
endpoint: hostA,
tags: mount=/home,
value: 5, 
timestamp: UNIX時間戳,
counterType: GAUGE, 
step: 60
}
{
metric: df.bytes.free.percent, 
endpoint: hostA, 
tags: mount=/root, 
value: 15, 
timestamp: UNIX時間戳,
counterType: GAUGE, 
step: 60 
}```

metric為df.bytes.free.percent，表示這個指標(biāo)的具體含義為服務(wù)器的磁盤可用百分比摘悴；endpoint描述這個metric所在的主體是hostA蹂喻；tags是對這個metric的一組補充描述口四，比如mount=/home這一組tag蔓彩，表示這個metric描述的是home分區(qū)的磁盤可用百分比赤嚼；同樣mount=/root探膊，表示這個metric描述的是root分區(qū)的磁盤可用百分比逞壁。

使用tags的好處是可以簡化告警策略的配置腌闯。比如上面提到的這個最簡單的場景姿骏，hostA的磁盤可用百分比小于5%就觸發(fā)告警分瘦。對于root和home兩個分區(qū)丑罪，在Open-Falcon中茉稠，可以用一條規(guī)則來描述寞秃，即 ：
>endpoint=hostA && metric=df.bytes.free.percent < 5%

而不再需要針對兩個分區(qū)土陪，寫兩條規(guī)則：

>endpoint=hostA && metric=df.bytes.free.percent && mount=/home < 5%
endpoint=hostA && metric=df.bytes.free.percent && mount=/root < 5%

另外鬼雀，在Dashboard中源哩，可以借助于tags，把tags作為篩選過濾條件坯辩，更方便用戶查看自己關(guān)心的指標(biāo)漆魔。

#  數(shù)據(jù)采集
數(shù)據(jù)采集改抡，是監(jiān)控系統(tǒng)一個最基本的功能阿纤。在Open-Falcon中欠拾，Agent采集到的數(shù)據(jù)藐窄，會先發(fā)送給Transfer組件荆忍。Transfer接收到客戶端發(fā)送的數(shù)據(jù)刹枉，做一些數(shù)據(jù)規(guī)整微宝、檢查之后轉(zhuǎn)發(fā)到多個后端系統(tǒng)去處理芥吟。在轉(zhuǎn)發(fā)到每個后端業(yè)務(wù)系統(tǒng)的時候钟鸵，Transfer會根據(jù)一致性哈希算法進(jìn)行數(shù)據(jù)分片棺耍，來達(dá)到后端業(yè)務(wù)系統(tǒng)的水平擴展蒙袍。Transfer自身是無狀態(tài)的害幅，掛掉一臺或者多臺不會有任何影響岂昭。

Transfer目前支持的業(yè)務(wù)后端有三種：Judge约啊、Graph和OpenTSDB恰矩。Judge是我們開發(fā)的高性能告警判定組件纪吮，Graph是我們開發(fā)的高性能數(shù)據(jù)存儲萎胰、歸檔巷疼、查詢組件灵奖，OpenTSDB是開源的時間序列數(shù)據(jù)存儲服務(wù)骡尽。每個業(yè)務(wù)后端都可以通過Transfer的配置文件來開啟攀细。

Transfer的數(shù)據(jù)來源一般有4種。
1. Falcon-agent主動采集的基礎(chǔ)監(jiān)控數(shù)據(jù)境钟。
2. Falcon-agent執(zhí)行用戶自定義的插件返回的數(shù)據(jù)。
3. client-library：線上的業(yè)務(wù)系統(tǒng)缚态，都嵌入使用了統(tǒng)一的基礎(chǔ)庫玫芦，對于業(yè)務(wù)系統(tǒng)中的每個業(yè)務(wù)接口桥帆，都會主動計算其CPS环葵、Lantency等指標(biāo)并上報张遭。
4. 用戶產(chǎn)生的一些自定義的指標(biāo)菊卷，由用戶自行上報洁闰。

這4種數(shù)據(jù)都會先發(fā)送給本機的Proxy-gateway扑眉，再由Proxy-gateway轉(zhuǎn)發(fā)給Transfer腰素。

一個推送數(shù)據(jù)給Proxy-gateway的例子如下：
```python
#!-*- coding:utf8 -*-
 
import requests
import time
import json

ts = int(time.time())
payload = [
    {
        ＂endpoint＂: ＂test-endpoint＂,
        ＂metric＂: ＂test-metric＂,
        ＂timestamp＂: ts,
        ＂step＂: 60,
        ＂value＂: 1,
        ＂counterType＂: ＂GAUGE＂,
        ＂tags＂: ＂location=beijing,service=falcon＂,
    },
]
r=requests.post(＂http://127.0.0.1:1988/v1/push＂,data=json.dumps(payload))

業(yè)務(wù)性能數(shù)據(jù)采集基礎(chǔ)庫設(shè)計思路

除了一些基礎(chǔ)采集項弓千，線上業(yè)務(wù)各接口的各項性能數(shù)據(jù)也是研發(fā)人員和運維人員重點關(guān)注的內(nèi)容镣陕。我們抽象總結(jié)出了兩類最通用的指標(biāo)呆抑，供大家參考理肺。

• 每秒調(diào)用次數(shù)：CPS摄闸。
• 接口調(diào)用延時：Lantency-75th善镰、Lantency-95th、Lantency-99th年枕。

即針對線上業(yè)務(wù)的每個接口炫欺，都會由基礎(chǔ)庫自動計算這兩類指標(biāo)，并由基礎(chǔ)庫周期性地推送給本地的Proxy-gateway熏兄。這樣不用業(yè)務(wù)研發(fā)人員投入過多的精力品洛，就可以自動化摩桶、標(biāo)準(zhǔn)化地采集業(yè)務(wù)性能指標(biāo)數(shù)據(jù)。

有了相關(guān)的性能數(shù)據(jù)后士飒，一方面，我們可以針對某些核心接口調(diào)用配置監(jiān)控策略，在接口調(diào)用耗時增大到一定程度的時候，或者接口調(diào)用次數(shù)發(fā)生突升突降的時候，發(fā)送告警及時通知相關(guān)人員酷师；另一方面，借助于性能數(shù)據(jù)褐望，相關(guān)的研發(fā)人員和運維人員能夠更從容地規(guī)劃整個系統(tǒng)的容量谨读，提高系統(tǒng)的穩(wěn)定性以及資源利用率。

注：線上業(yè)務(wù)性能數(shù)據(jù)采集，一個開源的實現(xiàn)可以參考 http://metrics.dropwizard.io矛缨。

HTTP服務(wù)數(shù)據(jù)采集思路

目前HTTP服務(wù)仍然在我們的所有業(yè)務(wù)中占據(jù)重要地位盟广，所以如何自動化地監(jiān)控碉熄、評估Web服務(wù)的可用性指標(biāo)和性能數(shù)據(jù)是非常重要的。我們的線上業(yè)務(wù)大量使用Nginx作為Web Server性誉。

在第一階段，通過分析Nginx的訪問日志得到訪問次數(shù)轧邪，通過分析日志中的status code得到正常返回和服務(wù)器出錯的數(shù)量菜循。這個方案可以解決一部分問題昧穿，不過存在一些不足的地方厅瞎，比如：

• 在線上服務(wù)器上分析日志，會對服務(wù)器造成一定的壓力，拖慢正常業(yè)務(wù)的響應(yīng)時間。
• 分析的時效性較差，一般都是5分鐘的粒度和延遲重挑。
• 日志的覆蓋率有限严肪，有些性能數(shù)據(jù)很難在日志中體現(xiàn)，比如upstream到某個后端花費的時間等。

在第二階段袍患，我們嘗試在Nginx中內(nèi)嵌Lua腳本來自動計算和獲取每個Nginx Location對應(yīng)的相關(guān)性能指標(biāo)肆良，包括：

• qps棺牧，該Location每秒被訪問的次數(shù)疲牵。
• request_time负蚊，請求的平均響應(yīng)時間。
• upstream_time_to_xxx哨坪，upstream到某個后端的平均響應(yīng)時間忿偷，用來衡量Nginx到每個后端應(yīng)用服務(wù)器花費的時間。
• bytes_sent，每秒返回的字節(jié)數(shù)罪裹，用來衡量網(wǎng)絡(luò)帶寬的利用率冯袍。
• status_code.200择膝，每秒鐘每庆，HTTP的狀態(tài)碼等于200的次數(shù)腮出。
• status_code.4xx，每秒鐘垒迂，HTTP的狀態(tài)碼大于等于400欢揖、小于500的次數(shù)。
• status_code.5xx谢鹊，HTTP的狀態(tài)碼大于等于500的次數(shù)压昼。
• availability : 1-(status_code.4xx + status_code.5xx) / qps郁季，用來衡量服務(wù)的可用性。

采用該方案后派近，HTTP服務(wù)的各項指標(biāo)的覆蓋率得到大大提高戒幔，數(shù)據(jù)分析的時效性也提高到1分鐘粒度罢吃，同時相對于第一階段日志分析的方案，該方案的運維成本得到大大降低篮奄，對服務(wù)器資源的消耗也降低到可以忽略不計的水平菩帝。

告警

告警判定悴品，是由Judge組件來完成的依鸥。用戶在Web-portal上配置相關(guān)的報警策略，存儲在MySQL中忧换。Heartbeat-server 會定期加載MySQL中的內(nèi)容梢夯。Judge也會定期和Heartbeat-server保持溝通，來獲取相關(guān)的報警策略姑尺。

Heartbeat-server不僅僅是單純地加載MySQL中的內(nèi)容什黑。另一個重要功能是根據(jù)用戶配置的模板繼承關(guān)系橘蜜、模板項覆蓋關(guān)系力麸、報警動作覆蓋關(guān)系、模板和機器組的綁定關(guān)系缭召，計算出最終關(guān)聯(lián)到每個endpoint的告警策略，下發(fā)給Judge組件來進(jìn)行告警判定垛耳。

Transfer轉(zhuǎn)發(fā)到Judge的每條數(shù)據(jù)，都會觸發(fā)相關(guān)策略的判定，來決定是否滿足報警條件，如果條件滿足蚌讼，則會將告警信息寫入告警隊列。Alarm會從告警隊列中獲取數(shù)據(jù)，再以郵件、短信蜈缤、米聊等形式通知相關(guān)用戶拾氓，也可以執(zhí)行用戶預(yù)先配置好的回調(diào)動作。

用戶可以很靈活地來配置告警判定策略劫樟，比如連續(xù)N次都滿足條件痪枫，連續(xù)N次的最大值滿足條件，不同的時間段設(shè)置不同的閾值叠艳，如果處于維護(hù)周期內(nèi)則忽略告警等奶陈。同時也支持最大告警次數(shù)設(shè)置、告警級別設(shè)置附较，支持告警恢復(fù)通知吃粒、一段時間內(nèi)突升突降判定等功能。

與告警組件相關(guān)的幾個重要概念如下拒课。

• 告警策略：某個metric觸發(fā)告警需要滿足的條件徐勃，稱之為一個告警策略事示。比如cpu.idle，連續(xù)3次的值都小于10%僻肖，則觸發(fā)告警肖爵。這就是一個典型的告警策略。
• 模板：一組告警策略的集合臀脏，稱之為模板劝堪。模板和某個服務(wù)器分組綁定之后，該服務(wù)器分組下面的所有endpoint都會自動應(yīng)用該模板中所有的策略揉稚。
• 服務(wù)器分組：一組endpoint的集合秒啦，稱之為一個服務(wù)器分組。一個endpoint加入某個服務(wù)器分組中搀玖，那么就會自動應(yīng)用該分組所綁定的策略模板余境；同理，一個endpoint從某個服務(wù)器分組中去掉灌诅，這個endpoint便不再擁有該分組所綁定的策略模板芳来。通過這種管理方式，使得服務(wù)擴容和縮減時監(jiān)控可以自動化地變更延塑。服務(wù)器分組是綁定策略模板的唯一單位绣张。
• 告警動作：滿足告警策略需要后續(xù)執(zhí)行的動作，稱之為告警動作关带。目前支持的告警動作包括發(fā)送短信侥涵、發(fā)送郵件、發(fā)送米聊宋雏、執(zhí)行指定的回調(diào)動作芜飘。回調(diào)動作這種機制磨总，便于用戶執(zhí)行一些自動化的預(yù)案嗦明。

為了提高運維人員和研發(fā)人員配置、維護(hù)監(jiān)控策略的效率蚪燕，Open-Falcon有兩個很重要的功能：一是根據(jù)tag來設(shè)置告警策略娶牌；二是引入模板來組織告警策略。

根據(jù)tag來設(shè)置告警策略馆纳，我們在前面講述Open-Falcon數(shù)據(jù)模型的時候诗良，有過簡單介紹。這里再舉幾個場景來說明一下鲁驶。

場景一：部署了Falcon這個服務(wù)的所有服務(wù)器鉴裹，SDA盤的磁盤IO使用率，超過80%就告警。

service=falcon && metric=disk.io.util && device=sda > 80%

場景二：部署了Falcon這個服務(wù)的所有服務(wù)器径荔，任何一塊磁盤IO使用率督禽，超過80%就告警。

service=falcon && metric=disk.io.util > 80%

在上面兩個場景中总处，我們用到了service和device這兩個tag來作為配置告警的條件狈惫，僅僅通過一條配置，就能滿足用戶的需求辨泳。

模板是用戶管理一組策略的唯一單元虱岂，一個模板可以和多個機器分組進(jìn)行綁定。模板的作用在于用戶修改了模板中的某個策略之后菠红，與該模板綁定的所有機器分組中的endpoint都會即時生效該策略變動。

模板之間可以存在繼承關(guān)系难菌，子模板會自動擁有父模板中的所有策略试溯。另外，在子模板中郊酒，可以覆蓋父模板中的某些策略遇绞。比如我們可以創(chuàng)建一些標(biāo)準(zhǔn)的模板，其他用戶只需要繼承該模板燎窘，做一些簡單的增摹闽、刪、改就可以使用了褐健。模板的繼承和覆蓋特性付鹿，可以有效地幫助運維人員減少維護(hù)告警策略的工作量。

對于模板的繼承和覆蓋特性蚜迅，我們可以通過以下兩個場景來闡述舵匾。

在圖3所描述的場景一中，我們需要監(jiān)控FalconHostGroup這個服務(wù)器分組下的所有服務(wù)器谁不，其cpu.idle都不能低于10%坐梯；否則發(fā)送告警給falcon-dev用戶組。我們通過給FalconHostGroup分組綁定Template-A策略模板刹帕，即可達(dá)到目的吵血。

圖3 場景一——模板繼承和覆蓋

這時候，用戶的需求場景發(fā)生了變化偷溺，即如圖4所示的新場景中所描述的蹋辅，用戶希望在場景一的基礎(chǔ)上，監(jiān)控portal這個服務(wù)器分組下的所有服務(wù)器亡蓉，其cpu_idle不能低于50%晕翠；否則發(fā)送告警給portal-dev用戶組。為了解決用戶的新需求，通常的做法是淋肾，去除FalconHostGroup和Template-A的綁定關(guān)系硫麻，然后給下面的5個子分組分別綁定不同的策略模板。這樣的操作方式樊卓，對用戶來講是非常煩瑣的拿愧，特別是在子分組很多的情況下。

在Open-Falcon中碌尔，我們可以利用模板的繼承和覆蓋特性浇辜，方便地滿足這個新需求。我們保持FalconHostGroup分組和Template-A的綁定關(guān)系不變唾戚，只需要給portal這個有特殊需求的分組單獨綁定一個策略模板Template-B即可柳洋，其中Template-B繼承自Template-A，且對Template-A中的cpu.idle策略項進(jìn)行了覆蓋叹坦。這樣就可以滿足用戶的新需求了熊镣。

圖4 新場景——模板繼承和覆蓋

告警分級

同樣是告警，有的告警需要立即處理募书；否則就會造成很大的影響绪囱，比如嚴(yán)重影響用戶體驗，無法正常使用該業(yè)務(wù)的核心功能等莹捡；有的告警則時效性要求較低鬼吵，比如多臺Nginx中的一臺宕機了，暫時不影響服務(wù)篮赢，稍后處理即可齿椅。告警分級，讓運維人員做到對重點故障重點關(guān)注荷逞。

考慮到這樣的場景媒咳，監(jiān)控系統(tǒng)在設(shè)計的時候，允許用戶設(shè)置告警級別种远，對于高級別的告警涩澡，會優(yōu)先在第一時間通過多種通道下發(fā)給相關(guān)用戶；對于低級別的告警坠敷，則只會通過郵件進(jìn)行發(fā)送妙同。

告警級別，是按照對服務(wù)膝迎、對用戶的影響范圍來確定的粥帚。下面是相關(guān)定義，如表24-1所示限次。

表24-1 告警級別定義

告警合并

不知道各位讀者在運維過程中缘缚，有沒有遇到過一些告警短信轟炸的場景勾笆，比如機房之間專線故障導(dǎo)致連通性下降，或者內(nèi)網(wǎng)DNS出現(xiàn)問題導(dǎo)致各種解析失敗桥滨，短時間內(nèi)產(chǎn)生大批量的告警匠襟。這些瞬時的大批量告警給運維和研發(fā)人員造成了很大的干擾，造成短信網(wǎng)關(guān)该园、郵件網(wǎng)關(guān)資源的浪費，同時也會淹沒一些重要的告警帅韧。因此里初，我們嘗試通過告警合并來解決這種告警轟炸問題。

在告警未合并之前忽舟，只要產(chǎn)生了告警双妨，就會立即發(fā)送。如果要做合并叮阅，那么就必然需要有一個等待時間刁品，比如產(chǎn)生告警后等1分鐘，然后看看這1分鐘里哪些告警可以合并為一條浩姥，最后再統(tǒng)一發(fā)送給目標(biāo)用戶挑随。告警合并需要有一定的規(guī)則，按照metric合并是一個很自然的方案勒叠，即很多endpoint的同一個metric告警兜挨，可以很自然地合并為一條，在減少告警數(shù)量的同時眯分，盡可能少地丟失信息量拌汇。用戶收到合并后的消息后，如果想進(jìn)一步查看詳情弊决，可以點擊附加在告警消息中的詳情鏈接進(jìn)入噪舀。

目前我們僅按照相同metric這一個維度來進(jìn)行合并。更進(jìn)一步，可以結(jié)合更多的緯度信息与倡，比如相同機柜界逛、同一接入交換機、同一類服務(wù)等蒸走，做到更智能仇奶、更準(zhǔn)確的信息合并和問題定位。

實施告警合并比驻，會對告警時效性存在影響该溯，這和高級別的告警要求立即發(fā)送的原則存在矛盾，因此最終的方案是只對低級別的告警實施合并别惦。

數(shù)據(jù)存儲方案

對于監(jiān)控系統(tǒng)來講狈茉，歷史數(shù)據(jù)的存儲、高效率查詢和快速展示是很重要且困難的問題掸掸。這主要表現(xiàn)在如下三個方面氯庆。

1. 數(shù)據(jù)量大：目前我們的監(jiān)控系統(tǒng)每個周期大概有2500萬次數(shù)據(jù)采集項上報（上報周期為1分鐘和5分鐘兩種，各占50%）扰付，一天24小時里堤撵，從來不會有低峰，不管是白天還是黑夜羽莺，每個周期總會有那么多的數(shù)據(jù)要更新实昨。
2. 寫操作多：一般的業(yè)務(wù)系統(tǒng)通常都是讀多寫少，可以方便地使用各種緩存技術(shù)盐固。再者荒给，各類數(shù)據(jù)庫對于查詢操作的處理效率遠(yuǎn)遠(yuǎn)高于寫操作。而監(jiān)控系統(tǒng)恰恰相反刁卜，寫操作遠(yuǎn)遠(yuǎn)高于讀志电。每個周期幾千萬次的更新操作，對于常用數(shù)據(jù)庫（MySQL蛔趴、PostgreSQL挑辆、MongoDB）都不是最合適和擅長的。
3. 高效率查詢：我們說監(jiān)控系統(tǒng)讀操作少夺脾，是相對寫入來講的之拨。監(jiān)控系統(tǒng)本身對于讀的要求很高，用戶經(jīng)常會查詢上百個metric咧叭，在過去一天蚀乔、一周、一月菲茬、一年的數(shù)據(jù)吉挣。如何在秒級返回給用戶并在前端展現(xiàn)派撕，這是一個不小的挑戰(zhàn)。

Open-Falcon在這塊投入了較大的精力睬魂。我們把數(shù)據(jù)按照用途分成兩類终吼，一類是用于圖表展示的；一類是用戶做數(shù)據(jù)挖掘的氯哮。

對于圖表展示的數(shù)據(jù)來講际跪，查詢要快是關(guān)鍵，同時盡可能不丟失信息量喉钢。對于用戶要查詢100個metric在過去一年里的數(shù)據(jù)姆打，數(shù)據(jù)量是巨大的，很難能在1秒之內(nèi)返回肠虽。另外幔戏，就算返回了，前端也無法渲染這么多的數(shù)據(jù)税课，還得再采樣闲延，這就造成很多無謂的消耗。

我們參考RRDtool的理念韩玩，在數(shù)據(jù)每次存入的時候會自動進(jìn)行采樣垒玲、歸檔。歸檔策略是找颓，歷史數(shù)據(jù)保存5年侍匙。同時為了不丟失信息量，數(shù)據(jù)歸檔的時候叮雳，會按照平均值采樣、最大值采樣妇汗、最小值采樣存三份帘不。用戶在查詢某個metric在過去一年的歷史數(shù)據(jù)時，Graph會選擇最合適的采樣頻率杨箭，返回采樣后的數(shù)據(jù)寞焙，提高了數(shù)據(jù)查詢速度。

以1分鐘的上報周期為例互婿，下面是我們采用的數(shù)據(jù)歸檔采樣策略（RRA的概念請參考RRDtool的文檔）捣郊。

// 1分鐘一個點存12小時
RRA(＂AVERAGE＂, 0.5, 1, 720)

// 5分鐘一個點存2天
RRA(＂AVERAGE＂, 0.5, 5, 576)
RRA(＂MAX＂, 0.5, 5, 576)
RRA(＂MIN＂, 0.5, 5, 576)

// 20分鐘一個點存7天
RRA(＂AVERAGE＂, 0.5, 20, 504)
RRA(＂MAX＂, 0.5, 20, 504)
RRA(＂MIN＂, 0.5, 20, 504)

// 3小時一個點存3個月
RRA(＂AVERAGE＂, 0.5, 180, 766)
RRA(＂MAX＂, 0.5, 180, 766)
RRA(＂MIN＂, 0.5, 180, 766)

// 1天一個點存1年
RRA(＂AVERAGE＂, 0.5, 720, 730)
RRA(＂MAX＂, 0.5, 720, 730)
RRA(＂MIN＂, 0.5, 720, 730)

為了更進(jìn)一步地提高寫入性能，Graph充分使用內(nèi)存慈参，將待更新的數(shù)據(jù)緩存一定的時間（30分鐘）后呛牲，再刷新到磁盤中，這樣對磁盤IO的壓力減少了一個數(shù)量級驮配。同時為了避免刷新磁盤產(chǎn)生壓力峰值娘扩，我們把刷新磁盤的操作打散到了每一秒鐘着茸。當(dāng)然，使用緩存技術(shù)后琐旁，會產(chǎn)生兩個副作用涮阔，一是當(dāng)程序異常崩潰或者服務(wù)器斷電的時候，會導(dǎo)致內(nèi)存中尚未刷新到磁盤的數(shù)據(jù)丟失灰殴；二是用戶查詢數(shù)據(jù)的時候敬特，就需要把內(nèi)存中的數(shù)據(jù)和磁盤上的數(shù)據(jù)做合并，在一定程度上增加了代碼的復(fù)雜度牺陶。

前面在講述Transfer的時候伟阔，我們提到Transfer根據(jù)一致性哈希算法，將數(shù)據(jù)打散分發(fā)到后端不同的Graph實例上來達(dá)到水平擴展的能力义图。那么這里就存在一個問題减俏，如果后端的Graph需要擴容實例數(shù)目的時候，一致性哈希算法得到的結(jié)果就會跟著發(fā)生變化碱工，導(dǎo)致一部分歷史數(shù)據(jù)丟失娃承。為了解決這個問題，我們正在給Transfer增加一個migrating功能怕篷，當(dāng)后端Graph需要擴容實例數(shù)目的時候历筝，Transfer會根據(jù)擴容前后的實例信息，對每個數(shù)據(jù)采集項進(jìn)行兩次一致性哈希計算廊谓，根據(jù)計算結(jié)果來決定是否要進(jìn)行數(shù)據(jù)遷移梳猪。

對于原始數(shù)據(jù)，Transfer會推送一份到HBase蒸痹，也可以直接使用OpenTSDB春弥，Transfer支持往OpenTSDB中寫入數(shù)據(jù)。

數(shù)據(jù)查詢

到這里叠荠，數(shù)據(jù)已經(jīng)成功地存儲在Graph里了匿沛。如何快速地讀出來呢？讀過去1小時的榛鼎、過去1天的逃呼、過去一月的、過去一年的者娱，都需要在秒級時間內(nèi)返回抡笼。

這些都是靠Graph和Query組件來實現(xiàn)的，Transfer會將數(shù)據(jù)往Graph組件中轉(zhuǎn)發(fā)一份黄鳍，Graph收到數(shù)據(jù)以后推姻，會以RRDtool的數(shù)據(jù)歸檔方式存儲，同時提供查詢RPC接口框沟。

Query面向終端用戶拾碌，收到查詢請求后吐葱，根據(jù)一致性哈希算法，會去相應(yīng)的Graph里面查詢不同metric的數(shù)據(jù)校翔，匯總后統(tǒng)一返回給用戶弟跑。

Dashboard

在Dashboard首頁，用戶可以根據(jù)關(guān)鍵字來搜索endpoint防症，也可以根據(jù)上報的tags來搜索相關(guān)聯(lián)的endpoint孟辑，如圖5所示。

圖5 搜索

用戶可以自定義多個metric蔫敲，添加到某個screen中饲嗽，這樣每天早上只需要打開screen看一眼，服務(wù)的運行情況便盡在掌握中了奈嘿，如圖6所示貌虾。

圖6 掌握服務(wù)的運行情況

當(dāng)然，也可以查看清晰大圖裙犹，在橫坐標(biāo)上放大或縮小區(qū)間范圍尽狠，快速篩選或反選監(jiān)控項目，如圖7所示叶圃“栏啵總之，用戶的“使用效率”是第一要務(wù)掺冠。

圖7 查看清晰大圖

Web-portal

一個高效的用戶配置交互界面沉馆，對于提升用戶的“使用效率”有很大的作用。

如圖8所示是服務(wù)器分組管理頁面德崭，某個endpoint加入到某個服務(wù)器分組中斥黑，就會自動擁有該分組所綁定的所有策略列表。此處可以和服務(wù)樹結(jié)合眉厨，服務(wù)器進(jìn)出服務(wù)樹節(jié)點心赶，相關(guān)的模板會自動關(guān)聯(lián)或者解除。這樣服務(wù)上缺猛、下線都不需要手動來變更監(jiān)控，大大提高了效率椭符，降低了遺漏和誤報警荔燎。

圖8 服務(wù)器分組管理頁面

如圖9所示是一個最簡單的模板的例子。模板支持繼承和策略覆蓋销钝，模板和服務(wù)器分組綁定后有咨，該服務(wù)器分組下的endpoint會自動應(yīng)用該模板的所有策略。
告警接收人這些配置信息蒸健，是作為模板的一個屬性存在的座享。給定一個模板綁定了服務(wù)器分組之后婉商，當(dāng)該模板中的任何一個策略滿足告警條件時，就會發(fā)送告警給模板的告警接收人渣叛。

圖9 模板示例

總結(jié)

監(jiān)控系統(tǒng)是運維基礎(chǔ)設(shè)施中最重要的組成部分丈秩。本章，我們分享了從監(jiān)控系統(tǒng)的選型淳衙、對比蘑秽、優(yōu)化到自研的整個過程。Open-Falcon項目可以在我們的github主頁https://github.com/open-falcon上找到箫攀，期待各位讀者一起交流和改進(jìn)肠牲。

本文遵循「知識共享許可協(xié)議 CC-BY-NC-SA 4.0 International」，未經(jīng)作者(laiwei)書面許可靴跛，不允許用于商業(yè)用途的轉(zhuǎn)載叮喳、分發(fā)、和演繹讲衫。