新公司要上監(jiān)控，面試提到了Prometheus是公司需要的監(jiān)控解決方案，作為喜新厭舊的程序員，我當然是選擇跟風了，之前主要做的是Zabbix，既然公司需要Prometheus，那沒辦法，只能好好對比一番，了解下，畢竟技多不壓身，但稍稍深入一點，我就體會到了Prometheus 的優(yōu)點，總結(jié)一下這兩種監(jiān)控方式。

Prometheus

Kubernetes自從2012年開源以來便以不可阻擋之勢成為容器領域調(diào)度和編排的領頭羊，Kubernetes是Google Borg系統(tǒng)的開源實現(xiàn)，于此對應Prometheus則是Google BorgMon的開源實現(xiàn)。Prometheus是由SoundCloud開發(fā)的開源監(jiān)控報警系統(tǒng)和時序列數(shù)據(jù)庫。從字面上理解，Prometheus由兩個部分組成，一個是監(jiān)控報警系統(tǒng)，另一個是自帶的時序數(shù)據(jù)庫（TSDB）。2016年，由Google發(fā)起的Linux基金會旗下的原生云基金會（Cloud Native Computing Foundation）將Prometheus納入其第二大開源項目。Prometheus在開源社區(qū)也十分活躍，在GitHub上擁有兩萬多Star，并且系統(tǒng)每隔一兩周就會有一個小版本的更新，而Prometheus與它的“師兄”Kubernetes都自帶云原生的光環(huán)，天然能夠友好協(xié)作。

Zabbix

Zabbix官方的發(fā)行版本時間可以追朔到2012年，時間上比Prometheus早了四年，Zabbix是由Alexei Vladishev開源的分布式監(jiān)控系統(tǒng)，是一個企業(yè)級的分布式開源監(jiān)控方案。能夠監(jiān)控各種網(wǎng)絡參數(shù)以及服務器健康性和完整性的軟件。使用靈活的通知機制，允許用戶為幾乎任何事件配置基于郵件的告警。這樣可以快速反饋服務器的問題?；谝汛鎯Φ臄?shù)據(jù)，提供了出色的報告和數(shù)據(jù)可視化功能。

架構(gòu)對比

Prometheus

Prometheus的基本原理是通過HTTP周期性抓取被監(jiān)控組件的狀態(tài)，任意組件只要提供對應的HTTP接口并且符合Prometheus定義的數(shù)據(jù)格式，就可以接入Prometheus監(jiān)控。

Prometheus Server負責定時在目標上抓取Metrics（指標）數(shù)據(jù)并保存到本地存儲里面。Prometheus采用了一種Pull（拉）的方式獲取數(shù)據(jù)，不僅降低客戶端的復雜度，客戶端只需要采集數(shù)據(jù)，無需了解服務端情況，而且服務端可以更加方便的水平擴展。

如果監(jiān)控數(shù)據(jù)達到告警閾值Prometheus Server會通過HTTP將告警發(fā)送到告警模塊alertmanger，通過告警的抑制后觸發(fā)郵件或者webhook。Prometheus支持PromQL提供多維度數(shù)據(jù)模型和靈活的查詢，通過監(jiān)控指標關聯(lián)多個tag的方式，將監(jiān)控數(shù)據(jù)進行任意維度的組合以及聚合。

Zabbix

Zabbix由2部分構(gòu)成，Zabbix Server與可選組件Zabbix Agent。Zabbix Server可以通過SNMP，Zabbix Agent，ping，端口監(jiān)視等方法提供對遠程服務器/網(wǎng)絡狀態(tài)的監(jiān)視，數(shù)據(jù)收集等功能，它可以運行在Linux，Solaris，HP-UX，AIX，F(xiàn)ree BSD，Open BSD，OS X等平臺上。

核心組件主要是Agent和Server，其中Agent主要負責采集數(shù)據(jù)并通過主動或者被動的方式采集數(shù)據(jù)發(fā)送到Server/Proxy，除此之外，為了擴展監(jiān)控項，Agent還支持執(zhí)行自定義腳本。Server主要負責接收Agent發(fā)送的監(jiān)控信息，并進行匯總存儲，觸發(fā)告警等。Zabbix Server將收集的監(jiān)控數(shù)據(jù)存儲到Zabbix Database中。Zabbix Database支持常用的關系型數(shù)據(jù)庫，如果MySQL、PostgreSQL、Oracle等，默認是MySQL，并提供Zabbix Web頁面（PHP編寫）數(shù)據(jù)查詢。

Zabbix由于使用了關系型數(shù)據(jù)存儲時序數(shù)據(jù)，所以在監(jiān)控大規(guī)模集群時常常在數(shù)據(jù)存儲方面捉襟見肘。所以從Zabbix 4.2版本后開始支持TimescaleDB時序數(shù)據(jù)庫，不過目前成熟度還不高。

綜合對比

綜合比對

如上面的表格，從開發(fā)語言上看，為了應對高并發(fā)和快速迭代的需求，監(jiān)控系統(tǒng)的開發(fā)語言已經(jīng)慢慢從C語言轉(zhuǎn)移到Go。不得不說，Go憑借簡潔的語法和優(yōu)雅的并發(fā)，在Java占據(jù)業(yè)務開發(fā)，C占領底層開發(fā)的情況下，準確定位中間件開發(fā)需求，在當前開源中間件產(chǎn)品中被廣泛應用。從系統(tǒng)成熟度上看，Zabbix是老牌的監(jiān)控系統(tǒng)：Zabbix是在1998年就出現(xiàn)的，系統(tǒng)功能比較穩(wěn)定，成熟度較高。而Prometheus是最近幾年才誕生的，雖然功能還在不斷迭代更新，但站在巨人的肩膀之上，在架構(gòu)設計上借鑒了很多老牌監(jiān)控系統(tǒng)的經(jīng)驗；從數(shù)據(jù)存儲方面來看，Zabbix采用關系數(shù)據(jù)庫保存，這極大限制了Zabbix采集的性能，而Prometheus自研一套高性能的時序數(shù)據(jù)庫，在V3版本可以達到每秒千萬級別的數(shù)據(jù)存儲，通過對接第三方時序數(shù)據(jù)庫擴展歷史數(shù)據(jù)的存儲；從配置復雜度上看，Prometheus只有一個核心server組件，一條命令便可以啟動，相比而言，其他系統(tǒng)配置相對麻煩，從社區(qū)活躍度上看，目前Zabbix比較活躍，但基本都是國內(nèi)的公司參與，Prometheus在這方面占據(jù)絕對優(yōu)勢，社區(qū)活躍度雖然不如，但是受到CNCF的支持，后期的發(fā)展值得期待；從容器支持角度看，由于Zabbix出現(xiàn)得比較早，當時容器還沒有誕生，自然對容器的支持也比較差。而Prometheus的動態(tài)發(fā)現(xiàn)機制，不僅可以支持Swarm原生集群，還支持Kubernetes容器集群的監(jiān)控，是目前容器監(jiān)控最好解決方案。

總結(jié)

綜合來看，Zabbix 的成熟度更高，上手更快，但更好的集成導致靈活性較差，問題更大是，監(jiān)控數(shù)據(jù)的復雜度增加后，Zabbix 做進一步定制難度很高，即使做好了定制，也沒法利用之前收集到的數(shù)據(jù)了（關系型數(shù)據(jù)庫造成的問題）。Prometheus 基本上是正相反，上手難度大一些，但由于定制靈活度高，數(shù)據(jù)也有更多的聚合可能，起步后的使用難度遠小于 Zabbix。但如果已經(jīng)對傳統(tǒng)監(jiān)控系統(tǒng)有技術(shù)積累的話，還是要謹慎考慮更換監(jiān)控。

結(jié)論

如果監(jiān)控的是物理機，用Zabbix沒毛病，Zabbix在傳統(tǒng)監(jiān)控系統(tǒng)中，尤其是在服務器相關監(jiān)控方面，占據(jù)絕對優(yōu)勢。甚至環(huán)境變動不會很頻繁的情況下，Zabbix也會比Prometheus好使；但如果是云環(huán)境的話，除非是Zabbix玩的非常溜，可以做各種定制，否則還是Prometheus吧，畢竟人家就是干這個的。Prometheus開始成為主導及容器監(jiān)控方面的標配，并且在未來可見的時間內(nèi)被廣泛應用。如果是剛剛要上監(jiān)控系統(tǒng)的話，不用猶豫了，Prometheus準沒錯。

原文鏈接：https://www.cnblogs.com/xiaoyuxixi/p/12235979.html