---

相关内容原文地址：

CSDN：宫凯宁：Prometheus与zabbix的对比
博客园：小雨淅淅o0：prometheus和zabbix的对比
简书：blackpiglet：Prometheus vs Zabbix

---

一、Prometheus与Zabbix的对比

对比项	Prometheus	Zabbix	Prometheus优势	Zabbix优势
管理	二进制文件启动	LNMP+编译	轻量级Server，便于迁移和维护	-
配置	配置文件	图形化	更好的支持自动化配置	学习成本低
client	丰富的client库	zabbix_agent自定义脚本	为各种中间件、应用提供专业的exporter，监控项更全面	支持自定义监控项，对监控设计者的格局要求较高
数据存储方式	Prometheus TSDB	MySQL	监控数据以时间为维度统计情况较多，时序数据库更适用于监控数据的存储，按时间索引性能更高	MySQL较常用，学习成本低
数据处理	PromQL	MySQL	PromQL计算函数丰富，统计维度广	同上
二次开发	丰富的sdk	API	提供了GO、Java/Scala、Python、Ruby等SDK，二次开发更便捷	API适配较为常用，学习成本低
对云环境的支持	原生支持容器监控	更适合物理机监控	自动发现容器，更好的适配k8x	-
告警方式	可按照标签分组，收敛	在次数上收敛	告警收敛方式多样化	-
监控项值	支持数字	支持数字字符串	-	可做日志监控

总结：

• Zabbix更适合于物理机/虚拟机的监控。
• Prometheus更适合容器的监控，对于目前来说，大部分都是Docker或者K8s容器，如果公司所在逐渐往容器方向发展，建议还是采用Prometheus。

二、架构对比

2.1 Prometheus

Prometheus的基本原理是通过HTTP周期性抓取被监控组件的状态，任意组件只要提供对应的HTTP接口并且符合Prometheus定义的数据格式，就可以接入Prometheus监控。

Prometheus Server负责定时在目标上抓取metrics（指标）数据并保存到本地存储里面。Prometheus采用了一种Pull（拉）的方式获取数据，不仅降低客户端的复杂度，客户端只需要采集数据，无需了解服务端情况，而且服务端可以更加方便的水平扩展。

如果监控数据达到告警阈值Prometheus Server会通过HTTP将告警发送到告警模块alertmanger，通过告警的抑制后触发邮件或者webhook。Prometheus支持PromQL提供多维度数据模型和灵活的查询，通过监控指标关联多个tag的方式，将监控数据进行任意维度的组合以及聚合。

2.2 Zabbix

zabbix由2部分构成，zabbix server与可选组件zabbix agent。zabbix server可以通过SNMP，zabbix agent，ping，端口监视等方法提供对远程服务器/网络状态的监视，数据收集等功能，它可以运行在Linux，Solaris，HP-UX，AIX，Free BSD，Open BSD，OS X等平台上。

核心组件主要是Agent和Server，其中Agent主要负责采集数据并通过主动或者被动的方式采集数据发送到Server/Proxy，除此之外，为了扩展监控项，Agent还支持执行自定义脚本。Server主要负责接收Agent发送的监控信息，并进行汇总存储，触发告警等。Zabbix Server将收集的监控数据存储到Zabbix Database中。Zabbix Database支持常用的关系型数据库，如果MySQL、PostgreSQL、Oracle等，默认是MySQL，并提供Zabbix Web页面（PHP编写）数据查询。

Zabbix由于使用了关系型数据存储时序数据，所以在监控大规模集群时常常在数据存储方面捉襟见肘。所以从Zabbix 4.2版本后开始支持TimescaleDB时序数据库，不过目前成熟度还不高。

	发行时间	开发语言	性能	社区支持	容器支持	企业使用	部署难度
Prometheus	2016	go	支持万为单位	目前来说，应该很活跃了	不仅支持swarm原生集群，还支持K8s容器集群的监控，是目前容器监控最好解决方案	基本上使用k8s容器的企业，都选用Prometheus	只有一个核心server组件，一条命令便可以启动
zabbix	2012	c+php	上限约1000节点	虽然成熟，但目前活跃度应该不如prometheus高	zabbix出现较早，当时没有容器，对容器的支持较差	对于传统监控系统，尤其是服务器级别和虚拟器级别监控，占据优势	多种系统，多种监控采集方式

三、二者差异解析

3.1 图形化还是配置文件

Zabbix 的图形化配置毫无疑问是完爆 Prometheus 的，但这真的是个优势吗？

细想起来还真未必。图形化确实省去了手动改配置文件和命令行的繁琐，但这种努力毫无疑问是已经做出了需要人工介入的假设。但 Prometheus 是为云原生环境而生的，这种情况下，环境是动态变化的，服务器会随时增减，人工介入不太现实，那么图形化在这种情况下意义就不大了，毕竟要做自动化，那就不必要过图形界面这一道了。这么看来 Prometheus 在图形化方面的简约也是有意的取舍。

3.2 时序数据库还是关系型数据库

近几年兴起的监控系统大部分都选择了将数据存储在时序型数据库中，Prometheus 用的就是自研的 TSDB，Zabbix 则用的是 MySQL 或 PostgreSQL。对于时序型数据库我了解不多，粗浅的来看，Prometheus 的时序型数据库在高并发的情况下，读写性能是远高过传统的关系型数据库的，另外还提供了很多内置的基于时间的处理函数，简化数据聚合的难度。也许这不能简单的理解为两种数据库的特性造成的结果，但至少说明，对专门监控场景进行存储优化，是十分必要的。

3.3 服务发现

Prometheus 在收集数据时，采用的 Pull 模型（服务端主动去客户端拉取数据），而以 Zabbix 为代表的传统监控采用的 Push 模型（客户端发送数据给服务端）。Pull 模型在云原生环境中有比较大的优势，原因是分布式系统中，一定是有中心节点知道整个集群信息的，那么通过中心节点就可以完成所有要监控节点的服务发现，去拉取数据就好了；Push 模型倒是省去了服务发现的步骤，但每个被监控的服务都需要内置客户端，还需要配置监控服务端的信息，这加大了部署的难度，Push 模型在 OpenStack 和 Kubernetes 等环境中用的不多。

3.4 开发语言

Golang 和 C 语言的开发对比，这就不用多解释了，不是一个时代的语言，Golang 占绝对优势。PHP 写界面倒是很常规的选择，但无奈 Grafana 写界面都不用编程语言，JSON 和 YAML 就可以搞定。所以真的要做定制开发，Prometheus 的难度要小很多。