新公司要上監(jiān)控，面試提到了 Prometheus 是公司需要的監(jiān)控解決方案，我當然是選擇跟風了。

之前主要做的是 Zabbix，既然公司需要 Prometheus，那沒辦法，只能好好對比一番，了解下，畢竟技多不壓身。

但稍稍深入一點，我就體會到了 Prometheus 的優(yōu)點，總結一下這兩種監(jiān)控方式。

兩種監(jiān)控工具的歷史簡介

Prometheus

Kubernetes 自從 2012 年開源以來便以不可阻擋之勢成為容器領域調度和編排的領頭羊。

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)控各種網絡參數(shù)以及服務器健康性和完整性的軟件。使用靈活的通知機制，允許用戶為幾乎任何事件配置基于郵件的告警。

這樣可以快速反饋服務器的問題。基于已存儲的數(shù)據(jù)，提供了出色的報告和數(shù)據(jù)可視化功能。

架構對比

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 部分構成，Zabbix Server 與可選組件 Zabbix Agent。Zabbix Server 可以通過 SNMP，Zabbix Agent，ping，端口監(jiān)視等方法提供對遠程服務器/網絡狀態(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ā)語言已經慢慢從 C 語言轉移到 Go。

不得不說，Go 憑借簡潔的語法和優(yōu)雅的并發(fā)，在 Java 占據(jù)業(yè)務開發(fā)，C 占領底層開發(fā)的情況下，準確定位中間件開發(fā)需求，在當前開源中間件產品中被廣泛應用。

從系統(tǒng)成熟度上看，Zabbix 是老牌的監(jiān)控系統(tǒng)：Zabbix 是在 1998 年就出現(xiàn)的，系統(tǒng)功能比較穩(wěn)定，成熟度較高。

而 Prometheus 是最近幾年才誕生的，雖然功能還在不斷迭代更新，但站在巨人的肩膀之上，在架構設計上借鑒了很多老牌監(jiān)控系統(tǒng)的經驗。

從數(shù)據(jù)存儲方面來看，Zabbix 采用關系數(shù)據(jù)庫保存，這極大限制了 Zabbix 采集的性能，而 Prometheus 自研一套高性能的時序數(shù)據(jù)庫，在 V3 版本可以達到每秒千萬級別的數(shù)據(jù)存儲，通過對接第三方時序數(shù)據(jù)庫擴展歷史數(shù)據(jù)的存儲。

從配置復雜度上看，Prometheus 只有一個核心 server 組件，一條命令便可以啟動，相比而言，其他系統(tǒng)配置相對麻煩。

從社區(qū)活躍度上看，目前 Zabbix 比較活躍，但基本都是國內的公司參與，Prometheus 在這方面占據(jù)絕對優(yōu)勢，社區(qū)活躍度雖然不如，但是受到 CNCF 的支持，后期的發(fā)展值得期待。

從容器支持角度看，由于 Zabbix 出現(xiàn)得比較早，當時容器還沒有誕生，自然對容器的支持也比較差。

而 Prometheus 的動態(tài)發(fā)現(xiàn)機制，不僅可以支持 Swarm 原生集群，還支持 Kubernetes 容器集群的監(jiān)控，是目前容器監(jiān)控最好解決方案。

總結

綜合來看，Zabbix 的成熟度更高，上手更快，但更好的集成導致靈活性較差，問題更大是，監(jiān)控數(shù)據(jù)的復雜度增加后，Zabbix 做進一步定制難度很高，即使做好了定制，也沒法利用之前收集到的數(shù)據(jù)了（關系型數(shù)據(jù)庫造成的問題）。

Prometheus 基本上是正相反，上手難度大一些，但由于定制靈活度高，數(shù)據(jù)也有更多的聚合可能，起步后的使用難度遠小于 Zabbix。

但如果已經對傳統(tǒng)監(jiān)控系統(tǒng)有技術積累的話，還是要謹慎考慮更換監(jiān)控。

如果監(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)控方面的標配，并且在未來可見的時間內被廣泛應用。

如果是剛剛要上監(jiān)控系統(tǒng)的話，不用猶豫了，Prometheus 準沒錯。

編輯：黃飛

?