本文遵循「知識共享許可協議 CC-BY-NC-SA 4.0 International」，未經作者(laiwei)書面許可，不允許用于商業用途的轉載、分發、和演繹。

在上一章中，我們介紹和對比了業界一些杰出的開源監控解決方案。早期，我們一直在用Zabbix，不過隨著業務的快速發展，以及互聯網公司特有的一些需求，現有的開源監控系統在性能、擴展性和用戶的使用效率方面，已經無法支撐了。

因此，從公司的一些需求出發，從各位運維人員、研發人員的使用經驗和反饋出發，結合業界一些大型互聯網公司監控系統的設計理念，研發了Open-Falcon，目標是做最開放、最好用的互聯網企業級監控產品（Open-Falcon的詳細內容，可以參考http://open-falcon.org）。

監控系統主要有4個功能：數據采集、告警、圖表展示和歷史數據挖掘。Open-Falcon也是著重從這4個方面來設計和開發的。Open-Falcon具有以下一些特點。

• 強大靈活的數據采集：通過配套的Falcon-agent，可以自動采集400多個單機指標，也可以通過用戶自定義的插件來增加更多的采集項。用戶可以自己實現采集程序獲取相關的指標，然后主動推送給監控系統，由監控系統負責后續的存儲、展示和告警功能。比如編寫腳本通過SNMP方式獲取網絡設備的相關運行指標，并把采集結果推送給監控系統。
• 良好的水平擴展能力：監控系統能通過水平擴展來支撐業務的快速發展。
• 高效率的告警策略管理：高效的用戶配置界面，支持策略模板，支持模板繼承和覆蓋，支持多種告警方式和回調動作。
• 人性化的告警設置：支持最大告警次數、告警級別設置、告警恢復通知、告警暫停、不同時段不同閾值，支持維護周期設置，支持告警合并。
• 高效的歷史數據查詢：采用RRDtool的數據歸檔策略，秒級返回上百個指標一年的歷史數據。
• 人性化的Dashboard：多維度的數據展示，用戶自定義Dashboard等功能。
• 高可用：整個系統無核心單點，易運維，易部署。

Open-Falcon架構

Open-Falcon架構示意圖如圖1所示。

圖1 Open-Falcon架構示意圖

整個監控系統，由Agent、Web-portal、Heartbeat-server、Dashboard、Transfer、Judge、Graph 等幾個核心組件構成。

Agent

做運維，不怕出問題，怕的是出了問題，抓不到現場兩眼抹黑。所以，依靠強大的監控系統，收集盡可能多的指標，意義重大。但哪些指標才是有意義的呢？本著從實踐中來的思想，各位工程師在長期摸爬滾打中總結出來的經驗最有價值。在運維工程師的長期工作實踐中，我們總結了在系統運維過程中經常會參考的一些指標，主要包括以下幾個類別。

• CPU
• Load
• 內存
• 磁盤
• IO
• 網絡相關
• 內核參數
• netstat/ss命令統計輸出
• 端口采集
• 核心服務的進程存活信息采集
• 關鍵業務進程資源消耗
• NTP Offset采集
• DNS解析采集

Agent是一個Daemon程序，只要安裝了Falcon-agent的Linux服務器，便會自發現地采集單機的各種數據指標，共計400多個，基本覆蓋了上面提到的各個類別。
這些采集好的指標，Agent會以一個固定的周期主動上報到服務端，并不需要用戶在服務端做任何配置（這和Zabbix有很大的不同）。這樣做的好處就是用戶維護起來方便，指標覆蓋率高，在服務器上架初始化的時候，就會自動安裝Agent。有了這些詳細的指標，對于運維人員和研發人員來講，事后追查問題不再是難題。當然，這樣做也會給服務端帶來一些壓力。

另外，Agent提供了一個Proxy-gateway功能，用戶可以方便地通過HTTP的方式，POST自定義的數據到本機的Proxy-gateway，Proxy-gateway會將這些數據轉發到服務端，便于用戶推送數據，并提高整個監控系統的穩定性。

Agent支持的這些采集項，都是大量運維人員在長期的工作中總結出來的，基本能覆蓋常見的一些監控需求。但仍然會存在一些特殊的業務需求，或者不適合在Agent里面內置的采集項，對于這些需求，如何更好地進行支持呢？我們設計開發了插件機制。

插件是符合一定規范的，由用戶開發的數據采集腳本或者可執行程序，Agent會負責周期性地調度這些插件，并將插件運行的輸出推送到監控系統。
插件的工作流程如圖2所示。

圖2 插件的工作流程圖

插件是作為一個Git項目（Falcon-plugin），通過Git來管理的。用戶編寫插件，完成測試之后，提交到Falcon-plugin的dev分支，并發起一個pull-request，管理員審核確認通過后，會合并到master分支。所有的Agent都會定期通過git pull來檢查獲取更新，這樣用戶提交的插件就更新到所有的服務器了。通過Git管理插件，好處就是版本管理和協作，所有的用戶都可以自由貢獻插件，通過pull-request合并到master分支。

插件更新到服務器之后，Agent并不會對其進行調度，因為某些插件只是解決特定的問題，并不適合在所有的服務器上運行，或者無法正常運行在所有的服務器上。從安全的角度和產品設計的角度考慮，用戶需要在Web-portal上進行配置，哪些機器允許執行哪些插件。完成這步操作后，相關的插件才會被相關服務器的Agent自動調度。

數據模型

在講述其他組件之前，有必要先描述一下Open-Falcon的數據模型（Data Model）。

數據模型是否強大、是否靈活，對于監控系統用戶的“使用效率”至關重要。比如以Zabbix為例，上報的數據格式為hostname（或者IP地址）、metric、timestamp、value這4個維度，那么用戶添加告警策略、管理告警策略的時候，就只能以這幾個維度來進行。

舉一個最常見的場景：hostA的磁盤空間，小于5%，就告警。在一般的服務器上，都會有兩個主要的分區，即root分區和home分區，在Zabbix中，就得加兩條規則；如果是Hadoop服務所在的機器，一般還會有十幾塊數據盤，還得再加十多條規則，這樣就會很煩瑣，不利于自動化（當然，Zabbix可以通過配置一些自動發現策略來搞定，不過仍然比較麻煩且不直觀）。

Open-Falcon采用類似于OpenTSDB的數據模型，由以下7個字段構成。

• metric：最核心的字段，代表這個數據采集項具體度量的是什么東西，比如是內存的使用量（memory_used），還是某個接口調用的次數（QPS）。
• endpoint：代表metric的主體，比如metric是內存使用量（memory_uesd），那么endpoint就表示該metric屬于哪臺機器。
• tags：這是一組用逗號分隔的鍵值對，用來對metric進行進一步的描述，比如service=falcon,location=beijing。
• timestamp：UNIX時間戳，表示產生該數據的時間點。
• value：整型或者浮點型，代表該metric在指定時間點的值。
• step：整型，表示該數據采集項的匯報周期，這對于后續的配置監控策略很重要，必須明確指定。
• counterType：只能是COUNTER或者GAUGE二選一，前者表示該采集項為計數器類型，后者表示其為原值。對于計數器類型，在告警判定以及圖表展示前，會被先計算為速率。

舉兩個例子：

{ 
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，表示這個指標的具體含義為服務器的磁盤可用百分比；endpoint描述這個metric所在的主體是hostA；tags是對這個metric的一組補充描述，比如mount=/home這一組tag，表示這個metric描述的是home分區的磁盤可用百分比；同樣mount=/root，表示這個metric描述的是root分區的磁盤可用百分比。

使用tags的好處是可以簡化告警策略的配置。比如上面提到的這個最簡單的場景，hostA的磁盤可用百分比小于5%就觸發告警。對于root和home兩個分區，在Open-Falcon中，可以用一條規則來描述，即 ：
>endpoint=hostA && metric=df.bytes.free.percent < 5%

而不再需要針對兩個分區，寫兩條規則：

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

另外，在Dashboard中，可以借助于tags，把tags作為篩選過濾條件，更方便用戶查看自己關心的指標。

#  數據采集
數據采集，是監控系統一個最基本的功能。在Open-Falcon中，Agent采集到的數據，會先發送給Transfer組件。Transfer接收到客戶端發送的數據，做一些數據規整、檢查之后轉發到多個后端系統去處理。在轉發到每個后端業務系統的時候，Transfer會根據一致性哈希算法進行數據分片，來達到后端業務系統的水平擴展。Transfer自身是無狀態的，掛掉一臺或者多臺不會有任何影響。

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

Transfer的數據來源一般有4種。
1. Falcon-agent主動采集的基礎監控數據。
2. Falcon-agent執行用戶自定義的插件返回的數據。
3. client-library：線上的業務系統，都嵌入使用了統一的基礎庫，對于業務系統中的每個業務接口，都會主動計算其CPS、Lantency等指標并上報。
4. 用戶產生的一些自定義的指標，由用戶自行上報。

這4種數據都會先發送給本機的Proxy-gateway，再由Proxy-gateway轉發給Transfer。

一個推送數據給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))

業務性能數據采集基礎庫設計思路

除了一些基礎采集項，線上業務各接口的各項性能數據也是研發人員和運維人員重點關注的內容。我們抽象總結出了兩類最通用的指標，供大家參考。

• 每秒調用次數：CPS。
• 接口調用延時：Lantency-75th、Lantency-95th、Lantency-99th。

即針對線上業務的每個接口，都會由基礎庫自動計算這兩類指標，并由基礎庫周期性地推送給本地的Proxy-gateway。這樣不用業務研發人員投入過多的精力，就可以自動化、標準化地采集業務性能指標數據。

有了相關的性能數據后，一方面，我們可以針對某些核心接口調用配置監控策略，在接口調用耗時增大到一定程度的時候，或者接口調用次數發生突升突降的時候，發送告警及時通知相關人員；另一方面，借助于性能數據，相關的研發人員和運維人員能夠更從容地規劃整個系統的容量，提高系統的穩定性以及資源利用率。

注：線上業務性能數據采集，一個開源的實現可以參考 http://metrics.dropwizard.io。

HTTP服務數據采集思路

目前HTTP服務仍然在我們的所有業務中占據重要地位，所以如何自動化地監控、評估Web服務的可用性指標和性能數據是非常重要的。我們的線上業務大量使用Nginx作為Web Server。

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

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

在第二階段，我們嘗試在Nginx中內嵌Lua腳本來自動計算和獲取每個Nginx Location對應的相關性能指標，包括：

• qps，該Location每秒被訪問的次數。
• request_time，請求的平均響應時間。
• upstream_time_to_xxx，upstream到某個后端的平均響應時間，用來衡量Nginx到每個后端應用服務器花費的時間。
• bytes_sent，每秒返回的字節數，用來衡量網絡帶寬的利用率。
• status_code.200，每秒鐘，HTTP的狀態碼等于200的次數。
• status_code.4xx，每秒鐘，HTTP的狀態碼大于等于400、小于500的次數。
• status_code.5xx，HTTP的狀態碼大于等于500的次數。
• availability : 1-(status_code.4xx + status_code.5xx) / qps，用來衡量服務的可用性。

采用該方案后，HTTP服務的各項指標的覆蓋率得到大大提高，數據分析的時效性也提高到1分鐘粒度，同時相對于第一階段日志分析的方案，該方案的運維成本得到大大降低，對服務器資源的消耗也降低到可以忽略不計的水平。

告警

告警判定，是由Judge組件來完成的。用戶在Web-portal上配置相關的報警策略，存儲在MySQL中。Heartbeat-server 會定期加載MySQL中的內容。Judge也會定期和Heartbeat-server保持溝通，來獲取相關的報警策略。

Heartbeat-server不僅僅是單純地加載MySQL中的內容。另一個重要功能是根據用戶配置的模板繼承關系、模板項覆蓋關系、報警動作覆蓋關系、模板和機器組的綁定關系，計算出最終關聯到每個endpoint的告警策略，下發給Judge組件來進行告警判定。

Transfer轉發到Judge的每條數據，都會觸發相關策略的判定，來決定是否滿足報警條件，如果條件滿足，則會將告警信息寫入告警隊列。Alarm會從告警隊列中獲取數據，再以郵件、短信、米聊等形式通知相關用戶，也可以執行用戶預先配置好的回調動作。

用戶可以很靈活地來配置告警判定策略，比如連續N次都滿足條件，連續N次的最大值滿足條件，不同的時間段設置不同的閾值，如果處于維護周期內則忽略告警等。同時也支持最大告警次數設置、告警級別設置，支持告警恢復通知、一段時間內突升突降判定等功能。

與告警組件相關的幾個重要概念如下。

• 告警策略：某個metric觸發告警需要滿足的條件，稱之為一個告警策略。比如cpu.idle，連續3次的值都小于10%，則觸發告警。這就是一個典型的告警策略。
• 模板：一組告警策略的集合，稱之為模板。模板和某個服務器分組綁定之后，該服務器分組下面的所有endpoint都會自動應用該模板中所有的策略。
• 服務器分組：一組endpoint的集合，稱之為一個服務器分組。一個endpoint加入某個服務器分組中，那么就會自動應用該分組所綁定的策略模板；同理，一個endpoint從某個服務器分組中去掉，這個endpoint便不再擁有該分組所綁定的策略模板。通過這種管理方式，使得服務擴容和縮減時監控可以自動化地變更。服務器分組是綁定策略模板的唯一單位。
• 告警動作：滿足告警策略需要后續執行的動作，稱之為告警動作。目前支持的告警動作包括發送短信、發送郵件、發送米聊、執行指定的回調動作?；卣{動作這種機制，便于用戶執行一些自動化的預案。

為了提高運維人員和研發人員配置、維護監控策略的效率，Open-Falcon有兩個很重要的功能：一是根據tag來設置告警策略；二是引入模板來組織告警策略。

根據tag來設置告警策略，我們在前面講述Open-Falcon數據模型的時候，有過簡單介紹。這里再舉幾個場景來說明一下。

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

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

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

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

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

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

模板之間可以存在繼承關系，子模板會自動擁有父模板中的所有策略。另外，在子模板中，可以覆蓋父模板中的某些策略。比如我們可以創建一些標準的模板，其他用戶只需要繼承該模板，做一些簡單的增、刪、改就可以使用了。模板的繼承和覆蓋特性，可以有效地幫助運維人員減少維護告警策略的工作量。

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

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

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

這時候，用戶的需求場景發生了變化，即如圖4所示的新場景中所描述的，用戶希望在場景一的基礎上，監控portal這個服務器分組下的所有服務器，其cpu_idle不能低于50%；否則發送告警給portal-dev用戶組。為了解決用戶的新需求，通常的做法是，去除FalconHostGroup和Template-A的綁定關系，然后給下面的5個子分組分別綁定不同的策略模板。這樣的操作方式，對用戶來講是非常煩瑣的，特別是在子分組很多的情況下。

在Open-Falcon中，我們可以利用模板的繼承和覆蓋特性，方便地滿足這個新需求。我們保持FalconHostGroup分組和Template-A的綁定關系不變，只需要給portal這個有特殊需求的分組單獨綁定一個策略模板Template-B即可，其中Template-B繼承自Template-A，且對Template-A中的cpu.idle策略項進行了覆蓋。這樣就可以滿足用戶的新需求了。

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

告警分級

同樣是告警，有的告警需要立即處理；否則就會造成很大的影響，比如嚴重影響用戶體驗，無法正常使用該業務的核心功能等；有的告警則時效性要求較低，比如多臺Nginx中的一臺宕機了，暫時不影響服務，稍后處理即可。告警分級，讓運維人員做到對重點故障重點關注。

考慮到這樣的場景，監控系統在設計的時候，允許用戶設置告警級別，對于高級別的告警，會優先在第一時間通過多種通道下發給相關用戶；對于低級別的告警，則只會通過郵件進行發送。

告警級別，是按照對服務、對用戶的影響范圍來確定的。下面是相關定義，如表24-1所示。

表24-1 告警級別定義

告警合并

不知道各位讀者在運維過程中，有沒有遇到過一些告警短信轟炸的場景，比如機房之間專線故障導致連通性下降，或者內網DNS出現問題導致各種解析失敗，短時間內產生大批量的告警。這些瞬時的大批量告警給運維和研發人員造成了很大的干擾，造成短信網關、郵件網關資源的浪費，同時也會淹沒一些重要的告警。因此，我們嘗試通過告警合并來解決這種告警轟炸問題。

在告警未合并之前，只要產生了告警，就會立即發送。如果要做合并，那么就必然需要有一個等待時間，比如產生告警后等1分鐘，然后看看這1分鐘里哪些告警可以合并為一條，最后再統一發送給目標用戶。告警合并需要有一定的規則，按照metric合并是一個很自然的方案，即很多endpoint的同一個metric告警，可以很自然地合并為一條，在減少告警數量的同時，盡可能少地丟失信息量。用戶收到合并后的消息后，如果想進一步查看詳情，可以點擊附加在告警消息中的詳情鏈接進入。

目前我們僅按照相同metric這一個維度來進行合并。更進一步，可以結合更多的緯度信息，比如相同機柜、同一接入交換機、同一類服務等，做到更智能、更準確的信息合并和問題定位。

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

數據存儲方案

對于監控系統來講，歷史數據的存儲、高效率查詢和快速展示是很重要且困難的問題。這主要表現在如下三個方面。

1. 數據量大：目前我們的監控系統每個周期大概有2500萬次數據采集項上報（上報周期為1分鐘和5分鐘兩種，各占50%），一天24小時里，從來不會有低峰，不管是白天還是黑夜，每個周期總會有那么多的數據要更新。
2. 寫操作多：一般的業務系統通常都是讀多寫少，可以方便地使用各種緩存技術。再者，各類數據庫對于查詢操作的處理效率遠遠高于寫操作。而監控系統恰恰相反，寫操作遠遠高于讀。每個周期幾千萬次的更新操作，對于常用數據庫（MySQL、PostgreSQL、MongoDB）都不是最合適和擅長的。
3. 高效率查詢：我們說監控系統讀操作少，是相對寫入來講的。監控系統本身對于讀的要求很高，用戶經常會查詢上百個metric，在過去一天、一周、一月、一年的數據。如何在秒級返回給用戶并在前端展現，這是一個不小的挑戰。

Open-Falcon在這塊投入了較大的精力。我們把數據按照用途分成兩類，一類是用于圖表展示的；一類是用戶做數據挖掘的。

對于圖表展示的數據來講，查詢要快是關鍵，同時盡可能不丟失信息量。對于用戶要查詢100個metric在過去一年里的數據，數據量是巨大的，很難能在1秒之內返回。另外，就算返回了，前端也無法渲染這么多的數據，還得再采樣，這就造成很多無謂的消耗。

我們參考RRDtool的理念，在數據每次存入的時候會自動進行采樣、歸檔。歸檔策略是，歷史數據保存5年。同時為了不丟失信息量，數據歸檔的時候，會按照平均值采樣、最大值采樣、最小值采樣存三份。用戶在查詢某個metric在過去一年的歷史數據時，Graph會選擇最合適的采樣頻率，返回采樣后的數據，提高了數據查詢速度。

以1分鐘的上報周期為例，下面是我們采用的數據歸檔采樣策略（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)

為了更進一步地提高寫入性能，Graph充分使用內存，將待更新的數據緩存一定的時間（30分鐘）后，再刷新到磁盤中，這樣對磁盤IO的壓力減少了一個數量級。同時為了避免刷新磁盤產生壓力峰值，我們把刷新磁盤的操作打散到了每一秒鐘。當然，使用緩存技術后，會產生兩個副作用，一是當程序異常崩潰或者服務器斷電的時候，會導致內存中尚未刷新到磁盤的數據丟失；二是用戶查詢數據的時候，就需要把內存中的數據和磁盤上的數據做合并，在一定程度上增加了代碼的復雜度。

前面在講述Transfer的時候，我們提到Transfer根據一致性哈希算法，將數據打散分發到后端不同的Graph實例上來達到水平擴展的能力。那么這里就存在一個問題，如果后端的Graph需要擴容實例數目的時候，一致性哈希算法得到的結果就會跟著發生變化，導致一部分歷史數據丟失。為了解決這個問題，我們正在給Transfer增加一個migrating功能，當后端Graph需要擴容實例數目的時候，Transfer會根據擴容前后的實例信息，對每個數據采集項進行兩次一致性哈希計算，根據計算結果來決定是否要進行數據遷移。

對于原始數據，Transfer會推送一份到HBase，也可以直接使用OpenTSDB，Transfer支持往OpenTSDB中寫入數據。

數據查詢

到這里，數據已經成功地存儲在Graph里了。如何快速地讀出來呢？讀過去1小時的、過去1天的、過去一月的、過去一年的，都需要在秒級時間內返回。

這些都是靠Graph和Query組件來實現的，Transfer會將數據往Graph組件中轉發一份，Graph收到數據以后，會以RRDtool的數據歸檔方式存儲，同時提供查詢RPC接口。

Query面向終端用戶，收到查詢請求后，根據一致性哈希算法，會去相應的Graph里面查詢不同metric的數據，匯總后統一返回給用戶。

Dashboard

在Dashboard首頁，用戶可以根據關鍵字來搜索endpoint，也可以根據上報的tags來搜索相關聯的endpoint，如圖5所示。

圖5 搜索

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

圖6 掌握服務的運行情況

當然，也可以查看清晰大圖，在橫坐標上放大或縮小區間范圍，快速篩選或反選監控項目，如圖7所示?？傊?，用戶的“使用效率”是第一要務。

圖7 查看清晰大圖

Web-portal

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

如圖8所示是服務器分組管理頁面，某個endpoint加入到某個服務器分組中，就會自動擁有該分組所綁定的所有策略列表。此處可以和服務樹結合，服務器進出服務樹節點，相關的模板會自動關聯或者解除。這樣服務上、下線都不需要手動來變更監控，大大提高了效率，降低了遺漏和誤報警。

圖8 服務器分組管理頁面

如圖9所示是一個最簡單的模板的例子。模板支持繼承和策略覆蓋，模板和服務器分組綁定后，該服務器分組下的endpoint會自動應用該模板的所有策略。
告警接收人這些配置信息，是作為模板的一個屬性存在的。給定一個模板綁定了服務器分組之后，當該模板中的任何一個策略滿足告警條件時，就會發送告警給模板的告警接收人。

圖9 模板示例

總結

監控系統是運維基礎設施中最重要的組成部分。本章，我們分享了從監控系統的選型、對比、優化到自研的整個過程。Open-Falcon項目可以在我們的github主頁https://github.com/open-falcon上找到，期待各位讀者一起交流和改進。

本文遵循「知識共享許可協議 CC-BY-NC-SA 4.0 International」，未經作者(laiwei)書面許可，不允許用于商業用途的轉載、分發、和演繹。