[[426470]]

圖片來自 包圖網(wǎng)

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

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

兩種監(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ù)可視化功能。

架構對比

①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 由兩部分構成，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 語言轉移到 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 是最近幾年才誕生的，雖然功能還在不斷迭代更新，但站在巨人的肩膀之上，在架構設計上借鑒了很多老牌監(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)控最好解決方案。

總結

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

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

但如果已經(jīng)對傳統(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)控方面的標配，并且在未來可見的時間內(nèi)被廣泛應用。

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

作者：小雨淅淅o0

編輯：陶家龍

出處：cnblogs.com/xiaoyuxixi/p/12235979.html