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 侧重在告警。