大規模分布式監控系統研究

孔祥文，張 穎

（中國市政工程華北設計研究總院有限公司，天津 300074）

0 引言

監控是衡量和管理技術系統的工具和流程。對于管理和維護生產業務環境服務的技術人員來說，監控系統可以用來幫助他們掌握環境運行狀況，及時獲知系統中發生的問題甚至故障，作為分析、診斷故障的重要依據；對于業務產品或運營團隊來說，監控系統中的監控指標可以作為衡量用戶體驗的依據，并為業務團隊和人員提供反饋，以確保為客戶提供滿足質量要求的產品和服務。

所以監控系統是管理基礎設施和業務的不可或缺的核心工具，應該和信息化系統一起構建部署。如果沒有監控，維護人員就無法了解系統環境、進行故障診斷、制定容量計劃，也無法向公司或團隊管理層提供系統的性能、成本和狀態等可信賴的數據信息。

1 監控方法論

在介紹監控方法論前，先討論一下其中涉及的監控指標概念。監控指標是軟件或硬件組件屬性的度量，我們會追蹤其狀態并記錄一段時間內的數據點，這些數據點被稱作觀察點，觀察點包括數據值和時間戳兩部分，將觀察點按時間順序排列而產生的集合，被稱作時間序列。當前，大多數分布式監控系統都支持兩種指標類型：原始值（gauge）和計數值（counter）。原始值這種類型的指標值是特定度量的快照，數字值通常是上下增減變化的；計數值這種類型的指標值隨著時間的增加而不會減少。常見的監控指標比如 CPU利用率、內存利用率等都是原始值類型；而網卡收發包數、網絡字節數等監控指標就是計數值類型。

監控方法提供的指導原則可以縮小范圍并集中精力關注海量時間序列里面的特定指標，監控指標在結合監控方法論進行落地實踐后，才能更加有效地完成對信息化系統的監控目標。當前，業界比較流行的兩種監控方法：USE （Utilization、Saturation和Error）、Google四個黃金指標。這兩個監控方法論并不是對立的，而是有各自的側重范圍：前者側重于主機級的監控，后者專注于應用程序級的監控。針對不同層級的監控指標，結合使用兩種監控方法論才可以獲得一個比較全面并有效的環境視圖。

1 .1 USE方法[1]

USE是使用率（Utilization）、飽和度（Saturation）、錯誤（Error）的縮寫，指針對每個資源，檢查使用率、飽和度和錯誤，它對于監控那些受高使用率或飽和度等性能問題影響的資源是比較有效的。USE方法中四個術語的定義為：

（1）資源：指系統的一個組件，通常是物理服務器的某個組件，比如 CPU、磁盤等。

（2）使用率：資源處于工作繁忙狀態的平均時間，通常使用隨時間變化的百分比表示。

（3）飽和度：等待資源的隊列長度。

（4）錯誤：資源錯誤時間的累積數量。結合USE方法，我們先創建一份資源清單，然后針對每一項資源都采用使用率、飽和度、錯誤來實現監控。需要說明的是，并不是每項資源都完全具備有意義的三項指標，需要根據具體資源的屬性進行判斷。以 CPU資源為例，當遇到性能問題時，檢查CPU資源的以下內容：

（1）CPU使用率隨時間變化的百分比。

（2）等待 CPU的進程數，即 CPU飽和度。

（3）錯誤，通常對 CPU資源不太有影響。

1.2 Google四個黃金指標[2]

該方法來自 Google SRE手冊，它主要關注的不是系統級的時間序列指標數據，而是針對應用程序的上層指標內容：

（1）延遲：服務完成請求內容所花費的時間，注意需要區分成功請求和失敗請求。

（2）流量：服務的吞吐量，比如 HTTP服務器的請求數、數據庫服務器的事務數。

（3）錯誤：服務產生的錯誤響應速率，比如 HTTP服務器的 500錯誤、響應超時的數量等。

（4）飽和度：系統中目前最為受限的某種資源的某個具體指標的度量。復雜系統的飽和度需要配合其他高層次的負載度量來使用。

2 分布式監控軟件介紹

2.1 Ganglia

Ganglia采用gmond守護進程進行監控數據的收集和發送，通過分層架構、RRDtool數據存儲機制實現數以千計節點的監控。通過這個分層體系架構，一臺客戶端服務器可以管理上萬臺客戶端的數據節點，其最大的不足在于缺乏消息通知和告警機制。

Ganglia監控組件主要包括三個部分：Gmond、Gmetad、Gweb。

（1）Gmond作為發送者時，會收集本節點的系統負載、CPU使用率等基本指標；作為接收者，會將其他客戶端發來的指標進行收集并保存到內存緩沖區中。

（2）Gmetad是 Ganglia Server， 它 會 定 期 檢 查Gmond節點并從其拉取數據，然后存儲到 RRD存儲引擎里。

（3）Gweb是使用 PHP編寫的指標可視化組件，通常安裝在 Gmetad相同的主機上，以讀取 RRD存儲引擎。

Ganglia各組件的架構如圖 1所示。

圖1 Ganglia各組件架構圖

2.2 Zabbix

Zabbix豐富的數據采集方法，使其可以對幾乎所有類型的監控數據進行采集和處理；有賴于其靈活的告警機制，可以實現復雜的多條件告警策略；具備自動發現和自動注冊功能；具有多種圖表展示類型，自帶畫圖功能，Web圖形化能力強大。

Zabbix主要組件有：Zabbix Server、Zabbix Proxy、Zabbix Web Frontend、Zabbix Agent、Zabbix DB。

（1）Zabbix Server作為核心組件，可以配置管理所有被監控設備及監控項目，接收被監控設備數據和項目狀態信息，創建形式多樣的報表用于展示監控數據，同時可以實現對告警信息的判定與發送等。

（2）Zabbix Proxy可以作為 Zabbix Server的代替，用于收集和接收監控數據和狀態信息，并將數據轉發給Zabbix Server。在中小型監控環境里，Zabbix Proxy并不是必須的，但在大規模分布式監控場景下，可以減輕Zabbix Server的監控壓力、提高監控系統的整體性能。

（3）Zabbix Web Frontend是用于配置監控信息和查看監控數據的前端 Web組件。在中小型監控環境里，Web組件一般和 Zabbix Server安裝在同一臺服務器上；在大型復雜監控場景下，一般和 Zabbix Server部署到不同的服務器上以減輕壓力。

（4）Zabbix Agent是部署到被監控主機或設備上的客戶端組件，用以采集系統上各種監控數據并發送給Zabbix Server。

（5）Zabbix DB 支 持 MySQL、Oracle、SQLite、PostgreSQL等多種數據庫軟件對監控設備及監控項目的配置信息和采集到的監控數據進行存儲。

Zabbix系統組件關系如圖 2所示。

圖2 Zabbix系統組件關系圖

由于Zabbix采用的是關系型數據庫存儲監控數據，在龐大的監控規模下，Zabbix DB的寫入性能將成為整個系統的性能瓶頸，需要專業的DBA進行數據庫優化。并且核心組件 Zabbix Server、Zabbix Agent都是使用C++編寫的，二次開發的難度較大。

2.3 Open-falcon

Open-falcon是小米公司發布的開源企業級監控系統，Open-falcon采用RRDtool數據存儲機制，在應對海量節點的大型監控場景下，Open-falcon比 Zabbix更加強大、易于擴展。Open-falcon本身的組件比較多，都可以獨立部署，可以大致分為服務端和客戶端組件。除了dashboard使用了 python開發，其他組件都使用golang開發，二次開發相對簡單。Open-falcon的不足之處在于其本身圖表展示類型較單一，不如Zabbix系統那么豐富，且組件比較多，在大規模監控場景下對維護人員的要求比較高。

2.4 Prometheus

Prometheus采用時序數據庫存儲監控數據，支持通過服務發現和靜態配置來發現監控目標，支持靈活的查詢語言和第三方可視化組件 Grafana，采用Golang編寫，性能好，支持的時序數據類型也比較豐富。Prometheus監控系統的主要組件有：Prometheus Server、Exporter、Pushgateway、Alertmanager，以及經常配合使用的第三方可視化組件Grafana。Prometheus監控系統組件較少，維護成本低，由 Golang編寫，二次開發的難度也較低，并且是當前流行的容器編排系統 Kubernetes官方推薦的集群監控方案。不足之處是當前中文的文檔資料較少，學習成本較高。

3 結束語

本文首先闡述了在信息化系統中重要組成部分監控的概念與意義，然后介紹了業界優秀的監控方法論，以指導具體監控方案的落地應用，接著重點介紹了業界四款流行的開源監控軟件和它們各自的架構與特點，以指導從業人員根據各自實際場景選擇具體方案實現自己的監控系統。總體來看，Prometheus監控系統屬于下一代監控，既可以支持傳統的主機、設備、服務的監控，也能夠解決容器云平臺的監控需求。