這篇文章，我將對(duì)監(jiān)控體系的基礎(chǔ)知識(shí)、原理和架構(gòu)做一次系統(tǒng)性整理，同時(shí)還會(huì)對(duì)幾款最常用的開(kāi)源監(jiān)控產(chǎn)品做下介紹，以便大家選型時(shí)參考。內(nèi)容包括3部分：

• 必知必會(huì)的監(jiān)控基礎(chǔ)知識(shí)
• 主流監(jiān)控系統(tǒng)介紹
• 監(jiān)控系統(tǒng)的選型建議

一、必知必會(huì)的監(jiān)控基礎(chǔ)知識(shí)

我們可以理解監(jiān)控系統(tǒng)就像我們古代打戰(zhàn)的哨兵一樣，哨兵的角色非常重要，敵人來(lái)了，哨兵會(huì)第一時(shí)間發(fā)出預(yù)警(吹笛、打鼓、放煙)，讓守城的戰(zhàn)士能夠最快的時(shí)間處理，應(yīng)對(duì)。

那對(duì)于我們應(yīng)用系統(tǒng)而言，監(jiān)控系統(tǒng)就像我們第三只眼，如果有應(yīng)用系統(tǒng)出現(xiàn)問(wèn)題，我們可以通過(guò)監(jiān)控系統(tǒng)看是哪里出現(xiàn)問(wèn)題，是redis掛了，還是說(shuō)服務(wù)器內(nèi)存滿(mǎn)了，有監(jiān)控系統(tǒng)我們可以很輕松、快速的定位問(wèn)題。

甚至我們可以設(shè)置預(yù)警，對(duì)一些將要出現(xiàn)的問(wèn)題進(jìn)行提前預(yù)防處理，及時(shí)避免問(wèn)題的發(fā)生。

1、監(jiān)控系統(tǒng)的作用

1）幫助定位故障

在發(fā)生故障時(shí)，我們可以通過(guò)查看監(jiān)控系統(tǒng)的各項(xiàng)指標(biāo)數(shù)據(jù)，輔助故障分析和定位。

2）預(yù)警減少故障率

對(duì)于即將可能產(chǎn)生的故障能夠及時(shí)發(fā)出預(yù)警信息，做好提前預(yù)防處理。

3）輔助容量規(guī)劃

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

4）輔助性能調(diào)優(yōu)

JVM垃圾回收次數(shù)、接口響應(yīng)時(shí)間、慢SQL等等都可以監(jiān)控優(yōu)化。

2、常見(jiàn)的監(jiān)控對(duì)象和指標(biāo)都有哪些？

1）服務(wù)器監(jiān)控

CPU使用率、內(nèi)存使用率、磁盤(pán)使用率、磁盤(pán)讀寫(xiě)的吞吐量、網(wǎng)絡(luò)出入流量等等。

2）MySQL監(jiān)控

TPS、QPS、數(shù)據(jù)庫(kù)連接數(shù)、慢SQL、InnoDB緩沖池命中率等等。

3）Redis監(jiān)控

內(nèi)存使用率、緩存命中率、key值總數(shù)、Redis響應(yīng)請(qǐng)求時(shí)間、客戶(hù)端連接數(shù)、持久性指標(biāo)等等。

4）MQ監(jiān)控

連接數(shù)、隊(duì)列數(shù)、生產(chǎn)速率、消費(fèi)速率、消息堆積量等等。

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

• HTTP接口：URL存活、請(qǐng)求量、耗時(shí)、異常量。
• JVM ：GC次數(shù)、GC耗時(shí)、各個(gè)內(nèi)存區(qū)域的大小、當(dāng)前線(xiàn)程數(shù)、死鎖線(xiàn)程數(shù)。
• 線(xiàn)程池：活躍線(xiàn)程數(shù)、任務(wù)隊(duì)列大小、任務(wù)執(zhí)行耗時(shí)、拒絕任務(wù)數(shù)。
  

3、監(jiān)控系統(tǒng)的基本流程

1）數(shù)據(jù)采集

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

2）數(shù)據(jù)傳輸

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

3）數(shù)據(jù)存儲(chǔ)

有使用MySQL、Oracle等關(guān)系數(shù)據(jù)庫(kù)存儲(chǔ)的，也有使用時(shí)序數(shù)據(jù)庫(kù)RRDTool、OpentTSDB、InfluxDB存儲(chǔ)的，還有使用HBase存儲(chǔ)的。

4）數(shù)據(jù)展示

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

5）監(jiān)控告警

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

二、市面上的一些常見(jiàn)監(jiān)控系統(tǒng)比較

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

1、Zabbix介紹

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

先來(lái)了解下Zabbix的架構(gòu)設(shè)計(jì)：

• Zabbix Server

核心組件，C語(yǔ)言編寫(xiě)，負(fù)責(zé)接收Agent、Proxy發(fā)送的監(jiān)控?cái)?shù)據(jù)。同時(shí)，它還負(fù)責(zé)數(shù)據(jù)的匯總存儲(chǔ)以及告警觸發(fā)等。

• Zabbix Proxy

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

• Zabbix Agentd

部署在被監(jiān)控主機(jī)上，用于采集本機(jī)的數(shù)據(jù)并發(fā)送給Proxy或者Server。數(shù)據(jù)收集方式同時(shí)支持主動(dòng)Push和被動(dòng)Pull 兩種模式。

• Database

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

• Web Server

Zabbix的GUI組件，PHP編寫(xiě)，提供監(jiān)控?cái)?shù)據(jù)的展現(xiàn)和告警配置。

1）Zabbix的優(yōu)勢(shì)

• 產(chǎn)品成熟

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

• 采集方式豐富

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

2）Zabbix的劣勢(shì)

需要在被監(jiān)控主機(jī)上安裝Agent，所有的數(shù)據(jù)都存在數(shù)據(jù)庫(kù)里，產(chǎn)生的數(shù)據(jù)很大，瓶頸主要在數(shù)據(jù)庫(kù)。

2、Open-Falcon（小米出品，國(guó)內(nèi)流行）

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

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

架構(gòu)看去比Zabbix復(fù)雜多了，其實(shí)它也是基于Server---Agent的模式，只不過(guò)Server又給他劃分了好幾個(gè)組件，這個(gè)耦合性和擴(kuò)展性都得到了明顯提高。

• Falcon-agent

數(shù)據(jù)采集器和收集器，Go開(kāi)發(fā)，部署在被監(jiān)控的機(jī)器上。就相當(dāng)于Agent，用于采集機(jī)器負(fù)載監(jiān)控指標(biāo)數(shù)據(jù)如：CPU、內(nèi)存、磁盤(pán)、IO、網(wǎng)絡(luò)、端口等等大概有200多個(gè)這些都可以自定是否收集。

• Transfer

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

• Graph

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

• Judge和Alarm

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

• API

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

1）Open-Falcon優(yōu)勢(shì)

• 自動(dòng)采集能力

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

• 強(qiáng)大的存儲(chǔ)能力

底層采RRDTool，并且通過(guò)一致性hash進(jìn)行數(shù)據(jù)分片，構(gòu)建了一個(gè)分布式的時(shí)序數(shù)據(jù)存儲(chǔ)系統(tǒng)，可擴(kuò)展性強(qiáng)。

• 靈活的數(shù)據(jù)模型

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

• 插件統(tǒng)一管理

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

• 個(gè)性化監(jiān)控支持

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

2）Open-Falcon缺點(diǎn)

• 監(jiān)控類(lèi)型較少

不支持常用應(yīng)用服務(wù)器如tomcat、apache、jetty等的監(jiān)控。

• 整體發(fā)展一般，社區(qū)活躍度低

沒(méi)有專(zhuān)門(mén)的運(yùn)維支持，代碼更新較少，沒(méi)有一個(gè)較大的社區(qū)來(lái)維護(hù)，后續(xù)想要有什么新的能力基本只能指望自己擴(kuò)展。

3、Prometheus（號(hào)稱(chēng)下一代監(jiān)控系統(tǒng)）

我們知道 zabbix 在監(jiān)控界占有不可撼動(dòng)的地位，功能強(qiáng)大。但是對(duì)容器監(jiān)控顯得力不從心。為解決監(jiān)控容器的問(wèn)題，引入了 Prometheus 技術(shù)。

Prometheus 是一套開(kāi)源的系統(tǒng)監(jiān)控報(bào)警框架。是由前google員工2015年正式發(fā)布的開(kāi)源監(jiān)控系統(tǒng)，采用Go語(yǔ)言開(kāi)發(fā)。它不僅有一個(gè)很酷的名字，同時(shí)它有Google與k8s的強(qiáng)力支持，開(kāi)源社區(qū)異?；鸨?/span>

先來(lái)了解下Prometheus的架構(gòu)設(shè)計(jì)：

• Exporter

主要用來(lái)采集數(shù)據(jù)，并通過(guò) HTTP 服務(wù)的形式暴露給 Prometheus Server，Prometheus Server 通過(guò)訪問(wèn)該 Exporter 提供的接口，即可獲取到需要采集的監(jiān)控?cái)?shù)據(jù)。常見(jiàn)的Exporter有很多，例如node_exporter、mysqld_exporter、redis_exporter 等

• Prometheus Server

核心組件，負(fù)責(zé)實(shí)現(xiàn)對(duì)監(jiān)控?cái)?shù)據(jù)的獲取，存儲(chǔ)以及查詢(xún)。Prometheus Server 也是一個(gè)時(shí)序數(shù)據(jù)庫(kù)，它將監(jiān)控?cái)?shù)據(jù)保存在本地磁盤(pán)中，并對(duì)外提供自定義的 PromQL 語(yǔ)言實(shí)現(xiàn)對(duì)數(shù)據(jù)的查詢(xún)和分析。

• Push gateway

由于 Prometheus 數(shù)據(jù)采集采用 pull 方式進(jìn)行設(shè)置的， 內(nèi)置必須保證 prometheus server 和對(duì)應(yīng)的 exporter 必須通信，當(dāng)網(wǎng)絡(luò)情況無(wú)法直接滿(mǎn)足時(shí)，可以使用 pushgateway 來(lái)進(jìn)行中轉(zhuǎn)，可以通過(guò) pushgateway 將內(nèi)部網(wǎng)絡(luò)數(shù)據(jù)主動(dòng) push 到 gateway 里面去，而 prometheus 采用 pull方式拉取 pushgateway 中數(shù)據(jù)。

• Alert Manager

當(dāng)支持基于 PromQL 創(chuàng)建告警規(guī)則，如果滿(mǎn)足定義的規(guī)則，則會(huì)產(chǎn)生一條告警信息，進(jìn)入 AlertManager 進(jìn)行處理?？梢约舌]件，微信或者通過(guò) webhook 自定義報(bào)警。

• Web UI

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

1）Prometheus優(yōu)點(diǎn)

• 社區(qū)活躍度高

github start超過(guò)40k，且一直在維護(hù)。

• 基于時(shí)序數(shù)據(jù)庫(kù)，存儲(chǔ)效率高

Prometheus核心部分只有一個(gè)單獨(dú)的二進(jìn)制文件，不存在任何的第三方依賴(lài)(數(shù)據(jù)庫(kù)，緩存等等)。唯一需要的就是 本地磁盤(pán)，因此不會(huì)有潛在級(jí)聯(lián)故障的風(fēng)險(xiǎn)。

• 很好地支持容器監(jiān)控

能自動(dòng)發(fā)現(xiàn)容器，同時(shí)k8s和etcd等項(xiàng)目都提供了對(duì)Prometheus的原生支持，是目前容器監(jiān)控最流行的方案。

• 基于Pull模型的架構(gòu)

Prometheus基于Pull模型的架構(gòu)方式，可以在任何地方（本地電腦，開(kāi)發(fā)環(huán)境，測(cè)試環(huán)境）搭建我們的監(jiān)控系統(tǒng)。

2）Prometheus缺點(diǎn)

• Prometheus 是基于 Metric 的監(jiān)控，不適用于日志（Logs）、事件(Event)、調(diào)用鏈(Tracing)。
• 由于Prometheus采用的是Pull模型拉取數(shù)據(jù)，意味著所有被監(jiān)控的endpoint必須是可達(dá)的，需要合理規(guī)劃網(wǎng)絡(luò)的安全配置。
• 指標(biāo)眾多，需進(jìn)行適當(dāng)裁剪。

三、選型建議

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

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

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

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

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

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

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

7）Zabbix、Open-Falcon和Prometheus都支持和Grafana做快速集成，想要美觀且強(qiáng)大的可視化體驗(yàn)，可以和Grafana進(jìn)行組合。

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

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

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