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

[[347265]]

圖片來自 Pexels

 

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

監(jiān)控的維度

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

①監(jiān)控的廣度

 

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

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

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

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

②監(jiān)控的深度

 

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

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

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

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

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

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

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

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

監(jiān)控選型

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

 

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

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

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

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

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

①UI 方面

Zabbix 5.0 界面如下圖：

Zabbix 一直被吐槽的最多的一點(diǎn)就是它的 UI。

 

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

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

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

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

Prometheus界面如下圖：

 

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

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

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

②架構(gòu)方面

Zabbix 架構(gòu)圖如下：

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

 

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

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

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

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

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

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

Prometheus 架構(gòu)圖如下：

總體而言，Prometheus 的架構(gòu)和 Zabbix 有很多相似之處：

 

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

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

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

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

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

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

③Zabbix 的高級特性

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Zabbix 全棧自動(dòng)化監(jiān)控實(shí)踐案例

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

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

 

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

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

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

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

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

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

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

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

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

 

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

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

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

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

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

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

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

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

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

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

告警方式

 

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

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

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

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

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

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

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

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

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

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

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

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

 

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

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

自動(dòng)化帶外管理

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

 

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

當(dāng)一個(gè)機(jī)房里面有多種服務(wù)器的時(shí)候，如果只是依靠這些平臺，除了昂貴的 License 授權(quán)，管理成本也非常高昂。

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

來看看 Zabbix 是如何解決的：

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

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

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

總結(jié)

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

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

我的建議是：

 

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

使用 Zabbix 的收益

 

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

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

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

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

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

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

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

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

 

作者：蔡翔華

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

編輯：陶家龍

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