prometheus和zabbix的對比

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

一、兩種監控工具的歷史簡介：

prometheus：

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

zabbix：

　　zabbix官方的發行版本時間可以追朔到2012年，時間上比prometheus早了四年，Zabbix是由Alexei Vladishev開源的分布式監控系統，是一個企業級的分布式開源監控方案。能夠監控各種網絡參數以及服務器健康性和完整性的軟件。使用靈活的通知機制，允許用戶為幾乎任何事件配置基於郵件的告警。這樣可以快速反饋服務器的問題。基於已存儲的數據，提供了出色的報告和數據可視化功能。

 

二、架構對比：

Prometheus：

 

 

　　Prometheus的基本原理是通過HTTP周期性抓取被監控組件的狀態，任意組件只要提供對應的HTTP接口並且符合Prometheus定義的數據格式，就可以接入Prometheus監控。

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

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

Zabbix：

 

　　zabbix由2部分構成，zabbix server與可選組件zabbix agent。zabbix server可以通過SNMP，zabbix agent，ping，端口監視等方法提供對遠程服務器/網絡狀態的監視，數據收集等功能，它可以運行在Linux，Solaris，HP-UX，AIX，Free BSD，Open BSD，OS X等平台上。

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

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

三、綜合對比：

 

綜合比對：

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

總結：

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

結論：

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