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

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

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

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

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

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

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

• 幫助定位故障 : 在發(fā)生故障時，我們可以通過查看監(jiān)控系統(tǒng)的各項指標數(shù)據(jù)，輔助故障分析和定位。
• 預警減少故障率 : 對于即將可能產(chǎn)生的故障能夠及時發(fā)出預警信息，做好提前預防處理。
• 輔助容量規(guī)劃 : 為服務器、中間件以及應用集群的容量規(guī)劃提供數(shù)據(jù)支撐。
• 輔助性能調優(yōu) : JVM垃圾回收次數(shù)、接口響應時間、慢SQL等等都可以監(jiān)控優(yōu)化。

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

• 服務器監(jiān)控 : CPU使用率、內存使用率、磁盤使用率、磁盤讀寫的吞吐量、網(wǎng)絡出入流量等等。

• MySQL監(jiān)控 : TPS、QPS、數(shù)據(jù)庫連接數(shù)、慢SQL、InnoDB緩沖池命中率等等。

• Redis監(jiān)控 : 內存使用率、緩存命中率、key值總數(shù)、Redis響應請求時間、客戶端連接數(shù)、持久性指標等等。

• MQ監(jiān)控 : 連接數(shù)、隊列數(shù)、生產(chǎn)速率、消費速率、消息堆積量等等。

• 應用監(jiān)控 :

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

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

• 數(shù)據(jù)采集 ：采集的方式有很多種，包括日志埋點進行采集，JMX標準接口輸出監(jiān)控指標，被監(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等關系數(shù)據(jù)庫存儲的，也有使用時序數(shù)據(jù)庫RRDTool、OpentTSDB、InfluxDB存儲的，還有使用HBase存儲的。
• 數(shù)據(jù)展示 ：數(shù)據(jù)指標的圖形化展示。
• 監(jiān)控告警 ：靈活的告警設置，以及支持郵件、短信、IM等多種通知通道。

基于 Spring Boot + MyBatis Plus + Vue & Element 實現(xiàn)的后臺管理系統(tǒng) + 用戶小程序，支持 RBAC 動態(tài)權限、多租戶、數(shù)據(jù)權限、工作流、三方登錄、支付、短信、商城等功能

• 項目地址：https://gitee.com/zhijiantianya/ruoyi-vue-pro
• 視頻教程：https://doc.iocoder.cn/video/

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

下面再來認識下主流的開源監(jiān)控系統(tǒng)，由于篇幅有限，我挑選了3款使用最廣泛的監(jiān)控系統(tǒng)：Zabbix 、Open-Falcon 、Prometheus ，會對它們的架構進行介紹，同時總結下各自的優(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的架構設計：

• 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等關系型數(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ù)傳輸方式。

Zabbix的劣勢：

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

2、Open-Falcon（小米出品，國內流行）

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

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

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

• Falcon-agent ：數(shù)據(jù)采集器和收集器，Go開發(fā)，部署在被監(jiān)控的機器上。就相當于Agent，用于采集機器負載監(jiān)控指標數(shù)據(jù)如：CPU、內存、磁盤、IO、網(wǎng)絡、端口等等大概有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ù)，匯總結果后統(tǒng)一返回給用戶，屏蔽了存儲集群的分片細節(jié)。

Open-Falcon優(yōu)勢

• 自動采集能力 ：Falcon-agent 能自動采集服務器的200多個基礎指標（比如CPU、內存等），無需在server上做任何配置，這一點可以秒殺Zabbix.
• 強大的存儲能力 ：底層采用RRDTool，并且通過一致性hash進行數(shù)據(jù)分片，構建了一個分布式的時序數(shù)據(jù)存儲系統(tǒng)，可擴展性強。
• 靈活的數(shù)據(jù)模型 ：借鑒OpenTSDB，數(shù)據(jù)模型中引入了tag，這樣能支持多維度的聚合統(tǒng)計以及告警規(guī)則設置，大大提高了使用效率。
• 插件統(tǒng)一管理 ：Open-Falcon的插件機制實現(xiàn)了對用戶自定義腳本的統(tǒng)一化管理，可通過HeartBeat Server分發(fā)給agent，減輕了使用者自主維護腳本的成本。
• 個性化監(jiān)控支持 ：基于Proxy-gateway，很容易通過自主埋點實現(xiàn)應用層的監(jiān)控（比如監(jiān)控接口的訪問量和耗時）和其他個性化監(jiān)控需求，集成方便。

Open-Falcon缺點

• 監(jiān)控類型較少 : 不支持常用應用服務器如tomcat、apache、jetty等的監(jiān)控。
• 整體發(fā)展一般，社區(qū)活躍度低 : 沒有專門的運維支持，代碼更新較少，沒有一個較大的社區(qū)來維護，后續(xù)想要有什么新的能力基本只能指望自己擴展。

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

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

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

先來了解下Prometheus的架構設計：

• Exporter ：主要用來采集數(shù)據(jù)，并通過 HTTP 服務的形式暴露給 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 方式進行設置的， 內置必須保證 prometheus server 和對應的 exporter 必須通信，當網(wǎng)絡情況無法直接滿足時，可以使用 pushgateway 來進行中轉，可以通過 pushgateway 將內部網(wǎng)絡數(shù)據(jù)主動 push 到 gateway 里面去，而 prometheus 采用 pull方式拉取 pushgateway 中數(shù)據(jù)。
• Alert Manager ：當支持基于 PromQL 創(chuàng)建告警規(guī)則，如果滿足定義的規(guī)則，則會產(chǎn)生一條告警信息，進入 AlertManager 進行處理。可以集成郵件，微信或者通過 webhook 自定義報警。
• Web UI ：Prometheus內置了一個簡單的web控制臺，可以查詢配置信息和指標等，而實際應用中我們通常會將Prometheus作為Grafana的數(shù)據(jù)源，創(chuàng)建儀表盤以及查看指標。

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

Prometheus缺點

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

基于 Spring Cloud Alibaba + Gateway + Nacos + RocketMQ + Vue & Element 實現(xiàn)的后臺管理系統(tǒng) + 用戶小程序，支持 RBAC 動態(tài)權限、多租戶、數(shù)據(jù)權限、工作流、三方登錄、支付、短信、商城等功能

• 項目地址：https://gitee.com/zhijiantianya/yudao-cloud
• 視頻教程：https://doc.iocoder.cn/video/

選型建議

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

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

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

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

4、Zabbix在服務器監(jiān)控方面占絕對優(yōu)勢，可以滿足90%以上的監(jiān)控場景，但是應用層的監(jiān)控似乎并不擅長，比如要監(jiān)控線程池的狀態(tà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)控沒有技術積累，建議使用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)解決相應的問題即可，可以多套監(jiān)控同時使用，這種在企業(yè)初期很常見。

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

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

審核編輯 ：李倩