經(jīng)常收到網(wǎng)友提問，監(jiān)控系統(tǒng)選型，到底應(yīng)該選擇 Zabbix 還是 Prometheus？本文談一下個人看法，希望對你有所啟發(fā)。

時代決定了基因

Zabbix 是 2001 年左右發(fā)布的，那個時代，微服務(wù)和 Kubernetes 都不盛行，Zabbix 更多的是關(guān)注網(wǎng)絡(luò)設(shè)備、服務(wù)器、數(shù)據(jù)庫等傳統(tǒng) IT 基礎(chǔ)設(shè)施的監(jiān)控。Zabbix 的創(chuàng)始人是銀行運(yùn)維出身，對于監(jiān)控相關(guān)的各類零碎需求了解的非常透徹。

Prometheus 是 2014 年發(fā)布的，相對年輕，依托于之前 Google Borgmon 的先進(jìn)經(jīng)驗(yàn)和靈感，Prometheus 在云原生監(jiān)控領(lǐng)域有著非常好的表現(xiàn)。Prometheus 的創(chuàng)始人是 SoundCloud 的工程師，之前就職于 Google，對 Google Borgmon 有深入的使用經(jīng)驗(yàn)。Borgmon 是什么？Borgmon 是 Borg 的監(jiān)控系統(tǒng)，Borg 是 Google 的集群管理系統(tǒng)，Kubernetes 就是 Borg 的開源版本。所以 Prometheus 的設(shè)計(jì)理念和 Borgmon 有很多相似之處。

所以，Zabbix 一開始就是更多服務(wù)于網(wǎng)絡(luò)設(shè)備、服務(wù)器的監(jiān)控，而 Prometheus 則更多服務(wù)于微服務(wù)、Kubernetes 等新技術(shù)的監(jiān)控。

面向靜態(tài)資產(chǎn)還是面向動態(tài)環(huán)境

2001 年那會，企業(yè)內(nèi)部的服務(wù)器、網(wǎng)絡(luò)設(shè)備都不會很多，要監(jiān)控某個服務(wù)器或網(wǎng)絡(luò)設(shè)備，就在 Zabbix 頁面上把它添加進(jìn)來就行了，添加的時候綁定模板（模板里包含采集規(guī)則、告警規(guī)則、預(yù)置圖表等）、加入 Host Group 即可，非常絲滑。

Zabbix 這種方式可以概括為資產(chǎn)管理式，偏靜態(tài)，而隨著微服務(wù)、Kubernetes 體系的發(fā)展，IT 變得更加動態(tài)了。比如 Redis 部署在 Kubernetes 中，實(shí)例數(shù)量（隨著擴(kuò)縮容）和位置（由于驅(qū)逐、調(diào)度等）變化更加頻繁，服務(wù)一旦重新發(fā)布，Pod 的名字就會發(fā)生變化，沒法把 Pod 類似服務(wù)器或網(wǎng)絡(luò)設(shè)備那樣添加到監(jiān)控系統(tǒng)中來靜態(tài)管理。

所以 Prometheus 體系中，對各種監(jiān)控對象的管理，主要是采用自動發(fā)現(xiàn)的方式來動態(tài)獲取實(shí)例列表，然后做了約定，每個實(shí)例都要暴露 /metrics 端點(diǎn)（無法直接暴露的則通過 Exporter 間接暴露），這樣一來，整個使用體驗(yàn)和 Zabbix 就截然不同了。

舉例，如果你習(xí)慣了在 Zabbix 監(jiān)控中添加監(jiān)控目標(biāo)然后就可以采集監(jiān)控?cái)?shù)據(jù)，那對于 Prometheus 這種根據(jù)發(fā)現(xiàn)規(guī)則自動發(fā)現(xiàn)的方式，就會很不適應(yīng)。

產(chǎn)品集成度

Zabbix 開始的時代，社區(qū)生態(tài)比較薄弱，Zabbix 是 All-in-one 的玩法，即你就只需要部署一套 Zabbix，數(shù)據(jù)采集、可視化、告警等，我全部給你搞定，雖然某些方面做得不出彩，但是它有，它是一個大而全的方案。發(fā)展了這么多年，Zabbix 產(chǎn)品自身完成度很高。

Prometheus 發(fā)展的年代，人們對大型軟件的分層、協(xié)同相關(guān)的認(rèn)知提升了很多，而且社區(qū)里有很多其他的完備的產(chǎn)品，所以 Prometheus 體系的設(shè)計(jì)和 Zabbix 截然不同，比如可視化，Prometheus 自身就做得比較弱，主要是交給 Grafana 來處理，而采集，Prometheus 體系也是百花齊放，有各種的 Exporter，告警是自己搞的，開發(fā)了 Alertmanager，不過側(cè)重在告警事件的處理（抑制、屏蔽、分組），在告警事件分發(fā)層面，還是需要 PagerDuty、FlashDuty 這樣的產(chǎn)品來協(xié)同體驗(yàn)方為最佳。

Zabbix 未來的演進(jìn)

Zabbix 也在持續(xù)想要增強(qiáng)自身對 Kubernetes、微服務(wù)的監(jiān)控能力，但是社區(qū)顯然并不買賬，絕大部分用戶仍然使用 Prometheus 生態(tài)來做 Kubernetes、微服務(wù)的監(jiān)控。

Zabbix 的強(qiáng)項(xiàng)還是在服務(wù)器和網(wǎng)絡(luò)設(shè)備的監(jiān)控，尤其是網(wǎng)絡(luò)設(shè)備方面，Zabbix 的采集性能、模板豐富性、社區(qū)實(shí)踐資料等，都遠(yuǎn)超 Prometheus 生態(tài)。

嘗試站在 Zabbix 的角度來思考未來的發(fā)展，我感覺要擴(kuò)大能力范圍還是很難的，當(dāng)然，Alexei Vladishev 可能有更多想法，咱們是咸吃蘿卜淡操心了。

Prometheus 生態(tài)的演進(jìn)

在講 Prometheus 的時候，通常我都不是說 Prometheus 本身，而是說 Prometheus 生態(tài)，因?yàn)槟闶欠袷褂?Prometheus 進(jìn)程本身都不一定，舉例：

• Exporter：Prometheus 自身提供了幾個 Exporter，更多大量的 Exporter 都是社區(qū)提供的，甚至還有 Alloy、Cprobe、OTel-Collector 這類想要把 Exporter 整合到一起的項(xiàng)目
• Puller：拉取器，Prometheus 自身就提供了 Scrape 的能力，但是你有更多選擇，比如使用 Telegraf、Categraf、vmagent
• TSDB：首推 VictoriaMetrics，已經(jīng)不建議使用 Prometheus 做時序數(shù)據(jù)存儲了，VictoriaMetrics 和 Prometheus 接口兼容、性能更好、支持集群模式，當(dāng)然，還有 Thanos、M3、Mimir 等更多選擇
• 告警引擎：Prometheus 自身集成了告警引擎，但如果你不是用的 Prometheus 做 TSDB，那你的告警引擎大概率會選擇別的，比如 vmalert，或者 Nightingale

Prometheus 生態(tài)里，每個細(xì)分方面都有替代項(xiàng)目，所以有些公司說是用了 Prometheus，其實(shí)它連 Prometheus 進(jìn)程都沒有部署，可能只是用了 Prometheus 的 SDK。這種情況，我們?nèi)匀恢v他確實(shí)是用的 Prometheus 生態(tài)，因?yàn)樗€是遵照了這個生態(tài)的玩法。

未來如何演進(jìn)？Prometheus 采集側(cè)會被 OpenTelemetry 替換掉，存儲側(cè)會被 VictoriaMetrics 替換掉么？是有可能的，但顯然沒法準(zhǔn)確預(yù)測。對于實(shí)踐來講，筆者認(rèn)為：

• Prometheus 的體系已經(jīng)很成熟，長期來看，即便風(fēng)頭被搶，對企業(yè)而言，繼續(xù)使用 Prometheus 也沒有任何問題
• 如果是新項(xiàng)目，存儲方面當(dāng)然還是建議選用 VictoriaMetrics，YYDS
• 采集層面，新項(xiàng)目要用 OpenTelemetry 么？其實(shí)我感覺必要性沒有太高，可以等 OpenTelemetry 再成熟一些再做考慮，當(dāng)然，你們公司有 OpenTelemetry 兜底能力自然是 OK 的。

數(shù)據(jù)的場景化消費(fèi)是重點(diǎn)

開源社區(qū)的項(xiàng)目要想成功，卡位是極為關(guān)鍵的，把一個細(xì)分方向做好做透，是最容易成功的。Zabbix 卡位是設(shè)備監(jiān)控、Prometheus 卡位是動態(tài)指標(biāo)監(jiān)控。

但是行業(yè)的熱點(diǎn)，已經(jīng)不是數(shù)據(jù)底座了，而是如何用好這些數(shù)據(jù)，尤其是通過 AI 的能力如何用好這些數(shù)據(jù)。畢竟，采集數(shù)據(jù)、數(shù)據(jù)傳輸、數(shù)據(jù)ETL都是臟活累活，而且已經(jīng)有這么多巨頭項(xiàng)目了。

國外的話，有個公司很值得關(guān)注，叫 causely，國內(nèi)的話就是 flashcat，大家都希望把各類可觀測性數(shù)據(jù)做好串聯(lián)，在上層做故障定位，因?yàn)榧铀俟收隙ㄎ皇潜O(jiān)控、可觀測性數(shù)據(jù)最大的消費(fèi)場景。

如何選型

如果你們公司沒有大量的網(wǎng)絡(luò)設(shè)備，我感覺選擇 Zabbix 的意義不大。Zabbix 是上一個時代的王者，新時代的王者就是 Prometheus，毫無疑問。尤其是你還要考慮職業(yè)規(guī)劃問題，對 Prometheus 更熟悉的話感覺找工作會有幫助。

如果你們真的有很多網(wǎng)絡(luò)設(shè)備，也不見得就不能用 Prometheus，只是需要你這塊的知識儲備，比如 Zenlayer，全球這么多網(wǎng)絡(luò)設(shè)備，就是從 Zabbix 遷移到了 Flashcat（可以理解為是 Prometheus 的商業(yè)產(chǎn)品），他們是因?yàn)榫W(wǎng)絡(luò)設(shè)備太多了，管理復(fù)雜度較高，有較高的容量需求，一般來說，幾百臺或者上千臺網(wǎng)絡(luò)設(shè)備用 Zabbix 管理，還是比較舒服的。

One more thing

除了注重工具本身，使用、規(guī)范、運(yùn)營等也很關(guān)鍵，這是一個持續(xù)的過程，把工具安裝上，只是萬里長征第一步。

同樣是 Zabbix，有些公司只發(fā)揮了其 30% 的能力，有些公司發(fā)揮了其 90% 的能力，有些公司只用了其 20% 的能力其中 10% 還沒有遵照最佳實(shí)踐，然后吐槽說這貨真難用...

近期文章

• NetFlix SRE 實(shí)踐
• 大模型在小米運(yùn)維體系的探索與演進(jìn) | PPT
• 引入 AI 分析故障，F(xiàn)lashduty 又進(jìn)步了
• 可觀測性體系建設(shè)的五步心法
• 十年磨一劍，運(yùn)維監(jiān)控、可觀測性領(lǐng)域創(chuàng)業(yè)，拼的是產(chǎn)品細(xì)節(jié)和交付迭代能力
• 首席工程師教我的 10 個經(jīng)驗(yàn)
• Kafka 不難，只是你用得不對
• 從 1 到 100 萬用戶：我真希望早點(diǎn)知道的架構(gòu)
• 做開源商業(yè)化創(chuàng)業(yè)3年，一點(diǎn)小感悟