Zabbix 被淘汰了吗

Zabbix 是一个历史悠久的开源监控系统，从 2001 年开始发展，到现在已经有 20 多年。在这 20 多年里，Zabbix 经历了大量版本迭代，功能越来越丰富。但监控领域也在变化：Prometheus、云监控、APM、日志平台、链路追踪和统一可观测平台层出不穷。

所以问题来了：Zabbix 还有存在价值吗？或者更直白地说，Zabbix 被淘汰了吗？

核心要点摘要

Zabbix 没有被完全淘汰，它在网络设备、传统服务器和部分存量系统监控中仍然很有价值。
如果团队动手能力强，并且没有 AIX 等小机监控需求，很多 Zabbix 场景可以被 Prometheus 生态或其他现代监控系统替代。
对中间件、数据库、Kubernetes 和微服务监控，Prometheus 生态通常更适合高维标签、聚合计算和云原生环境。
Zabbix 的主要短板不是“功能少”，而是 Host + Key 数据模型和关系型数据库存储不太适合现代高维时序数据。
多套监控并存会带来告警 OnCall 问题，需要 PagerDuty、Flashduty 这类告警响应平台做统一治理。

笔者近期认真研究了一下 Zabbix 的设计，直接抛结论：

如果你的动手能力较强，并且没有 AIX 等小机监控需求，Zabbix 可以被替掉。
如果你不想投入太多精力放在监控、可观测性的构建上，使用 Zabbix 监控网络设备，是一个不错的、投入脑细胞较少的选择。
除了网络设备之外，中间件、数据库、Kubernetes、微服务等的监控，建议使用 Prometheus 生态的开源项目。
这样会导致构建多套监控系统，Zabbix、Prometheus、甚至还有各类云监控，告警事件 OnCall 变成了一个大问题。可以使用 PagerDuty、Flashduty 之类的商业产品解决。

先给结论：Zabbix 没有整体淘汰，但部分场景已经落后

讨论 Zabbix 是否被淘汰，不能只问工具名字，要拆成场景。

如果场景是网络设备、固定服务器、传统操作系统、SNMP 设备、稳定模板和相对低频指标采集，Zabbix 仍然好用。它的功能完整性、模板积累和使用路径，对很多运维团队仍然有价值。

如果场景是 Kubernetes、微服务、大量中间件实例、高维标签聚合、服务级 SLO、链路追踪和跨数据源排障，Zabbix 就明显不占优势。不是 Zabbix 不能做，而是做起来不自然，维护成本也高。

所以更准确的判断是：Zabbix 没有被整体淘汰，但在云原生和现代可观测场景里，已经不再是首选。

Zabbix 的优势

Zabbix 发展了 20 多年，功能丰富，设计完整，很多细节都考虑到了。国内很多所谓的商业监控产品，其实都是基于 Zabbix 做的二次开发。

操作系统和设备覆盖面广

从数据采集角度，Zabbix 可以监控 Linux、Windows、BSD、AIX 等各种操作系统。要想在这方面淘汰 Zabbix，有点难度，因为很多新的监控系统都是使用 Go 编写的，甚至都无法跑在 AIX 上。

不过好消息是，现在大部分企业的 OS 已经趋于统一，基本都是清一色的 Linux。个别企业仍然在用 Windows，使用 AIX 的企业已经很少，是一个典型的存量市场。

功能完整，配置体系成熟

从使用角度，Zabbix 的界面虽然不够现代，但功能齐全。很多监控系统都从 Zabbix 的界面和功能组织方式上学习过。

Zabbix 的配置比较复杂，但配置好之后基本不用频繁调整，稳定性也是它的优势之一。Zabbix 使用模板机制降低配置复杂度，这个机制也是很多监控系统学习的对象。

分享一个笔者现阶段的认知：

一个 ToB 的软件产品，更强调功能丰富性、灵活性，不能像 C 端产品那样，追求傻瓜化，当然了，ToB 产品也尽量希望傻瓜化，因为可以降低用户使用门槛嘛。典型的手段有两个：一个是采用模板机制，提前内置一些最佳实践，让用户直接使用；另一个是默认只暴露基础功能，高级功能需要用户打开才能使用。

告警机制比较完备

Zabbix 的告警机制也很完整：通知媒介、用户联系方式、告警规则和通知策略之间的关联都设计得比较完整，甚至支持告警认领确认和升级。

它的不足在于告警降噪能力不够强。对门店、云资源、微服务这类容易产生大量告警的场景，如果只依赖 Zabbix 通知，后续 OnCall、收敛、抑制、升级和复盘会比较吃力。

Zabbix 的劣势

Zabbix 最大的优势是发展时间久、完成度高、功能丰富稳定。但也正因为发展时间久，它有比较重的历史包袱，很多设计已经不太符合现代监控要求。

数据结构僵化

Zabbix 的监控数据，主要用 Host + Key 来唯一标识。这个方式在传统服务器和网络设备场景里没问题，但随着微服务、Kubernetes 等技术普及，就显得不够灵活。

典型问题是多维度聚合计算。比如一个服务有 100 个 HTTP 接口，每个接口都要收集响应时间、QPS、Error 数量等指标。这些指标通常还要附加 region、service、method、env、status、code 等维度，然后按不同维度聚合。

在这种场景里，Zabbix 的 Host + Key 模型就会比较捉襟见肘。Prometheus 生态采用 metric name + labels 的方式，更适合处理这种高维指标。

数据存储压力大

2001 年的时候，时序库尚未流行。即便是 OpenTSDB、InfluxDB 等老一辈时序库，当时也尚未问世。Zabbix 的数据存储自然选择了关系型数据库，可以使用 MySQL 或 PostgreSQL。

问题在于，随着监控规模扩大，指标数量越来越多，有些公司每秒收集几千万指标，关系型数据库很难支撑这类用例场景。

而 Zabbix 的整个产品设计严重依赖底层存储 Schema。要想彻底换掉底层存储，并不是简单配置一个新数据库那么容易。这也是 Zabbix 的劣势之一。

哪些场景仍然适合 Zabbix

Zabbix 仍然适合这些场景：

网络设备监控，尤其是大量 SNMP 模板和设备型号积累的环境。
生命周期稳定的服务器、虚拟机和传统操作系统。
已经有大量 Zabbix 模板、触发器和告警经验的存量环境。
对监控频率和高维聚合要求不高，但希望通过 Web 完成大部分配置的团队。
不希望投入太多精力自建完整 Prometheus 生态的团队。

在这些场景中，Zabbix 的“成熟”和“完整”本身就是价值。

哪些场景更适合 Prometheus 生态

如果需求集中在以下方向，Prometheus 生态通常更合适：

Kubernetes 工作负载监控。
微服务接口指标，例如 QPS、错误率、延迟分位数。
数据库、中间件、缓存、消息队列等组件的高维指标采集。
需要按标签进行灵活聚合、过滤和告警。
需要与 Grafana、Nightingale、Categraf、Exporter 等生态工具组合。

这类场景不是 Zabbix 完全做不了，而是 Prometheus 生态的模型天然更匹配。

多套监控并存时，告警响应要统一

现实中，很多企业不会只用一套监控系统。常见组合是：

Zabbix 负责网络设备和部分传统主机。
Prometheus 生态负责云原生、中间件和应用指标。
云监控负责云资源。
日志和 APM 系统负责日志、链路和应用性能。

这种组合带来一个新问题：告警事件分散在多个系统里，OnCall 变复杂。值班人需要判断哪些告警属于同一故障、哪些需要升级、哪些可以抑制、哪些要复盘。

所以当监控系统变多时，重点不只是替换 Zabbix，而是要统一告警入口。PagerDuty、Flashduty 这类告警响应产品，就适合处理多来源告警的分派、升级、认领、降噪和复盘。

FAQ