主流監(jiān)控系統(tǒng)技術(shù)選型

今天這篇文章，我將對監(jiān)控體系的基礎(chǔ)知識、原理和架構(gòu)做一次系統(tǒng)性梳理，同時還會對幾款最常用的開源監(jiān)控產(chǎn)品做下介紹，以便大家選型時參考。

內(nèi)容包括3部分：

必知必會的監(jiān)控基礎(chǔ)知識

主流監(jiān)控系統(tǒng)介紹

監(jiān)控系統(tǒng)的選型建議

01 必知必會的監(jiān)控基礎(chǔ)知識

監(jiān)控系統(tǒng)俗稱「第三只眼」，幾乎是我們每天都會打交道的系統(tǒng)，下面 4 項基礎(chǔ)知識我認(rèn)為是必須要了解的。

1. 監(jiān)控系統(tǒng)的7大作用 正所謂「無監(jiān)控，不運維」，監(jiān)控系統(tǒng)的地位不言而喻。不管你是監(jiān)控系統(tǒng)的開發(fā)者還是使用者，首先肯定要清楚：監(jiān)控系統(tǒng)的目標(biāo)是什么？它能發(fā)揮什么作用？

實時采集監(jiān)控數(shù)據(jù)：包括硬件、操作系統(tǒng)、中間件、應(yīng)用程序等各個維度的數(shù)據(jù)。

實時反饋監(jiān)控狀態(tài)：通過對采集的數(shù)據(jù)進行多維度統(tǒng)計和可視化展示，能實時體現(xiàn)監(jiān)控對象的狀態(tài)是正常還是異常。

預(yù)知故障和告警：能夠提前預(yù)知故障風(fēng)險，并及時發(fā)出告警信息。

輔助定位故障：提供故障發(fā)生時的各項指標(biāo)數(shù)據(jù)，輔助故障分析和定位。

輔助性能調(diào)優(yōu)：為性能調(diào)優(yōu)提供數(shù)據(jù)支持，比如慢SQL，接口響應(yīng)時間等。

輔助容量規(guī)劃：為服務(wù)器、中間件以及應(yīng)用集群的容量規(guī)劃提供數(shù)據(jù)支撐。

輔助自動化運維：為自動擴容或者根據(jù)配置的SLA進行服務(wù)降級等智能運維提供數(shù)據(jù)支撐。

2.使用監(jiān)控系統(tǒng)的正確姿勢

“

出任何線上事故，先不說其他地方有問題，監(jiān)控部分一定是有問題的。

聽著很甩鍋的一句話，仔細(xì)思考好像有一定道理。我們在事故復(fù)盤時，通常會思考這3個和監(jiān)控有關(guān)的問題：有沒有做監(jiān)控？監(jiān)控是否及時？監(jiān)控信息是否有助于快速定位問題？

可見光有一套好的監(jiān)控系統(tǒng)還不夠，還必須知道「如何用好它」。一個成熟的研發(fā)團隊通常會定一個監(jiān)控規(guī)范，用來統(tǒng)一監(jiān)控系統(tǒng)的使用方法。

了解監(jiān)控對象的工作原理：要做到對監(jiān)控對象有基本的了解，清楚它的工作原理。比如想對JVM進行監(jiān)控，你必須清楚JVM的堆內(nèi)存結(jié)構(gòu)和垃圾回收機制。

確定監(jiān)控對象的指標(biāo)：清楚使用哪些指標(biāo)來刻畫監(jiān)控對象的狀態(tài)？比如想對某個接口進行監(jiān)控，可以采用請求量、耗時、超時量、異常量等指標(biāo)來衡量。

定義合理的報警閾值和等級：達到什么閾值需要告警？對應(yīng)的故障等級是多少？不需要處理的告警不是好告警，可見定義合理的閾值有多重要，否則只會降低運維效率或者讓監(jiān)控系統(tǒng)失去它的作用。

建立完善的故障處理流程：收到故障告警后，一定要有相應(yīng)的處理流程和oncall機制，讓故障及時被跟進處理。

3. 監(jiān)控的對象和指標(biāo)都有哪些？ 監(jiān)控已然成為了整個產(chǎn)品生命周期非常重要的一環(huán)，運維關(guān)注硬件和基礎(chǔ)監(jiān)控，研發(fā)關(guān)注各類中間件和應(yīng)用層的監(jiān)控，產(chǎn)品關(guān)注核心業(yè)務(wù)指標(biāo)的監(jiān)控?？梢?，監(jiān)控的對象已經(jīng)越來越立體化。 這里，我對常用的監(jiān)控對象以及監(jiān)控指標(biāo)做了分類整理，供大家參考。

3.1 硬件監(jiān)控

包括：電源狀態(tài)、CPU狀態(tài)、機器溫度、風(fēng)扇狀態(tài)、物理磁盤、raid狀態(tài)、內(nèi)存狀態(tài)、網(wǎng)卡狀態(tài)

3.2 服務(wù)器基礎(chǔ)監(jiān)控

CPU：單個CPU以及整體的使用情況

內(nèi)存：已用內(nèi)存、可用內(nèi)存

磁盤：磁盤使用率、磁盤讀寫的吞吐量

網(wǎng)絡(luò)：出口流量、入口流量、TCP連接狀態(tài)

3.3數(shù)據(jù)庫監(jiān)控

包括：數(shù)據(jù)庫連接數(shù)、QPS、TPS、并行處理的會話數(shù)、緩存命中率、主從延時、鎖狀態(tài)、慢查詢

3.4中間件監(jiān)控

Nginx：活躍連接數(shù)、等待連接數(shù)、丟棄連接數(shù)、請求量、耗時、5XX錯誤率

Tomcat：最大線程數(shù)、當(dāng)前線程數(shù)、請求量、耗時、錯誤量、堆內(nèi)存使用情況、GC次數(shù)和耗時

緩存：成功連接數(shù)、阻塞連接數(shù)、已使用內(nèi)存、內(nèi)存碎片率、請求量、耗時、緩存命中率

消息隊列：連接數(shù)、隊列數(shù)、生產(chǎn)速率、消費速率、消息堆積量

3.5應(yīng)用監(jiān)控

HTTP接口：URL存活、請求量、耗時、異常量

RPC接口：請求量、耗時、超時量、拒絕量

JVM ：GC次數(shù)、GC耗時、各個內(nèi)存區(qū)域的大小、當(dāng)前線程數(shù)、死鎖線程數(shù)

線程池：活躍線程數(shù)、任務(wù)隊列大小、任務(wù)執(zhí)行耗時、拒絕任務(wù)數(shù)

連接池：總連接數(shù)、活躍連接數(shù)

日志監(jiān)控：訪問日志、錯誤日志

業(yè)務(wù)指標(biāo)：視業(yè)務(wù)來定，比如PV、訂單量等

4. 監(jiān)控系統(tǒng)的基本流程 無論是開源的監(jiān)控系統(tǒng)還是自研的監(jiān)控系統(tǒng)，監(jiān)控的整個流程大同小異，一般都包括以下模塊：

數(shù)據(jù)采集：采集的方式有很多種，包括日志埋點進行采集（通過Logstash、Filebeat等進行上報和解析），JMX標(biāo)準(zhǔn)接口輸出監(jiān)控指標(biāo)，被監(jiān)控對象提供REST API進行數(shù)據(jù)采集（如Hadoop、ES），系統(tǒng)命令行，統(tǒng)一的SDK進行侵入式的埋點和上報等。

數(shù)據(jù)傳輸：將采集的數(shù)據(jù)以TCP、UDP或者HTTP協(xié)議的形式上報給監(jiān)控系統(tǒng)，有主動Push模式，也有被動Pull模式。

數(shù)據(jù)存儲：有使用MySQL、Oracle等RDBMS存儲的，也有使用時序數(shù)據(jù)庫RRDTool、OpentTSDB、InfluxDB存儲的，還有使用HBase存儲的。

數(shù)據(jù)展示：數(shù)據(jù)指標(biāo)的圖形化展示。

監(jiān)控告警：靈活的告警設(shè)置，以及支持郵件、短信、IM等多種通知通道。

02 主流監(jiān)控系統(tǒng)介紹 下面再來認(rèn)識下主流的開源監(jiān)控系統(tǒng)，由于篇幅有限，我挑選了3款使用最廣泛的監(jiān)控系統(tǒng)：Zabbix、Open-Falcon、Prometheus，會對它們的架構(gòu)進行介紹，同時總結(jié)下各自的優(yōu)劣勢。

1. Zabbix（老牌監(jiān)控的優(yōu)秀代表）

Zabbix 1998年誕生，核心組件采用C語言開發(fā)，Web端采用PHP開發(fā)。它屬于老牌監(jiān)控系統(tǒng)中的優(yōu)秀代表，監(jiān)控功能很全面，使用也很廣泛，差不多有70%左右的互聯(lián)網(wǎng)公司都曾使用過 Zabbix 作為監(jiān)控解決方案。

先來了解下Zabbix的架構(gòu)設(shè)計：

Zabbix架構(gòu)圖

Zabbix Server：核心組件，C語言編寫，負(fù)責(zé)接收Agent、Proxy發(fā)送的監(jiān)控數(shù)據(jù)，也支持JMX、SNMP等多種協(xié)議直接采集數(shù)據(jù)。同時，它還負(fù)責(zé)數(shù)據(jù)的匯總存儲以及告警觸發(fā)等。

Zabbix Proxy：可選組件，對于被監(jiān)控機器較多的情況下，可使用Proxy進行分布式監(jiān)控，它能代理Server收集部分監(jiān)控數(shù)據(jù)，以減輕Server的壓力。

Zabbix Agentd：部署在被監(jiān)控主機上，用于采集本機的數(shù)據(jù)并發(fā)送給Proxy或者Server，它的插件機制支持用戶自定義數(shù)據(jù)采集腳本。Agent可在Server端手動配置，也可以通過自動發(fā)現(xiàn)機制被識別。數(shù)據(jù)收集方式同時支持主動Push和被動Pull 兩種模式。

Database：用于存儲配置信息以及采集到的數(shù)據(jù)，支持MySQL、Oracle等關(guān)系型數(shù)據(jù)庫。同時，最新版本的Zabbix已經(jīng)開始支持時序數(shù)據(jù)庫，不過成熟度還不高。

Web Server：Zabbix的GUI組件，PHP編寫，提供監(jiān)控數(shù)據(jù)的展現(xiàn)和告警配置。

下面是 Zabbix 的優(yōu)勢：

產(chǎn)品成熟：由于誕生時間長且使用廣泛，擁有豐富的文檔資料以及各種開源的數(shù)據(jù)采集插件，能覆蓋絕大部分監(jiān)控場景。

采集方式豐富：支持Agent、SNMP、JMX、SSH等多種采集方式，以及主動和被動的數(shù)據(jù)傳輸方式。

較強的擴展性：支持Proxy分布式監(jiān)控，有agent自動發(fā)現(xiàn)功能，插件式架構(gòu)支持用戶自定義數(shù)據(jù)采集腳本。

配置管理方便：能通過Web界面進行監(jiān)控和告警配置，操作方便，上手簡單。

下面是 Zabbix 的劣勢：

性能瓶頸：機器量或者業(yè)務(wù)量大了后，關(guān)系型數(shù)據(jù)庫的寫入一定是瓶頸，官方給出的單機上限是5000臺，個人感覺達不到，尤其現(xiàn)在應(yīng)用層的指標(biāo)越來越多。雖然最新版已經(jīng)開始支持時序數(shù)據(jù)庫，不過成熟度還不高。

應(yīng)用層監(jiān)控支持有限：如果想對應(yīng)用程序做侵入式的埋點和采集（比如監(jiān)控線程池或者接口性能），zabbix沒有提供對應(yīng)的sdk，通過插件式的腳本也能曲線實現(xiàn)此功能，個人感覺zabbix就不是做這個事的。

數(shù)據(jù)模型不強大：不支持tag，因此沒法按多維度進行聚合統(tǒng)計和告警配置，使用起來不靈活。

方便二次開發(fā)難度大：Zabbix采用的是C語言，二次開發(fā)往往需要熟悉它的數(shù)據(jù)表結(jié)構(gòu)，基于它提供的API更多只能做展示層的定制。

2. Open-Falcon

Open-falcon 是小米2015年開源的企業(yè)級監(jiān)控工具，采用Go和Python語言開發(fā)，這是一款靈活、高性能且易擴展的新一代監(jiān)控方案，目前小米、美團、滴滴等超過200家公司在使用它。

小米初期也使用的Zabbix進行監(jiān)控，但是機器量和業(yè)務(wù)量上來后，Zabbix就有些力不從心了。因此，后來自主研發(fā)了Open-Falcon，在架構(gòu)設(shè)計上吸取了Zabbix的經(jīng)驗，同時很好地解決了Zabbix的諸多痛點。

先來了解下Open-Falcon的架構(gòu)設(shè)計：

Open-Falcon架構(gòu)圖，來自網(wǎng)絡(luò)

Falcon-agent：數(shù)據(jù)采集器和收集器，Go開發(fā)，部署在被監(jiān)控的機器上，支持3種數(shù)據(jù)采集方式。首先它能自動采集單機200多個基礎(chǔ)監(jiān)控指標(biāo)，無需做任何配置；同時支持用戶自定義的plugin獲取監(jiān)控數(shù)據(jù)；此外，用戶可通過http接口，自主push數(shù)據(jù)到本機的proxy-gateway，由gateway轉(zhuǎn)發(fā)到server.

Transfer：數(shù)據(jù)分發(fā)組件，接收客戶端發(fā)送的數(shù)據(jù)，分別發(fā)送給數(shù)據(jù)存儲組件Graph和告警判定組件Judge，Graph和Judge均采用一致性hash做數(shù)據(jù)分片，以提高橫向擴展能力。同時Transfer還支持將數(shù)據(jù)分發(fā)到OpenTSDB，用于歷史歸檔。

Graph：數(shù)據(jù)存儲組件，底層使用RRDTool（時序數(shù)據(jù)庫）做單個指標(biāo)的存儲，并通過緩存、分批寫入磁盤等方式進行了優(yōu)化。據(jù)說一個graph實例能夠處理8W+每秒的寫入速率。

Judge和Alarm：告警組件，Judge對Transfer組件上報的數(shù)據(jù)進行實時計算，判斷是否要產(chǎn)生告警事件，Alarm組件對告警事件進行收斂處理后，將告警消息推送給各個消息通道。

API：面向終端用戶，收到查詢請求后會去Graph中查詢指標(biāo)數(shù)據(jù)，匯總結(jié)果后統(tǒng)一返回給用戶，屏蔽了存儲集群的分片細(xì)節(jié)。

下面是Open-Falcon的優(yōu)勢：

自動采集能力：Falcon-agent 能自動采集服務(wù)器的200多個基礎(chǔ)指標(biāo)（比如CPU、內(nèi)存等），無需在server上做任何配置，這一點可以秒殺Zabbix.

強大的存儲能力：底層采用RRDTool，并且通過一致性hash進行數(shù)據(jù)分片，構(gòu)建了一個分布式的時序數(shù)據(jù)存儲系統(tǒng)，可擴展性強。

靈活的數(shù)據(jù)模型：借鑒OpenTSDB，數(shù)據(jù)模型中引入了tag，這樣能支持多維度的聚合統(tǒng)計以及告警規(guī)則設(shè)置，大大提高了使用效率。

插件統(tǒng)一管理：Open-Falcon的插件機制實現(xiàn)了對用戶自定義腳本的統(tǒng)一化管理，可通過HeartBeat Server分發(fā)給agent，減輕了使用者自主維護腳本的成本。

個性化監(jiān)控支持：基于Proxy-gateway，很容易通過自主埋點實現(xiàn)應(yīng)用層的監(jiān)控（比如監(jiān)控接口的訪問量和耗時）和其他個性化監(jiān)控需求，集成方便。

下面是Open-Falcon的劣勢：

整體發(fā)展一般：社區(qū)活躍度不算高，同時版本更新慢，有些大廠是基于它的穩(wěn)定版本直接做二次開發(fā)的，關(guān)于以后的前景其實有點擔(dān)憂。

UI不夠友好：對于業(yè)務(wù)線的研發(fā)來說，可能只想便捷地完成告警配置和業(yè)務(wù)監(jiān)控，但是它把機器分組、策略模板、模板繼承等概念全部暴露在UI上，感覺在圍繞這幾個概念設(shè)計UI，理解有點費勁。

安裝比較復(fù)雜：個人的親身感受，由于它是從小米內(nèi)部衍生出來的，雖然去掉了對小米內(nèi)部系統(tǒng)的依賴，但是組件還是比較多，如果對整個架構(gòu)不熟悉，安裝很難一蹴而就。

3. Prometheus（號稱下一代監(jiān)控系統(tǒng)）

Prometheus（普羅米修斯）是由前google員工2015年正式發(fā)布的開源監(jiān)控系統(tǒng)，采用Go語言開發(fā)。它不僅有一個很酷的名字，同時它有Google與k8s的強力支持，開源社區(qū)異常火爆。

Prometheus 2016年加入云原生基金會，是繼k8s后托管的第二個項目，未來前景被相當(dāng)看好。它和Open-Falcon最大不同在于：數(shù)據(jù)采集是基于Pull模式的，而不是Push模式，并且架構(gòu)非常簡單。

先來了解下Prometheus的架構(gòu)設(shè)計：

Prometheus架構(gòu)圖，來自網(wǎng)絡(luò)

Prometheus Server：核心組件，用于收集、存儲監(jiān)控數(shù)據(jù)。它同時支持靜態(tài)配置和通過Service Discovery動態(tài)發(fā)現(xiàn)來管理監(jiān)控目標(biāo)，并從監(jiān)控目標(biāo)中獲取數(shù)據(jù)。此外，Prometheus Server 也是一個時序數(shù)據(jù)庫，它將監(jiān)控數(shù)據(jù)保存在本地磁盤中，并對外提供自定義的 PromQL 語言實現(xiàn)對數(shù)據(jù)的查詢和分析。

Exporter：用來采集數(shù)據(jù)，作用類似于agent，區(qū)別在于Prometheus是基于Pull方式拉取采集數(shù)據(jù)的，因此，Exporter通過HTTP服務(wù)的形式將監(jiān)控數(shù)據(jù)按照標(biāo)準(zhǔn)格式暴露給Prometheus Server，社區(qū)中已經(jīng)有大量現(xiàn)成的Exporter可以直接使用，用戶也可以使用各種語言的client library自定義實現(xiàn)。

Push gateway：主要用于瞬時任務(wù)的場景，防止Prometheus Server來pull數(shù)據(jù)之前此類Short-lived jobs就已經(jīng)執(zhí)行完畢了，因此job可以采用push的方式將監(jiān)控數(shù)據(jù)主動匯報給Push gateway緩存起來進行中轉(zhuǎn)。

Alert Manager：當(dāng)告警產(chǎn)生時，Prometheus Server將告警信息推送給Alert Manager，由它發(fā)送告警信息給接收方。

Web UI：Prometheus內(nèi)置了一個簡單的web控制臺，可以查詢配置信息和指標(biāo)等，而實際應(yīng)用中我們通常會將Prometheus作為Grafana的數(shù)據(jù)源，創(chuàng)建儀表盤以及查看指標(biāo)。

下面是Prometheus的優(yōu)勢：

輕量管理：架構(gòu)簡單，不依賴外部存儲，單個服務(wù)器節(jié)點可直接工作，二進制文件啟動即可，屬于輕量級的Server，便于遷移和維護。

較強的處理能力：監(jiān)控數(shù)據(jù)直接存儲在Prometheus Server本地的時序數(shù)據(jù)庫中，單個實例可以處理數(shù)百萬的metrics。

靈活的數(shù)據(jù)模型：同Open-Falcon，引入了tag，屬于多維數(shù)據(jù)模型，聚合統(tǒng)計更方便。

強大的查詢語句：PromQL允許在同一個查詢語句中，對多個metrics進行加法、連接和取分位值等操作。

很好地支持云環(huán)境：能自動發(fā)現(xiàn)容器，同時k8s和etcd等項目都提供了對Prometheus的原生支持，是目前容器監(jiān)控最流行的方案。

下面是Prometheus的劣勢：

功能不夠完善：Prometheus從一開始的架構(gòu)設(shè)計就是要做到簡單，不提供集群化方案，長期的持久化存儲和用戶管理，而這些是企業(yè)變大后所必須的特性，目前要做到這些只能在Prometheus之上進行擴展。

網(wǎng)絡(luò)規(guī)劃變復(fù)雜：由于Prometheus采用的是Pull模型拉取數(shù)據(jù)，意味著所有被監(jiān)控的endpoint必須是可達的，需要合理規(guī)劃網(wǎng)絡(luò)的安全配置。

03監(jiān)控系統(tǒng)的選型建議

通過上面的介紹，大家對主流的監(jiān)控系統(tǒng)應(yīng)該有了一定的認(rèn)識。面對選型問題，我的建議是：

1、先明確清楚你的監(jiān)控需求：要監(jiān)控的對象有哪些？機器數(shù)量和監(jiān)控指標(biāo)有多少？需要具備什么樣的告警功能？

2、監(jiān)控是一項長期建設(shè)的事情，一開始就想做一個 All In One 的監(jiān)控解決方案，我覺得沒有必要。從成本角度考慮，在初期直接使用開源的監(jiān)控方案即可，先解決有無問題。

3、從系統(tǒng)成熟度上看，Zabbix屬于老牌的監(jiān)控系統(tǒng)，資料多，功能全面且穩(wěn)定，如果機器數(shù)量在幾百臺以內(nèi)，不用太擔(dān)心性能問題，另外，采用數(shù)據(jù)庫分區(qū)、SSD硬盤、Proxy架構(gòu)、Push采集模式都可以提高監(jiān)控性能。

4、Zabbix在服務(wù)器監(jiān)控方面占絕對優(yōu)勢，可以滿足90%以上的監(jiān)控場景，但是應(yīng)用層的監(jiān)控似乎并不擅長，比如要監(jiān)控線程池的狀態(tài)、某個內(nèi)部接口的執(zhí)行時間等，這種通常都要做侵入式埋點。相反，新一代的監(jiān)控系統(tǒng)Open-Falcon和Prometheus在這一點做得很好。

5、從整體表現(xiàn)上來看，新一代監(jiān)控系統(tǒng)也有明顯的優(yōu)勢，比如：靈活的數(shù)據(jù)模型、更成熟的時序數(shù)據(jù)庫、強大的告警功能，如果之前對zabbix這種傳統(tǒng)監(jiān)控沒有技術(shù)積累，建議使用Open-Falcon或者Prometheus.

6、Open-Falcon的核心優(yōu)勢在于數(shù)據(jù)分片功能，能支撐更多的機器和監(jiān)控項；Prometheus則是容器監(jiān)控方面的標(biāo)配，有Google和k8s加持。

7、Zabbix、Open-Falcon和Prometheus都支持和Grafana做快速集成，想要美觀且強大的可視化體驗，可以和Grafana進行組合。

8、用合適的監(jiān)控系統(tǒng)解決相應(yīng)的問題即可，可以多套監(jiān)控同時使用，這種在企業(yè)初期很常見。

9、到中后期，隨著機器數(shù)據(jù)增加和個性化需求增多（比如希望統(tǒng)一監(jiān)控平臺、打通公司的CMDB和組織架構(gòu)關(guān)系），往往需要二次開發(fā)或者通過監(jiān)控系統(tǒng)提供的API做集成，從這點來看，Open-Falcon或者Prometheus更合適。

10、如果非要自研，可以多研究下主流監(jiān)控系統(tǒng)的架構(gòu)方案，借鑒它們的優(yōu)勢。

審核編輯：郭婷