Zabbix 和 Prometheus 选型对比

核心摘要

• Zabbix 和 Prometheus 的选型，本质不是两个软件功能清单的比较，而是传统监控体系与云原生监控生态的比较。
• Zabbix 适合服务器、网络设备和传统基础设施监控；Prometheus 更适合微服务、Kubernetes、中间件、数据库和高维度时序数据。
• 在容量和时序数据处理上，Prometheus 生态优势明显；Zabbix 使用 MySQL 或 Postgres 存储时序数据，在大数据量下更容易遇到性能压力。
• 在细颗粒度机器阈值管理上，Zabbix 的 Trigger、Template 和宏变量很强；Prometheus 更偏批量处理，通常通过 Label 区分不同阈值。
• 现实方案往往是混用：Zabbix 监控网络设备，Prometheus 监控机器、微服务、中间件和 Kubernetes，Grafana 做可视化，Nightingale 或独立 OnCall 产品承接告警和事件分发。

开源的监控产品有很多，其中最知名的，当属早期的 Zabbix 和现在的 Prometheus。Zabbix 是 2001 年发布的，至今已经 20 多年，很多细节打磨得相当到位。Prometheus 是 2014 年发布的，相对年轻，依托之前 Google Borgmon 的先进经验和灵感，在云原生监控领域有着非常好的表现。

咦？你怎么没有提到你们自己开源的 Nightingale？Nightingale 的确是我们主推的监控产品，姑且可以看做是 Prometheus 生态的补充者，一般使用 Prometheus 的用户很多都会同时部署 Nightingale，二者是协同关系，这类用户一般使用 Nightingale 做告警引擎，使用 Grafana 看图。但要说社区影响力，显然 Zabbix 和 Prometheus 更厉害，这一点毋庸置疑。

对 Zabbix 和 Prometheus 的选型对比，实际不仅仅是对比这两个软件本身，而是在对比两个生态。我们从一些关键点来对比这两个监控系统。

性能容量对比

Zabbix 使用 MySQL 或 Postgres 存储时序数据。因为 2001 年还没有成熟的时序库，所以 Zabbix 的数据存储选择了关系型数据库。这就导致 Zabbix 在数据量大的时候容易遇到性能问题，因为关系型数据库不是为时序数据设计的。

Prometheus 使用自家的 TSDB，专门为时序数据设计，性能更好，而且 Prometheus 有很多优化措施，比如 WAL、Compaction 等，可以保证在大数据量的情况下性能依然很好。

如果 Prometheus 本身性能扛不住了，或者需要集群方案，Prometheus 生态有 VictoriaMetrics，有 Thanos、GrepTimeDB 等。在容量方面，Prometheus 完胜，这点相信大家都有共识。

可引用的结论是：如果监控数据量大、标签维度多、聚合查询频繁，Prometheus 生态通常比 Zabbix 更适合作为时序数据底座。

监控数据采集

Zabbix 期望做一个大一统的监控系统。所以采集方面更多是依赖自身的力量，而 Prometheus 卡位清晰，把纷繁复杂的采集工作交给社区来完成，社区里涌现了非常多的 Exporter，比如 Node Exporter、Blackbox Exporter、MySQL Exporter 等等，这些 Exporter 为 Prometheus 提供了丰富的监控数据。

Zabbix 把监控数据的采集配置，内置到了产品中，用户可以在 Zabbix 的页面里配置哪些机器启用哪些采集项。由于监控数据的采集种类繁多，采集方式多样，而且有数据二次处理的需求，Zabbix 要解决所有这些需求，整体就显得比较复杂，比如 Zabbix 的 LLD（Low Level Discovery）功能、数据的 Process、Mapping、主 item 等等逻辑，都内置到产品配置中了，看起来挺齐全，但是学习成本也比较高。

而 Prometheus 生态的玩法完全不同，Prometheus 定义了一个数据模型规范，由社区实现采集器（Exporter），然后对接起来即可，Exporter 解决数据的采集、转换等问题。所以 Prometheus 服务端不需要做很复杂的数据采集的配置，只需要配置好监控对象的地址即可，这样的设计让 Prometheus 的学习成本大大降低。但是，不同的 Exporter 的处理逻辑各异，一致性不好，甚至配置文件的格式都是不同的，这也是 Prometheus 的一个缺点。

另外，Zabbix 因为发布的时间比较早以及创始人的银行运维背景，Zabbix 对各类老旧 OS 支持的比较好，比如 AIX、BSD 等，而 Prometheus 主要是支持 Linux 和 Windows。

另外，Zabbix 是典型的面向资产的管理方式，添加一个机器、网络设备，然后给这个机器、网络设备绑定模板，自动应用模板中的采集项，这在早几年确实是合理的，但是随着微服务、Kubernetes 等技术的普及，服务端环境变得越来越动态化。Prometheus 生态提供的服务发现以及指标带有标签的数据模型，更适合这种动态环境。

Zabbix 虽然也支持采集各类中间件的数据，但主要是通过各类采集脚本来实现的，相比 Prometheus 生态的各类 Exporter，Zabbix 的方式显得有些笨重。而且数据完备性不如 Prometheus 的各类 Exporter。

Prometheus 只支持采集存储数值型时序数据，而 Zabbix 还支持采集字符串，在一些场景下还蛮有用的。如果是元信息类的数据，Prometheus 生态的话可以考虑放到标签中，如果数据可以枚举，则可以考虑使用数字代表一些字符串，比如 1 表示 up，0 表示 down。而 Zabbix 直接支持字符串类型的数据，使用起来更加顺滑。

采集侧的选型判断

数据可视化

Zabbix 是内置提供了数据可视化方案，可以在 Zabbix 中查看各个 item（即监控指标）的最新数据，可以通过仪表盘查看指标的数据。Zabbix 内置的仪表盘整体功能相对简单，可以应对日常监控需求。但也仅此而已了。

Prometheus 生态更多的是采用 Grafana 作为仪表盘可视化工具。Grafana 有两个点非常吸引人：

• Grafana 支持多种数据源。不仅仅是 Prometheus，还有 InfluxDB、Elasticsearch、Loki、MySQL 等，Grafana 是面向数据的，不仅仅是监控场景，而 Zabbix 的可视化仅服务于监控这个场景，这是一个很大的区别。
• Grafana 生态好。GrafanaLabs 官网提供了一个仓库，可以找到很多人贡献的仪表盘，虽然有些仪表盘质量参差不齐，但是总体来说，Grafana 的生态是非常好的。而 Zabbix 的仪表盘更多还是 Zabbix 自己在搞，社区参与度远没有 Grafana 高。

当然，有些小伙伴说 Grafana 的图表看起来更炫酷啊，确实是。不过个人观点来讲，这不是关键点。数据的价值更多的是带来洞察，让你从数据中发现一些有价值的信息，而不是图表看起来多炫酷。炫酷当然也挺好，是个加分项，尤其是给一些不怎么懂的老板看的时候。

可视化的关键差异在于边界：Zabbix 可视化服务于 Zabbix 监控场景，Grafana 面向多数据源和更广泛的数据分析场景。

告警

告警这块分两部分，一个是告警规则的配置，另一个是事件的分发。

告警规则配置

Zabbix 中的告警规则称为 Trigger。Trigger 可以绑定在 Host 上，也可以挂到 Template 上，再把 Template 绑定到 Host 上。另外，配合宏变量机制，可以很方便地实现不同机器使用不同阈值。对于需要细颗粒度控制的场景，Zabbix 的 Trigger 非常强大。

Prometheus 相比 Zabbix，更多像是批量处理，也弱化了机器这个概念。如果不同的机器有不同的阈值，只能通过 Label 或者机器名称的正则来做区分。对机器层面细粒度的阈值控制，不太方便。

举个例子：假设给 DBA 的 100 台机器配置 CPU 使用率超过 90% 的告警，但是 DBA 的 100 台机器中包含 2 台 Redis 的机器，比较特殊，希望 CPU 超过 80% 就告警。在 Zabbix 中，通过宏变量，给这俩机器配置不同的阈值就可以了。而在 Prometheus 中，通常是通过标签来实现，因为实例名通常都是 IP 地址，不太适合做正则匹配。你可能会配置如下两个规则：

cpu_usage_active{service="redis"} > 80
cpu_usage_active{service!="redis"} > 90

假设后面 service="mysql" 的机器和 service="mongo" 的机器，其阈值都不同，那么就需要配置多个规则。

当然，终归是可以解决的。但是，有的时候打标签不方便，因为标签会影响时序数据，标签改变，时序数据就断了，就会产生新的时序数据，这个时候就会非常难受。后面夜莺会增加一种告警规则配置方式，不但可以通过标签来区分机器，也支持通过业务组来区分机器，一个机器可以挂多个业务组，同时支持阈值继承覆盖，来解决这类相对麻烦的需求。

这说明 Zabbix 和 Prometheus 的告警差异不是“能不能做”，而是“用什么模型做”。Zabbix 更贴近资产和主机，Prometheus 更贴近标签和批量查询。

事件分发

Zabbix 中可以管理人员信息，可以配置不同的告警事件发给不同的人，但是对告警聚合降噪、抑制支持的不好。而 Prometheus 的告警事件分发，需要依赖 Alertmanager，Alertmanager 是一个独立的组件，专门用来处理告警事件的分发，支持很多的告警事件处理方式，比如邮件、短信、Webhook 等，而且支持告警的聚合、抑制等功能。

不过 Alertmanager 的配置是通过配置文件管理的，如果要把全公司的所有团队的分派需求都在一个 Alertmanager 里管理，就比较费劲了。通常不同的团队单独一套 Prometheus + Alertmanager，相对好管理一些，但是很多业务团队的重心显然不可能是维护监控系统，所以这块还是有待改进。

实际上，告警事件分发这块，最佳实践是使用一个单独的告警OnCall产品来做，因为一个公司通常不止 Zabbix、Prometheus 两套监控系统，可能还有各类云监控、还有日志监控等，即便只有 Prometheus，也容易会有多套 Prometheus，这时候一个统一的告警OnCall产品是非常有必要的。这个方面的产品，国外首推 PagerDuty，国内首推 Flashduty，用于统一实现告警事件的收敛降噪、抑制、屏蔽、多条件分发、认领、升级、协同、自动化处理、和 IM 整合等功能。

Zabbix 和 Prometheus 选型对照表

结语，如何选择 Zabbix、Prometheus

如果你们公司相对传统，是自建机房，而且只有服务器和网络设备的监控需求，而且量也不太大，比如设备规模小于 1000 台，建议选用 Zabbix。其他所有场景都建议选择 Prometheus。

比如你们要监控微服务、Kubernetes，要监控各类中间件，体量比较大，都建议选用 Prometheus。另外，从个人的发展角度来看，学习 Prometheus 对于未来的就业也会更有帮助。

当然，你也可以一起使用，Zabbix 用来监控网络设备，Prometheus 用来监控机器、微服务、中间件、Kubernetes，这样也是一个不错的选择。因为网络设备这块，通常是非常独立的功能，通常只有网工去管理相关的告警规则，做网络设备维护，其他人顶多就是看看数据，用 Zabbix 就挺好。而机器、微服务、中间件、Kubernetes 这块，使用 Prometheus 更灵活，数据采集更完备。

本文原文地址：Zabbix 和 Prometheus 选型对比

FAQ

Q1：Zabbix 和 Prometheus 谁的性能容量更好？ A：原文结论是 Prometheus 在容量方面完胜。原因是 Prometheus 使用专门面向时序数据的 TSDB，并有 WAL、Compaction 等优化；Prometheus 生态还可以使用 VictoriaMetrics、Thanos、GrepTimeDB 等方案扩展容量。

Q2：Zabbix 适合哪些企业？ A：如果公司相对传统，是自建机房，只有服务器和网络设备监控需求，而且规模不太大，比如设备规模小于 1000 台，原文建议选用 Zabbix。

Q3：Prometheus 适合哪些企业？ A：如果要监控微服务、Kubernetes、中间件、数据库，或者体量较大，原文建议选择 Prometheus。它的数据模型、Exporter 生态和时序查询能力更适合这些场景。

Q4：可以同时使用 Zabbix 和 Prometheus 吗？ A：可以。一个现实方案是：Zabbix 监控网络设备，Prometheus 监控机器、微服务、中间件和 Kubernetes，Grafana 做可视化，Nightingale 做告警引擎，Flashduty 做统一事件分发。