時常會聽到很多運維伙伴在爭論，Prometheus 和 Zabbix 哪一個更好?在我看來，脫離實際應用場景討論技術的優劣其實是沒有任何意義的。

[[347265]]

圖片來自 Pexels

 

Zabbix 適合的監控場景

監控的維度

在選擇具體的監控平臺之前，我們最先需要明確，我們監控的目標是什么?在我的理解中，監控分為兩個維度：即監控的廣度和監控的深度。

①監控的廣度

 

大家所需要監控的系統少則幾種，多則幾十種，比如需要監控硬件、存儲、操作系統、中間件、數據庫及應用等。

而在每一個平臺中，又存在多種平臺：比如我們有華為、戴爾、惠普、IBM 的硬件服務器或者交換機，同時也會有 Windows、Linux、Aix、ESXi 等多種操作系統。

系統和平臺維度的組合，意味著我們不僅僅要監控多個層級的監控，也意味著每個層級內部的需要監控的對象更精細化。因此系統異構性和平臺的多樣性構成了運維的復雜性。

綜上，一個理想的監控平臺應該支持基于各類系統，覆蓋各類廠商和平臺的監控。

②監控的深度

 

相對的，監控目標需要考慮的另一維度是監控的深度。就監控深度而言，我們可以將其簡單分成可用性監控、性能監控、日志監控和自定義監控這四大類。

可用性監控：它的狀態是一個布爾型，即只有 1 或者 0。比方說，一個服務是處于停止狀態還是運行狀態，一個端口是 Up 還是 Down，根據可用性監控我們可以獲知監控對象是否處于正常狀態。

性能監控：是基于可用性監控的更進一步監控。比如說我們監控某個 IP 地址，在可用性監控中我們會去 Ping 這個 IP。

如果通，就說明這個 IP 可達;更進一步，Ping 延遲就是這個 IP 的性能監控。通過性能監控，我們可以獲知監控對象的健康程度以及負載水平。CPU、內存使用率，磁盤的 IOPS，網絡的吞吐量，都是常見的性能監控指標。

日志監控：不管是可用性監控還是性能監控，都基于一定的輪詢周期進行采樣，在兩個采樣點之間的監控其實是缺失的，因此在兩個采樣點之間可能會遺漏一些異常監控數據。

通過日志監控，可以記錄下每一個操作或者行為，確保監控的完整性。常用的日志監控會分為安全日志、系統日志、應用日志和操作日志等。

自定義的監控：顧名思義，根據我們自身的情況去定義一些符合我們監控需求的監控指標。比如訂單數、網絡設備流量的聚合運算等等。

一個理想的監控平臺應該支持不同的監控深度和方式，從可用性監控、性能監控、日志監控到自定義監控。

監控選型

綜合監控的廣度和監控的深度這兩點，為我們進行監控平臺的選型提供了一個思路和依據：

 

當我們的環境中只有 Windows 的服務器時，顯然微軟的 System Center 更合適，它不僅能比其他平臺更快的發現問題，并有完善的知識庫提供具體的解決方案。

不過，通常情況下我們的環境中還充滿了網絡設備、Linux、存儲等其他監控對象。

這個時候使用 System Center 去監控可能就比較難以實施了，即使能實施，仍然會存在較高的成本或者技術局限性。同樣 Solarwind 更加適合網絡設備的監控。

那么有沒有一個產品可以兼具監控的廣度和監控的深度呢?經過各種評估和試用，我們認為 Zabbix 可能是在目前兼顧監控廣度和深度的最合適的監控平臺。

剛才也提到了 Zabbix 和 Prometheus 孰優孰劣一直是大家爭議的熱點，接下來我們對這兩者在不同維度做一些簡單的比較。

①UI 方面

Zabbix 5.0 界面如下圖：

Zabbix 一直被吐槽的最多的一點就是它的 UI。

 

的確，在 Zabbix 早些的版本比如 1.8，2.2 中，它的 UI 并沒有那么友善和好看。

但是官方團隊始終在不斷迭代和完善 UI，5.0 的 UI 已經非常現代化，而且圖形圖表的展現也更豐富多彩。

同時 Zabbix 90% 以上的配置管理操作都可以通過 Zabbix 的 Web 端實現，僅有一部分基礎配置需要通過配置文件處理。

這樣有一個很大的好處：所有的維護都會有統一的入口，而且只要通過簡單的點擊、拖拽操作就可以完成，大大提升了運維團隊的效率。

Prometheus界面如下圖：

 

Prometheus 的界面相對比較基礎，提供類似 SQL 的查詢界面，可以簡單查詢某些指標。大家更常用的是 Grafana 作為 Prometheus 的前端。

Zabbix 本身也可以把 Grafana 作為前端，但就原生的 UI 進行對比，Prometheus 稍微簡單了點。

同時，Prometheus 絕大多數的操作和維護都通過配置文件進行。對上大批量監控對象的維護，必須要依賴于第三方的配置管理工具，因此運維復雜度會比Zabbix更高。

②架構方面

Zabbix 架構圖如下：

Zabbix 是一個分布式的監控系統。在很多公司內部，尤其是金融機構，會存在多個網絡區域，每個區域之間進行了隔離。

 

Zabbix 支持在每個網絡區域內部署一個 Zabbix Proxy，即 Zabbix 的代理服務器，這個服務器的職責是收集當前區域的監控對象的監控數據。

同時 Zabbix Proxy 會和 Zabbix Server 打通，把收集到的數據提供給 Zabbix Server 進行后續處理，比如觸發告警。

我們也會把 Web 端部署在一個用戶可以訪問的區域，這樣做的好處是用戶可以在正常的辦公環境而不是機房中訪問 Zabbix。

對于 Zabbix 使用的數據庫，使用 one proxy 或者 mycat 方式，能夠提高它的高可用性，同時也確保數據庫的主從分離。

這種架構的好處在于從庫作為讀庫提供給其他系統訪問，比如 CMDB 或者報表系統，同時不會影響主庫的性能。

由于 Zabbix 各個組件進行了分離，防火墻上只需要打通一些必要的網絡通路，不需要把所有監控主機的端口都像 Zabbix Server 暴露，從而提升了安全性。

Prometheus 架構圖如下：

總體而言，Prometheus 的架構和 Zabbix 有很多相似之處：

 

• Prometheus 使用各種 Exporter 進行監控，Exporter 的功能類似于 Zabbix 的 Agent，負責收集監控對象端的數據。
• Prometheus 的 AlertManager 類似于 Zabbix 的 Action，可以進行報警觸發，比如發送短信和郵件。

存在不同的一點是：Prometheus 使用的數據庫是 TSDB 時序數據庫，Zabbix 使用的是 MySQL 或者 PgSQL 的關系型數據庫。

TSDB 在存儲監控的性能會優于傳統關系型數據庫，因此 Zabbix 也開始嘗試性的支持 TSDB 作為后端的數據存儲。

在監控平臺的選型時，也需要評估數據庫是否是監控的瓶頸，當性能和壓力尚不能成為監控平臺的瓶頸時，TSDB 時序數據庫的優勢并不會十分明顯。

以上是 Zabbix 和 Prometheus 在不同幾個方面的對比，那也希望這些對比能為大家在監控平臺選型時，提供一定的參考依據。

在我所處的環境中，由于我們需要監控很多不同類型的設備和平臺，因此選擇了 Zabbix 作為統一監控平臺。依托 Zabbix 的一些特性，也大大提升了自動化監控的水平。

③Zabbix 的高級特性

開源免費，社區支持：很多的軟件雖然開源，但會有商業版和社區版區分，比如 MySQL、Puppet 等。商業版本會要求用戶付費，但同時會提供更完善和更高級的功能。

而 Zabbix 本身不僅開源，而且不存在商業版和社區版之分，官方保持著定期版本更新的頻率，在每一個新版本中也會修復問題或改善用戶體驗。

同時，Zabbix 除了原廠團隊以外，也會有社區的支持，在中國也有活躍的用戶社區，以及每年定期的 Zabbix 大會等活動。

分布式，高可用：Zabbix 本身也是分布式高可用的，這也很好的解決了單點的問題。

低級別發現，自動發現：這是 Zabbix 全棧自動化監控中最不可或缺的兩個特性。

低級別發現：低級別發現能幫助我們發現一臺設備上所有的監控對象。

試想一個場景，我們有 100 臺服務器，每臺服務器上至少有 2 塊硬盤，最多有 20 塊硬盤。

如果我們要監控這些磁盤的 IOPS、剩余磁盤空間 1、磁盤隊列長度等 10 個指標，需要怎么去添加監控?

常規的做法是，我在每 1 臺服務器上，根據服務器實際的磁盤數量，為每一塊磁盤添加監控，如果平均每臺 10 塊磁盤，那么就是要增加 100*10*10 個監控項，總計 10000 個監控項。

不止于此，還要繼續為這 10000 個監控項配置觸發器和告警規則。

而在 Zabbix 中，我們只需創建一個模版，定義低級別發現的規則，并將這個模版同這 100 臺需要監控的服務器關聯即可。

Zabbix 會根據服務器上實際的磁盤數量自動生成對應的監控項，大大提升了添加監控的效率，同時也減少了手動添加監控的紕漏。

自動發現：它能幫助我們快速發現網絡內的設備，并按規則識別出它的類型，將其和指定的模版進行關聯。

全棧級監控：就像剛才所介紹的，Zabbix 在監控的廣度和深度之間做了一個比較好的權衡，它是一個全棧級的監控平臺。

從底層的硬件、操作系統、中間件、數據庫，到上層的應用、業務，都可以納入到 Zabbix 的監控范圍中。

實現了通過一個統一的監控平臺，覆蓋所有監控對象不同層次監控的需求，同時降低了維護多套監控平臺的成本和所需要的知識積累，方便上手。

可定制，與 DevOps 流水線集成：Zabbix 本身也是一個開放的系統。提供了豐富的 API，這些 API 幾乎可以實現界面上所有的功能，可以同企業內部的 DevOps 持續交付流水線進行集成，提升整體自動化的水平。

Zabbix 全棧自動化監控實踐案例

接下來，我們來討論下 Zabbix 這些高級特性在實際使用場景中的最佳實踐案例。

分布式自動化監控

 

首先來看下我們是如何通過自動發現特性實現監控的自動添加的：

我們會在 Zabbix 中配置自動發現規則，比如我們對制定的網段進行掃描。當我們發現網段中某個 IP 的 1433 端口是打開的，我們基本上可以推斷它上面運行著微軟的 SQLServer 服務。

因此，我們通過已經配置好的規則，將發現的這個開放著 1433 端口的 IP 和 SQLServer 模版進行關聯。

SQLServer 的模版是我們預先定制好的對于微軟數據庫的監控模版，通過自動發現，我們能達到兩個目的：

• 所有的微軟數據庫都被監控到了。
• 所有被監控的數據庫使用了同一套監控基線，實現了標準化監控。

同樣的，我們也可以通過定制不同的規則，來添加不同類型的監控，比如 3306 是 MySQL 的監控等。

除了關聯模版，我們會把監控對象添加到不同的組中，確保每個組關聯了對應的運維人員。

這樣做的好處在于，我們不需要頻繁的更新告警策略，而當故障發生的時候，對應的管理員也能第一時間收到告警。

雙維度管理(平臺維度/業務維度)

 

剛才提到了組的概念，我們在實際應用中，一個監控對象屬于兩個組，即一個 P 組(平臺組)和一個 S 組(業務組)。

IT 運維人員的視角和業務人員的視角存在差異性，通常一個組織內會雇傭不同角色的 IT 專業人員，比如 Windows 管理員，Linux 管理員，DBA 等。

DBA 會負責所有數據庫相關的運維工作，而且不在乎這個數據庫屬于那個應用系統。

因此所有的數據庫服務器，比如所有的 MySQL，都會放到一個叫做 P-DB-MySQL 的組中。

這個組所有的告警會發送給指定的 DBA 而不是 Windows 管理員，同時會和對應的 MySQL 監控模版進行關聯。

這樣做的收益在于 DBA 只會收到他們所負責系統的告警，同時監控也實現了標準化。

而業務人員關注的是整體業務應用是否正常運行。比如一個登陸系統，它可能有前端的 Tomcat 中間件，還有一臺 MySQL 存放著用戶登錄信息，底層跑著一臺 HP 的服務器。

那么我們會把這三個監控對象放在一個叫做 S-Department1-Login 的組中。

這樣做的好處在于，一旦一個監控對象出現任何問題，我們可以第一時間知道它影響什么系統。

通過 P 組和 S 組的結合，我們可以在監控告警不被遺漏的同時，最大限度降低監控噪音，同時也能直觀知曉當前的問題會對那些業務造成影響。

告警方式

 

Zabbix 支持非常多的告警方式，這點類似于 Prometheus 的 AlertManager。

首先我們會對報警進行分級，Zabbix 原生提供了 5 種級別的告警，即 Disaster，High，Warning，Average 和 Info。

我們使用了其中的三種，并給出了這三種級別告警的定義：

• Disaster：觸發后需要立即處理，如不處理會直接影響生產系統的告警。
• Warning：觸發后需要盡快處理，短期不處理不會直接影響生產系統。
• Info：提示性的告警。

不同級別的報警會對應不同的策略，比如 Disaster 告警會發送給 IT 負責人和系統管理員;Warning 告警只會發送給系統管理員;Info 不會發送告警，但會在監控大屏上展現。

具體的告警分級和策略可以根據企業內部的實際情況和監控需求進行定制。

對于告警的呈現方式，主要有郵件、短信和監控大屏等幾種，多渠道的告警確保了我們的告警不會被遺漏。

同時我們也會對報警內容進行精細化的定制，包含報警狀態(Problem 或者OK)、具體的問題、出現問題的服務器和 IP、問題具體的值等信息。

此外，我們還會在內容中補充該告警對應系統負責人姓名和聯系方式，方便我們 7x24 小時的 NOC 第一時間聯系到相應運維人員處理故障，降低故障時間。

在我們的監控大屏上，也會展現出當前每個系統狀態，并顯示出具體的問題有哪些，用紅色標示出 Disaster 級別報警，Warning 級別的則是黃色。

持續集成/持續交付

在前面的分享中提到了 Zabbix 提供了 API。基于 Zabbix 的 API，我們將其融入到了 DevOps 的持續交付流水線。

 

當持續集成平臺 Jenkins 從版本控制系統 Git 上拉去代碼進行構建后，通過 Ansible 等配置管理工具進行應用發布的同時，會調用 Zabbix API 將對應的主機放入維護模式，從而避免應用發布時的監控噪音。

同時 Zabbix 也會通過基礎信息的收集，為 CMDB 配置管理數據庫提供數據。當告警的時候調用微信、郵件等平臺的接口進行告警觸發。通過和其他平臺的集成，形成完整的持續交付閉環。

自動化帶外管理

當物理服務器數量大幅上升后，硬件巡檢問題是最燒腦的難題。硬件故障存在著隨機性。

 

大多數的組織內部通過定期人工巡檢的方式觀察硬件是否有故障。而一些組織會通過服務器自帶的帶外管理平臺，HP 的 iLo，華為的 iBMC 和戴爾的 iDrac 等平臺，進行帶外管理。

當一個機房里面有多種服務器的時候，如果只是依靠這些平臺，除了昂貴的 License 授權，管理成本也非常高昂。

即使這些問題解決了，那么那些只支持 SNMP 的網絡設備、存儲怎么辦呢?

來看看 Zabbix 是如何解決的：

• 我們將 Zabbix 部署在帶外管理網絡中，這個網絡會有一臺 DHCP 服務器自動為所有的設備分配 IP 地址。
• Zabbix 在這個帶外網絡中會有一臺 Proxy 代理服務器，通過 Zabbix 的自動發現功能，將所有的帶外地址增加到 Zabbix 中;通過 IPMI 或者 SNMP 的標準協議套用監控模版，實現統一監控。
• 收集到的帶外數據可以作為 CMDB 配置管理數據庫中重要的硬件信息。

通過 Zabbix 的帶外管理大大節約了帶外管理平臺的授權費用，也降低了帶外管理的成本，實現了統一帶外管理的目標。

以上就是 Zabbix 在落地過程中的案例和最佳實踐。

總結

如何選擇監控平臺

如果我們只是在 Prometheus 和 Zabbix 中選擇，應該如何選擇一個合適的監控平臺?

我的建議是：

 

• 當環境是一個純容器的環境，毫無疑問 Prometheus 是更適合的選擇，Prometheus 是天生為容器化平臺打造的監控系統。
• 而當我們環境很復雜，有各種操作系統、硬件、中間件、數據庫等，那么 Zabbix 是更適合的監控平臺，Zabbix 兼顧了監控的深度和廣度，實現了統一監控平臺的目的。
• 當整個環境中又有容器、又有其他的系統，而又希望之用一套監控系統，那么 Zabbix 更合適，因為 Zabbix 的最新版本中已經強化了容器化監控的功能。
• 當然，有余力的話，也可以使用兩臺監控系統互相補足。

使用 Zabbix 的收益

 

Zabbix 有簡單易用的 UI，自帶的 Graph 和 Screen 也可以滿足企業級的展現需求。

90% 以上的配置可以通過 Web 端統一操作和實現，這一點比強依賴于配置文件的 Prometheus 要更為方便。

當然，如果對于 Zabbix 的原生 UI 不滿意，仍然可以和 Prometheus 一樣，接入 Grafana，大大降低了二次開發的成本。

基于平臺組和業務組的雙維度分組，也使得 Zabbix 可以在同一組織內為不同團隊提供更個性化的展現。

Zabbix 的開源、免費等特性使得越來越多的企業，尤其是自研能力不是那么強的中小企業快速實現全棧級監控。

Zabbix 幾乎可以覆蓋 80% 甚至更多的監控需求，它的高級特性也大大減少了人工介入，提升了自動化能力，并可以其他系統和平臺進行持續集成。

目前 Zabbix 的社區非常活躍，擁有豐富的學習資源，大大降低了學習成本。

也歡迎大家積極反饋在使用 Zabbix 中碰到的問題或者改善建議給到我或者 Zabbix 社區，我們也希望通過不斷的迭代和優化使其成為更加優秀的監控平臺。

 

作者：蔡翔華

簡介：Zabbix 認證專家，國內首批 Zabbix 認證專家，DevOps Master。活躍于 Zabbix 和 DevOps 的社區，參加《DevOps 最佳實踐》和《Zabbix 官方手冊》的翻譯工作;10 年四大及銀行 IT 基礎架構經驗，7 年 Zabbix 和 DevOps 經驗。

編輯：陶家龍

出處：轉載自公眾號 DBAplus社群(ID：dbaplus)，本文根據蔡翔華老師在〖deeplus直播“運維監控談：Prometheus與Zabbix的對比選型”〗線上分享演講內容整理而成。