經常收到網友提問，監控系統選型，到底應該選擇 Zabbix 還是 Prometheus？本文談一下個人看法，希望對你有所啓發。

時代決定了基因

Zabbix 是 2001 年左右發佈的，那個時代，微服務和 Kubernetes 都不盛行，Zabbix 更多的是關注網絡設備、服務器、數據庫等傳統 IT 基礎設施的監控。Zabbix 的創始人是銀行運維出身，對於監控相關的各類零碎需求瞭解的非常透徹。

Prometheus 是 2014 年發佈的，相對年輕，依託於之前 Google Borgmon 的先進經驗和靈感，Prometheus 在雲原生監控領域有着非常好的表現。Prometheus 的創始人是 SoundCloud 的工程師，之前就職於 Google，對 Google Borgmon 有深入的使用經驗。Borgmon 是什麼？Borgmon 是 Borg 的監控系統，Borg 是 Google 的集羣管理系統，Kubernetes 就是 Borg 的開源版本。所以 Prometheus 的設計理念和 Borgmon 有很多相似之處。

所以，Zabbix 一開始就是更多服務於網絡設備、服務器的監控，而 Prometheus 則更多服務於微服務、Kubernetes 等新技術的監控。

面向靜態資產還是面向動態環境

2001 年那會，企業內部的服務器、網絡設備都不會很多，要監控某個服務器或網絡設備，就在 Zabbix 頁面上把它添加進來就行了，添加的時候綁定模板（模板裏包含採集規則、告警規則、預置圖表等）、加入 Host Group 即可，非常絲滑。

Zabbix 這種方式可以概括為資產管理式，偏靜態，而隨着微服務、Kubernetes 體系的發展，IT 變得更加動態了。比如 Redis 部署在 Kubernetes 中，實例數量（隨着擴縮容）和位置（由於驅逐、調度等）變化更加頻繁，服務一旦重新發布，Pod 的名字就會發生變化，沒法把 Pod 類似服務器或網絡設備那樣添加到監控系統中來靜態管理。

所以 Prometheus 體系中，對各種監控對象的管理，主要是採用自動發現的方式來動態獲取實例列表，然後做了約定，每個實例都要暴露 /metrics 端點（無法直接暴露的則通過 Exporter 間接暴露），這樣一來，整個使用體驗和 Zabbix 就截然不同了。

舉例，如果你習慣了在 Zabbix 監控中添加監控目標然後就可以採集監控數據，那對於 Prometheus 這種根據發現規則自動發現的方式，就會很不適應。

產品集成度

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

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

Zabbix 未來的演進

Zabbix 也在持續想要增強自身對 Kubernetes、微服務的監控能力，但是社區顯然並不買賬，絕大部分用户仍然使用 Prometheus 生態來做 Kubernetes、微服務的監控。

Zabbix 的強項還是在服務器和網絡設備的監控，尤其是網絡設備方面，Zabbix 的採集性能、模板豐富性、社區實踐資料等，都遠超 Prometheus 生態。

嘗試站在 Zabbix 的角度來思考未來的發展，我感覺要擴大能力範圍還是很難的，當然，Alexei Vladishev 可能有更多想法，咱們是鹹吃蘿蔔淡操心了。

Prometheus 生態的演進

在講 Prometheus 的時候，通常我都不是説 Prometheus 本身，而是説 Prometheus 生態，因為你是否使用 Prometheus 進程本身都不一定，舉例：

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

Prometheus 生態裏，每個細分方面都有替代項目，所以有些公司説是用了 Prometheus，其實它連 Prometheus 進程都沒有部署，可能只是用了 Prometheus 的 SDK。這種情況，我們仍然講他確實是用的 Prometheus 生態，因為他還是遵照了這個生態的玩法。

未來如何演進？Prometheus 採集側會被 OpenTelemetry 替換掉，存儲側會被 VictoriaMetrics 替換掉麼？是有可能的，但顯然沒法準確預測。對於實踐來講，筆者認為：

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

數據的場景化消費是重點

開源社區的項目要想成功，卡位是極為關鍵的，把一個細分方向做好做透，是最容易成功的。Zabbix 卡位是設備監控、Prometheus 卡位是動態指標監控。

但是行業的熱點，已經不是數據底座了，而是如何用好這些數據，尤其是通過 AI 的能力如何用好這些數據。畢竟，採集數據、數據傳輸、數據ETL都是髒活累活，而且已經有這麼多巨頭項目了。

國外的話，有個公司很值得關注，叫 causely，國內的話就是 flashcat，大家都希望把各類可觀測性數據做好串聯，在上層做故障定位，因為加速故障定位是監控、可觀測性數據最大的消費場景。

如何選型

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

如果你們真的有很多網絡設備，也不見得就不能用 Prometheus，只是需要你這塊的知識儲備，比如 Zenlayer，全球這麼多網絡設備，就是從 Zabbix 遷移到了 Flashcat（可以理解為是 Prometheus 的商業產品），他們是因為網絡設備太多了，管理複雜度較高，有較高的容量需求，一般來説，幾百台或者上千台網絡設備用 Zabbix 管理，還是比較舒服的。

One more thing

除了注重工具本身，使用、規範、運營等也很關鍵，這是一個持續的過程，把工具安裝上，只是萬里長征第一步。

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

近期文章

• NetFlix SRE 實踐
• 大模型在小米運維體系的探索與演進 | PPT
• 引入 AI 分析故障，Flashduty 又進步了
• 可觀測性體系建設的五步心法
• 十年磨一劍，運維監控、可觀測性領域創業，拼的是產品細節和交付迭代能力
• 首席工程師教我的 10 個經驗
• Kafka 不難，只是你用得不對
• 從 1 到 100 萬用户：我真希望早點知道的架構
• 做開源商業化創業3年，一點小感悟