這篇文章，我將對監(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)的選型建議

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

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

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

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

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

1）幫助定位故障

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

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

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

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

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

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

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

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

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

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

2）MySQL監(jiān)控

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

3）Redis監(jiān)控

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

4）MQ監(jiān)控

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

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

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

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

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

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

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

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

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

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

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

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

5）監(jiān)控告警

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

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

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

1、Zabbix介紹

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 Server

核心組件，C語言編寫，負責接收Agent、Proxy發(fā)送的監(jiān)控數(shù)據(jù)。同時，它還負責數(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ù)收集方式同時支持主動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)和告警配置。

1）Zabbix的優(yōu)勢

• 產(chǎn)品成熟

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

• 采集方式豐富

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

2）Zabbix的劣勢

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

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

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的諸多痛點。

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

• Falcon-agent

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

• 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ù)庫）做單個指標的存儲，并通過緩存、分批寫入磁盤等方式進行了優(yōu)化。據(jù)說一個graph實例能夠處理8W+每秒的寫入速率。

• Judge和Alarm

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

• API

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

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

• 自動采集能力

Falcon-agent 能自動采集服務(wù)器的200多個基礎(chǔ)指標（比如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)控需求，集成方便。

2）Open-Falcon缺點

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

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

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

沒有專門的運維支持，代碼更新較少，沒有一個較大的社區(qū)來維護，后續(xù)想要有什么新的能力基本只能指望自己擴展。

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

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

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

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

• Exporter

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

• Prometheus Server

核心組件，負責實現(xiàn)對監(jiān)控數(shù)據(jù)的獲取，存儲以及查詢。Prometheus Server 也是一個時序數(shù)據(jù)庫，它將監(jiān)控數(shù)據(jù)保存在本地磁盤中，并對外提供自定義的 PromQL 語言實現(xiàn)對數(shù)據(jù)的查詢和分析。

• Push gateway

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

• Alert Manager

當支持基于 PromQL 創(chuàng)建告警規(guī)則，如果滿足定義的規(guī)則，則會產(chǎn)生一條告警信息，進入 AlertManager 進行處理。可以集成郵件，微信或者通過 webhook 自定義報警。

• Web UI

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

1）Prometheus優(yōu)點

• 社區(qū)活躍度高

github start超過40k，且一直在維護。

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

Prometheus核心部分只有一個單獨的二進制文件，不存在任何的第三方依賴(數(shù)據(jù)庫，緩存等等)。唯一需要的就是 本地磁盤，因此不會有潛在級聯(lián)故障的風險。

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

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

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

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

2）Prometheus缺點

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

三、選型建議

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

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

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

3）從系統(tǒng)成熟度上看，Zabbix屬于老牌的監(jiān)控系統(tǒng)，資料多，功能全面且穩(wěn)定，如果機器數(shù)量在幾百臺以內(nèi)，不用太擔心性能問題，另外，采用數(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)控方面的標配，有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)勢。