公司要上监控：Zabbix 和 Prometheus 到底怎么选？千万别用错了！

Posted 2022-06-18 Java技术栈

点击关注公众号，Java干货及时送达

来源：www.cnblogs.com/xiaoyuxixi/p/12235979.html

新公司要上监控，面试提到了 Prometheus 是公司需要的监控解决方案，我当然是选择跟风了。

之前主要做的是 Zabbix，既然公司需要 Prometheus，那没办法，只能好好对比一番，了解下，毕竟技多不压身。

但稍稍深入一点，我就体会到了 Prometheus 的优点，总结一下这两种监控方式。

两种监控工具的历史简介

Prometheus

Kubernetes 自从 2012 年开源以来便以不可阻挡之势成为容器领域调度和编排的领头羊。

Kubernetes 是 Google Borg 系统的开源实现，于此对应 Prometheus 则是 Google BorgMon 的开源实现。

Prometheus 是由 SoundCloud 开发的开源监控报警系统和时序列数据库。

从字面上理解，Prometheus 由两个部分组成，一个是监控报警系统，另一个是自带的时序数据库（TSDB）。

2016 年，由 Google 发起的 Linux 基金会旗下的原生云基金会（Cloud Native Computing Foundation）将 Prometheus 纳入其第二大开源项目。

Prometheus 在开源社区也十分活跃，在 GitHub 上拥有两万多 Star，并且系统每隔一两周就会有一个小版本的更新，而 Prometheus 与它的“师兄”Kubernetes 都自带云原生的光环，天然能够友好协作。

Zabbix

Zabbix 官方的发行版本时间可以追朔到 2012 年，时间上比 Prometheus 早了四年。

Zabbix 是由 Alexei Vladishev 开源的分布式监控系统，是一个企业级的分布式开源监控方案。能够监控各种网络参数以及服务器健康性和完整性的软件。使用灵活的通知机制，允许用户为几乎任何事件配置基于邮件的告警。

这样可以快速反馈服务器的问题。基于已存储的数据，提供了出色的报告和数据可视化功能。

架构对比

想成为架构师，这份架构师图谱建议看看，少走弯路。

Prometheus

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

Prometheus Server 负责定时在目标上抓取 Metrics（指标）数据并保存到本地存储里面。

Prometheus 采用了一种 Pull（拉）的方式获取数据，不仅降低客户端的复杂度，客户端只需要采集数据，无需了解服务端情况，而且服务端可以更加方便的水平扩展。

如果监控数据达到告警阈值 Prometheus Server 会通过 HTTP 将告警发送到告警模块 alertmanger，通过告警的抑制后触发邮件或者 webhook。最新 HTTP 面试题整理好了，大家可以在Java面试库小程序在线刷题。

Prometheus 支持 PromQL 提供多维度数据模型和灵活的查询，通过监控指标关联多个 tag 的方式，将监控数据进行任意维度的组合以及聚合。

Zabbix

Zabbix 由 2 部分构成，Zabbix Server 与可选组件 Zabbix Agent。Zabbix Server 可以通过 SNMP，Zabbix Agent，ping，端口监视等方法提供对远程服务器/网络状态的监视，数据收集等功能。

它可以运行在 Linux，Solaris，HP-UX，AIX，Free BSD，Open BSD，OS X 等平台上。最新 Linux 面试题整理好了，大家可以在Java面试库小程序在线刷题。

核心组件主要是 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 时序数据库，不过目前成熟度还不高。

点击关注公众号，Java干货及时送达

综合对比

上面的表格，从开发语言上看，为了应对高并发和快速迭代的需求，监控系统的开发语言已经慢慢从 C 语言转移到 Go。

不得不说，Go 凭借简洁的语法和优雅的并发，在 Java 占据业务开发，C 占领底层开发的情况下，准确定位中间件开发需求，在当前开源中间件产品中被广泛应用。

从系统成熟度上看，Zabbix 是老牌的监控系统：Zabbix 是在 1998 年就出现的，系统功能比较稳定，成熟度较高。

而 Prometheus 是最近几年才诞生的，虽然功能还在不断迭代更新，但站在巨人的肩膀之上，在架构设计上借鉴了很多老牌监控系统的经验。

从数据存储方面来看，Zabbix 采用关系数据库保存，这极大限制了 Zabbix 采集的性能，而 Prometheus 自研一套高性能的时序数据库，在 V3 版本可以达到每秒千万级别的数据存储，通过对接第三方时序数据库扩展历史数据的存储。

从配置复杂度上看，Prometheus 只有一个核心 server 组件，一条命令便可以启动，相比而言，其他系统配置相对麻烦。

从社区活跃度上看，目前 Zabbix 比较活跃，但基本都是国内的公司参与，Prometheus 在这方面占据绝对优势，社区活跃度虽然不如，但是受到 CNCF 的支持，后期的发展值得期待。

从容器支持角度看，由于 Zabbix 出现得比较早，当时容器还没有诞生，自然对容器的支持也比较差。

而 Prometheus 的动态发现机制，不仅可以支持 Swarm 原生集群，还支持 Kubernetes 容器集群的监控，是目前容器监控最好解决方案。

总结

综合来看，Zabbix 的成熟度更高，上手更快，但更好的集成导致灵活性较差，问题更大是，监控数据的复杂度增加后，Zabbix 做进一步定制难度很高，即使做好了定制，也没法利用之前收集到的数据了（关系型数据库造成的问题）。

Prometheus 基本上是正相反，上手难度大一些，但由于定制灵活度高，数据也有更多的聚合可能，起步后的使用难度远小于 Zabbix。

但如果已经对传统监控系统有技术积累的话，还是要谨慎考虑更换监控。

如果监控的是物理机，用 Zabbix 没毛病，Zabbix 在传统监控系统中，尤其是在服务器相关监控方面，占据绝对优势。

甚至环境变动不会很频繁的情况下，Zabbix 也会比 Prometheus 好使；但如果是云环境的话，除非是 Zabbix 玩的非常溜，可以做各种定制，否则还是 Prometheus 吧，毕竟人家就是干这个的。

Prometheus 开始成为主导及容器监控方面的标配，并且在未来可见的时间内被广泛应用。

如果是刚刚要上监控系统的话，不用犹豫了，Prometheus 准没错。

Spring Boot 定时任务开启后，怎么自动停止？

工作 3 年的同事不知道如何回滚代码！

23 种设计模式实战（很全）

Spring Boot 保护敏感配置的 4 种方法！

面了个 5 年 Java，两个线程数据交换都不会！

阿里为什么推荐使用 LongAdder？

新来一个技术总监：禁止戴耳机写代码。。

重磅！Spring Boot 2.7 正式发布

Java 18 正式发布，finalize 被弃用。。

Spring Boot Admin 横空出世！

Spring Boot 学习笔记，这个太全了！

关注Java技术栈看更多干货

获取 Spring Boot 实战笔记！

开发者涨薪指南 48位大咖的思考法则、工作方式、逻辑体系