一、兩種監控工具的歷史簡介：
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 準沒錯。