Zabbix和普罗米修斯区别

巴辉特 2024-11-11 14:16:42

Zabbix和普罗米修斯区别

Zabbix 和普罗米修斯是开源监控领域最值得了解的两个项目,Zabbix 更专注在设备监控,普罗米修斯更专注在微服务、Kubernetes 监控,本文探讨 Zabbix 和普罗米修斯的区别。

Zabbix 和普罗米修斯 Prometheus 的历史

Zabbix 是 2001 年左右发布的,那个时代,微服务和 Kubernetes 都不盛行,Zabbix 更多的是关注网络设备、服务器、数据库等传统 IT 基础设施的监控。Zabbix 的创始人是银行运维出身,对于监控相关的各类零碎需求了解的非常透彻。

普罗米修斯是 2014 年发布的,相对年轻,依托于之前 Google Borgmon 的先进经验和灵感,普罗米修斯在云原生监控领域有着非常好的表现。普罗米修斯的创始人是 SoundCloud 的工程师,之前就职于 Google,对 Google Borgmon 有深入的使用经验。Borgmon 是什么?Borgmon 是 Borg 的监控系统,Borg 是 Google 的集群管理系统,Kubernetes 就是 Borg 的开源版本。所以普罗米修斯的设计理念和 Borgmon 有很多相似之处。

所以,Zabbix 一开始就是更多服务于网络设备、服务器的监控,而普罗米修斯则更多服务于微服务、Kubernetes 等新技术的监控。

Zabbix 和普罗米修斯 Prometheus 的功能设计理念

Zabbix 出现的时间早,是它的优势,所以积累了很多功能,产品层面很多细节打磨的非常到位。在服务器和网路设备监控领域,你几乎可以使用 Zabbix 完成所有需求,Zabbix 可以看做是这个领域的大一统解决方案。

普罗米修斯由于出现的时间较晚,当时的社区资源截然不同,所以普罗米修斯更多的会借助社区的力量,比如可视化方面,就完全交给 Grafana 来做,而 Zabbix 则是内置了可视化方案。

普罗米修斯时代,大家对 IaC 的认可程度更高,很多配置都是通过代码来完成的,所以普罗米修斯的配置文件也是文本形式的,而 Zabbix 则是通过界面来配置。国内的企业相对来讲,对 IaC 的认可程度还不够,所以要想吸引国内客户,各类监控方案还是需要提供界面化的配置。毕竟客户的认知在哪里,产品就要在哪里,要想扭转客户的认知,需要时间。

Zabbix 从采集到存储到可视化分析和告警,基本都是自己一肩挑,而普罗米修斯出现的时间晚,要想快速发展,就需要借助社区的力量,所以普罗米修斯的设计理念是更开放的,很多工作是交给社区来完成。其职能边界更加清晰,更专注于监控数据的格式规范、采集规范、存储规范等。

  • 采集方面:普罗米修斯提供了数据格式要求,提供了少量的 Exporter,社区承担开发了大量的 Exporter,这些 Exporter 为普罗米修斯提供了丰富的监控数据。Zabbix 针对监控数据采集的很多逻辑,比如 LLD(Low Level Discovery)功能、数据的 Process、Mapping、主 item 等等逻辑,Prometheus 很多都没有,这些逻辑都是放在 Exporter 中的。
  • 存储方面:Zabbix 使用 MySQL 或 Postgres 存储时序数据,而普罗米修斯使用自家的 TSDB,专门为时序数据设计,性能更好,而且普罗米修斯有很多优化措施,比如 WAL、Compaction 等,可以保证在大数据量的情况下,性能依然很好。而实际上在当下的 2024 年,中大型企业也基本不会使用 Prometheus 直接存储监控时序数据,而是选用 VictoriaMetrics、Thanos、GrepTimeDB 等和 Prometheus 兼容的存储方案。这就导致:即便有些人说自己公司采用的 Prometheus 作为监控系统,实际他都未必部署的 Prometheus 进程。Prometheus 在这里更多的是指 Prometheus 生态,是一个广义的概念。
  • 告警引擎:普罗米修斯的告警严重依赖 PromQL,这是 Prometheus Query Language 的简称,是一种时序数据的查询语言,其灵活性好,基本解决了时序数据查询、告警的所有需求。而 Zabbix 也是内置告警引擎的,随着发展,Zabbix 也越来越重视其 Query Language,但是相比 PromQL,Zabbix 的 Query Language 还是有些不够灵活。当然,Prometheus 在告警引擎方面容易被诟病的是单点风险,这个问题可以通过部署多套 Prometheus 并且引入 Alertmanager 集群来解决。当然你也可以直接使用 Nightingale,Nightingale 越来越专注在做告警引擎,当前支持 Nightingale、Loki、TDEngine 的告警,后续会支持 ElasticSearch、ClickHouse 的告警。
  • 事件分发:Zabbix 的事件分发功能完成度很高,很灵活,其用户管理、团队管理、角色管理、权限管理、联系方式管理、媒介管理、通知脚本的管理,整体是非常体系化的,甚至支持告警事件的认领确认、升级,这都是很企业级的功能。但是 Zabbix 不支持告警降噪,而 Prometheus 生态的 Alertmanager 支持告警降噪,这是一个很大的区别。在事件分发方面,不同的监控系统都很难做到尽善尽美,而且通常一个公司会采用多套监控系统,比如同时使用了 Zabbix、普罗米修斯、云监控、日志监控等,这时候就需要一个统一的告警事件分发系统,比如 PagerDuty、FlashDuty 等。

Zabbix 和普罗米修斯 Prometheus 的适用场景

以笔者的观点来看,网络设备的监控,很适合使用 Zabbix 解决,因为 Zabbix 发展的时间比较久,积累了大量的网络设备的模板,而且社区里也有很多人贡献,几乎可以开箱即用。虽然 Prometheus 生态也有 snmp-exporter 这样的工具来解决网络设备监控的需求,但是如果你两个都去测试就会发现,Zabbix 的网络设备监控更加完善,更加适合企业使用。当然,如果你动手能力很强,不需要外人协助仅靠文档、Google 就可以自行搞定 snmp-exporter,那你也可以使用 Prometheus 生态来监控网络设备。从技术上来讲,基本也可以用。

但是,对于一些复杂场景,比如获取 SNMP 某个 Table 的数据,然后和某些 OID 拼接去获取另外一些 Table 的数据这样的场景,我知道 Zabbix 是可以解决的,不确定 SNMP-Exporter 能否搞得定,如果 SNMP-Exporter 搞不定但是你又想使用 Prometheus 生态作为你的监控系统,可以尝试 Categraf 作为 SNMP 采集器。

除了网络设备方面的监控,中间件、数据库、Kubernetes、微服务等的监控,建议使用 Prometheus 作为监控解决方案。因为这些数据量很大,而且经常需要按照不同的维度做聚合计算,这些场景下,Prometheus 生态更加适合。

如果你觉得普罗米修斯挺好,但是又想要 Zabbix 的 UI,则可以尝试 ccfos/nightingale 项目,姑且可以把 Nightingale 看做是带有 UI 的告警规则引擎,而且也提供权限、用户、团队等管理能力,适合拿来作为公司级统一的监控系统,让各个团队自助操作。Nightingale 和 Prometheus 并非替代关系,而是协同关系,Nightingale 有点像是 Grafana,可以接入不同的数据源,只是 Grafana 侧重在可视化,而 Nightingale 侧重在告警。

联系我们交流

Zabbix 和普罗米修斯的区别总结

Zabbix 是老一辈监控系统,更多的是面向服务器、网络设备,使用 MySQL 作为数据存储方案,是网管时代的产物。普罗米修斯是新一代监控系统,更多的是面向微服务、Kubernetes,是云原生时代的产物。

选型时还是要看自身需求,不要觉得云原生时代的产物就一定适合自己。比如,你们是大学的网管,你选择 Zabbix 大概更合适,因为大学的 IT 更多是管理各类网络设备、监控各类网络设备,对微服务、Kubernetes 涉及较少。

没有银弹,你也可以混用,比如网络设备采用 Zabbix,其他的监控需求使用 Prometheus,可视化使用 Grafana,告警使用 Nightingale,事件分发使用 FlashDuty。成年人的世界不做选择,都要。

快猫星云 联系方式 快猫星云 联系方式
快猫星云 联系方式
快猫星云 联系方式
快猫星云 联系方式
快猫星云
OpenSource
开源版
Flashcat
Flashcat