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

[[347265]]

圖片來自 Pexels

 

Zabbix 適合的監(jiān)控場景

監(jiān)控的維度

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

①監(jiān)控的廣度

 

大家所需要監(jiān)控的系統(tǒng)少則幾種，多則幾十種，比如需要監(jiān)控硬件、存儲、操作系統(tǒng)、中間件、數(shù)據(jù)庫及應用等。

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

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

綜上，一個理想的監(jiān)控平臺應該支持基于各類系統(tǒng)，覆蓋各類廠商和平臺的監(jiān)控。

②監(jiān)控的深度

 

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

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

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

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

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

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

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

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

監(jiān)控選型

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

 

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

不過，通常情況下我們的環(huán)境中還充滿了網(wǎng)絡設備、Linux、存儲等其他監(jiān)控對象。

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

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

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

①UI 方面

Zabbix 5.0 界面如下圖：

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

 

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

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

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

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

Prometheus界面如下圖：

 

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

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

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

②架構方面

Zabbix 架構圖如下：

Zabbix 是一個分布式的監(jiān)控系統(tǒng)。在很多公司內(nèi)部，尤其是金融機構，會存在多個網(wǎng)絡區(qū)域，每個區(qū)域之間進行了隔離。

 

Zabbix 支持在每個網(wǎng)絡區(qū)域內(nèi)部署一個 Zabbix Proxy，即 Zabbix 的代理服務器，這個服務器的職責是收集當前區(qū)域的監(jiān)控對象的監(jiān)控數(shù)據(jù)。

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

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

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

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

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

Prometheus 架構圖如下：

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

 

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

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

TSDB 在存儲監(jiān)控的性能會優(yōu)于傳統(tǒng)關系型數(shù)據(jù)庫，因此 Zabbix 也開始嘗試性的支持 TSDB 作為后端的數(shù)據(jù)存儲。

在監(jiān)控平臺的選型時，也需要評估數(shù)據(jù)庫是否是監(jiān)控的瓶頸，當性能和壓力尚不能成為監(jiān)控平臺的瓶頸時，TSDB 時序數(shù)據(jù)庫的優(yōu)勢并不會十分明顯。

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

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

③Zabbix 的高級特性

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

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

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

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

低級別發(fā)現(xiàn)，自動發(fā)現(xiàn)：這是 Zabbix 全棧自動化監(jiān)控中最不可或缺的兩個特性。

低級別發(fā)現(xiàn)：低級別發(fā)現(xiàn)能幫助我們發(fā)現(xiàn)一臺設備上所有的監(jiān)控對象。

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

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

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

不止于此，還要繼續(xù)為這 10000 個監(jiān)控項配置觸發(fā)器和告警規(guī)則。

而在 Zabbix 中，我們只需創(chuàng)建一個模版，定義低級別發(fā)現(xiàn)的規(guī)則，并將這個模版同這 100 臺需要監(jiān)控的服務器關聯(lián)即可。

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

自動發(fā)現(xiàn)：它能幫助我們快速發(fā)現(xiàn)網(wǎng)絡內(nèi)的設備，并按規(guī)則識別出它的類型，將其和指定的模版進行關聯(lián)。

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

從底層的硬件、操作系統(tǒng)、中間件、數(shù)據(jù)庫，到上層的應用、業(yè)務，都可以納入到 Zabbix 的監(jiān)控范圍中。

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

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

Zabbix 全棧自動化監(jiān)控實踐案例

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

分布式自動化監(jiān)控

 

首先來看下我們是如何通過自動發(fā)現(xiàn)特性實現(xiàn)監(jiān)控的自動添加的：

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

因此，我們通過已經(jīng)配置好的規(guī)則，將發(fā)現(xiàn)的這個開放著 1433 端口的 IP 和 SQLServer 模版進行關聯(lián)。

SQLServer 的模版是我們預先定制好的對于微軟數(shù)據(jù)庫的監(jiān)控模版，通過自動發(fā)現(xiàn)，我們能達到兩個目的：

• 所有的微軟數(shù)據(jù)庫都被監(jiān)控到了。
• 所有被監(jiān)控的數(shù)據(jù)庫使用了同一套監(jiān)控基線，實現(xiàn)了標準化監(jiān)控。

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

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

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

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

 

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

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

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

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

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

這樣做的收益在于 DBA 只會收到他們所負責系統(tǒng)的告警，同時監(jiān)控也實現(xiàn)了標準化。

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

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

這樣做的好處在于，一旦一個監(jiān)控對象出現(xiàn)任何問題，我們可以第一時間知道它影響什么系統(tǒng)。

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

告警方式

 

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

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

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

• Disaster：觸發(fā)后需要立即處理，如不處理會直接影響生產(chǎn)系統(tǒng)的告警。
• Warning：觸發(fā)后需要盡快處理，短期不處理不會直接影響生產(chǎn)系統(tǒng)。
• Info：提示性的告警。

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

具體的告警分級和策略可以根據(jù)企業(yè)內(nèi)部的實際情況和監(jiān)控需求進行定制。

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

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

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

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

持續(xù)集成/持續(xù)交付

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

 

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

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

自動化帶外管理

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

 

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

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

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

來看看 Zabbix 是如何解決的：

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

通過 Zabbix 的帶外管理大大節(jié)約了帶外管理平臺的授權費用，也降低了帶外管理的成本，實現(xiàn)了統(tǒng)一帶外管理的目標。

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

總結

如何選擇監(jiān)控平臺

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

我的建議是：

 

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

使用 Zabbix 的收益

 

Zabbix 有簡單易用的 UI，自帶的 Graph 和 Screen 也可以滿足企業(yè)級的展現(xiàn)需求。

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

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

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

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

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

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

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

 

作者：蔡翔華

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

編輯：陶家龍

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