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

• 必知必會的監控基礎知識
• 主流監控系統介紹
• 監控系統的選型建議

必知必會的監控基礎知識

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

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

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

1、監控系統的作用

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

2、常見的監控對象和指標都有哪些？

• 服務器監控 : CPU使用率、內存使用率、磁盤使用率、磁盤讀寫的吞吐量、網絡出入流量等等。

• MySQL監控 : TPS、QPS、數據庫連接數、慢SQL、InnoDB緩沖池命中率等等。

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

• MQ監控 : 連接數、隊列數、生產速率、消費速率、消息堆積量等等。

• 應用監控 :

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

3、監控系統的基本流程

• 數據采集 ：采集的方式有很多種，包括日志埋點進行采集，JMX標準接口輸出監控指標，被監控對象提供REST API進行數據采集（如Hadoop、ES），系統命令行，統一的SDK進行侵入式的埋點和上報等。
• 數據傳輸 ：將采集的數據以TCP、UDP或者HTTP協議的形式上報給監控系統，有主動Push模式，也有被動Pull模式。
• 數據存儲 ：有使用MySQL、Oracle等關系數據庫存儲的，也有使用時序數據庫RRDTool、OpentTSDB、InfluxDB存儲的，還有使用HBase存儲的。
• 數據展示 ：數據指標的圖形化展示。
• 監控告警 ：靈活的告警設置，以及支持郵件、短信、IM等多種通知通道。

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

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

市面上的一些常見監控系統比較

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

1、Zabbix介紹

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

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

• Zabbix Server ：核心組件，C語言編寫，負責接收Agent、Proxy發送的監控數據。同時，它還負責數據的匯總存儲以及告警觸發等。
• Zabbix Proxy ：可選組件，對于被監控機器較多的情況下，可使用Proxy進行分布式監控，它能代理Server收集部分監控數據，以減輕Server的壓力。
• Zabbix Agentd ：部署在被監控主機上，用于采集本機的數據并發送給Proxy或者Server。數據收集方式同時支持主動Push和被動Pull 兩種模式。
• Database ：用于存儲配置信息以及采集到的數據，支持MySQL、Oracle等關系型數據庫。同時，最新版本的Zabbix已經開始支持時序數據庫，不過成熟度還不高。
• Web Server ：Zabbix的GUI組件，PHP編寫，提供監控數據的展現和告警配置。

Zabbix的優勢：

• 產品成熟 ：由于誕生時間長且使用廣泛，擁有豐富的文檔資料以及各種開源的數據采集插件，能覆蓋絕大部分監控場景。
• 采集方式豐富 ：支持Agent、SNMP、JMX、SSH等多種采集方式，以及主動和被動的數據傳輸方式。

Zabbix的劣勢：

需要在被監控主機上安裝Agent，所有的數據都存在數據庫里，產生的數據很大，瓶頸主要在數據庫。

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

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

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

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

• Falcon-agent ：數據采集器和收集器，Go開發，部署在被監控的機器上。就相當于Agent，用于采集機器負載監控指標數據如：CPU、內存、磁盤、IO、網絡、端口等等大概有200多個這些都可以自定是否收集。
• Transfer ：數據分發組件，接收客戶端發送的數據，分別發送給數據存儲組件Graph和告警判定組件Judge，Graph和Judge均采用一致性hash做數據分片，以提高橫向擴展能力。同時Transfer還支持將數據分發到OpenTSDB，用于歷史歸檔。
• Graph ：數據存儲組件，底層使用RRDTool（時序數據庫）做單個指標的存儲，并通過緩存、分批寫入磁盤等方式進行了優化。據說一個graph實例能夠處理8W+每秒的寫入速率。
• Judge和Alarm ：告警組件，Judge對Transfer組件上報的數據進行實時計算，判斷是否要產生告警事件，Alarm組件對告警事件進行收斂處理后，將告警消息推送給各個消息通道。
• API ：面向終端用戶，收到查詢請求后會去Graph中查詢指標數據，匯總結果后統一返回給用戶，屏蔽了存儲集群的分片細節。

Open-Falcon優勢

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

Open-Falcon缺點

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

3、Prometheus（號稱下一代監控系統）

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

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

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

• Exporter ：主要用來采集數據，并通過 HTTP 服務的形式暴露給 Prometheus Server，Prometheus Server 通過訪問該 Exporter 提供的接口，即可獲取到需要采集的監控數據。常見的Exporter有很多，例如node_exporter、mysqld_exporter、redis_exporter 等
• Prometheus Server ：核心組件，負責實現對監控數據的獲取，存儲以及查詢。Prometheus Server 也是一個時序數據庫，它將監控數據保存在本地磁盤中，并對外提供自定義的 PromQL 語言實現對數據的查詢和分析。
• Push gateway ：由于 Prometheus 數據采集采用 pull 方式進行設置的， 內置必須保證 prometheus server 和對應的 exporter 必須通信，當網絡情況無法直接滿足時，可以使用 pushgateway 來進行中轉，可以通過 pushgateway 將內部網絡數據主動 push 到 gateway 里面去，而 prometheus 采用 pull方式拉取 pushgateway 中數據。
• Alert Manager ：當支持基于 PromQL 創建告警規則，如果滿足定義的規則，則會產生一條告警信息，進入 AlertManager 進行處理。可以集成郵件，微信或者通過 webhook 自定義報警。
• Web UI ：Prometheus內置了一個簡單的web控制臺，可以查詢配置信息和指標等，而實際應用中我們通常會將Prometheus作為Grafana的數據源，創建儀表盤以及查看指標。

Prometheus優點

• 社區活躍度高 : github start超過40k，且一直在維護。
• 基于時序數據庫，存儲效率高 :Prometheus核心部分只有一個單獨的二進制文件，不存在任何的第三方依賴(數據庫，緩存等等)。唯一需要的就是 本地磁盤，因此不會有潛在級聯故障的風險。
• 很好地支持容器監控 : 能自動發現容器，同時k8s和etcd等項目都提供了對Prometheus的原生支持，是目前容器監控最流行的方案。
• 基于Pull模型的架構 : Prometheus基于Pull模型的架構方式，可以在任何地方（本地電腦，開發環境，測試環境）搭建我們的監控系統。

Prometheus缺點

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

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

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

選型建議

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

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

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

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

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

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

6、Open-Falcon的核心優勢在于數據分片功能，能支撐更多的機器和監控項；Prometheus則是容器監控方面的標配，有Google和k8s加持。

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

8、用合適的監控系統解決相應的問題即可，可以多套監控同時使用，這種在企業初期很常見。

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

10、如果非要自研，可以多研究下主流監控系統的架構方案，借鑒它們的優勢。

審核編輯 ：李倩