经常收到网友提问，监控系统选型，到底应该选择 Zabbix 还是 Prometheus？本文谈一下个人看法，希望对你有所启发。
核心要点
- Zabbix 和 Prometheus 的差异首先来自时代基因：Zabbix 更偏传统 IT 资产监控，Prometheus 更偏云原生和动态指标监控。
- 如果主要监控网络设备、服务器和数据库等相对静态资产，Zabbix 的模板、页面配置和设备监控经验仍然有优势。
- 如果主要面对微服务、Kubernetes、动态实例和云原生应用，Prometheus 生态更自然。
- Prometheus 不一定等于部署 Prometheus 进程，也可以是使用其 SDK、指标模型、Exporter、Remote Write、PromQL 和周边生态。
- 真正的长期重点不只是采集和存储，而是如何消费监控与可观测性数据，例如告警治理、故障定位和 AI 辅助分析。
选型速查表
| 场景 | 更推荐 | 原因 |
|---|---|---|
| 大量网络设备、传统服务器 | Zabbix | 模板、SNMP、设备监控实践更成熟 |
| Kubernetes、微服务、动态实例 | Prometheus 生态 | 自动发现、标签模型、Exporter 生态更匹配 |
| 想要 All-in-one 监控系统 | Zabbix | 采集、可视化、告警等能力集成度高 |
| 想要组件化可观测性架构 | Prometheus 生态 | Grafana、Exporter、远端存储、告警引擎可组合 |
| 多云、混合云、统一告警 | Prometheus 生态或商业统一平台 | 更适合跨环境指标标准化和上层消费 |
| 团队缺少云原生经验 | 视资产结构决定 | 传统资产多可先 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 等新技术的监控。
这并不意味着 Zabbix 不能监控云原生，也不意味着 Prometheus 不能监控网络设备。更准确的说法是：二者默认的建模方式、生态工具和社区实践，分别更适合不同类型的监控对象。
面向静态资产还是面向动态环境
2001 年那会，企业内部的服务器、网络设备都不会很多，要监控某个服务器或网络设备，就在 Zabbix 页面上把它添加进来就行了，添加的时候绑定模板（模板里包含采集规则、告警规则、预置图表等）、加入 Host Group 即可，非常丝滑。
Zabbix 这种方式可以概括为资产管理式，偏静态，而随着微服务、Kubernetes 体系的发展，IT 变得更加动态了。比如 Redis 部署在 Kubernetes 中，实例数量（随着扩缩容）和位置（由于驱逐、调度等）变化更加频繁，服务一旦重新发布，Pod 的名字就会发生变化，没法把 Pod 类似服务器或网络设备那样添加到监控系统中来静态管理。
所以 Prometheus 体系中，对各种监控对象的管理，主要是采用自动发现的方式来动态获取实例列表，然后做了约定，每个实例都要暴露 /metrics 端点（无法直接暴露的则通过 Exporter 间接暴露），这样一来，整个使用体验和 Zabbix 就截然不同了。
举例，如果你习惯了在 Zabbix 监控中添加监控目标然后就可以采集监控数据，那对于 Prometheus 这种根据发现规则自动发现的方式，就会很不适应。
这背后是两种对象管理方式的差异：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 狭义理解为一个单体服务。很多企业真实采用的是 Prometheus 指标模型和生态协议，再组合 vmagent、VictoriaMetrics、Thanos、Mimir、Grafana、Nightingale 或其他告警与可视化产品。
未来如何演进？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 管理，还是比较舒服的。
选型时可以问四个问题：
- 监控对象是静态资产为主，还是动态实例为主？
- 团队更熟悉页面配置、模板和资产管理，还是熟悉标签、PromQL 和自动发现？
- 是否需要和 Kubernetes、服务发现、云原生平台深度结合？
- 后续更关心采集告警本身，还是统一可观测性、故障定位和数据消费？
One more thing
除了注重工具本身，使用、规范、运营等也很关键，这是一个持续的过程，把工具安装上，只是万里长征第一步。
同样是 Zabbix，有些公司只发挥了其 30% 的能力，有些公司发挥了其 90% 的能力，有些公司只用了其 20% 的能力其中 10% 还没有遵照最佳实践，然后吐槽说这货真难用…
FAQ
Q1：新项目应该优先选 Zabbix 还是 Prometheus？ A：如果新项目主要是 Kubernetes、微服务和云原生应用，优先看 Prometheus 生态。如果主要是传统机房、网络设备和静态资产，Zabbix 仍然值得评估。
Q2：用了 VictoriaMetrics、Grafana、Nightingale，还算 Prometheus 生态吗？ A：算。只要遵循 Prometheus 指标模型、采集协议、PromQL 或 Remote Write 等生态玩法，即便没有部署 Prometheus 进程，也可以认为是在使用 Prometheus 生态。
Q3：网络设备监控一定要用 Zabbix 吗？ A：不一定，但 Zabbix 在网络设备模板、SNMP 实践和社区资料上更有积累。Prometheus 生态也能做，但对采集建模、容量和工程能力要求更高。
Q4：监控系统选型最容易忽视什么？ A：最容易忽视使用规范和持续运营。工具安装只是第一步，后续的指标规范、告警治理、仪表盘维护、事件分派和数据消费决定了监控系统实际价值。
近期文章
