Zabbix VS Prometheus :哪个更适合你

最近几年一直在使用监控系统,主要使用Zabbix和Prometheus 两个监控工具,对于这两个监控系统有一些使用实践方面的经验,通过对比的方式来和大家分享一下。

一、Zabbix 和 Prometheus 的出现和发展
Zabbix 和 Prometheus 都是监控系统中很流行的工具,Zabbix 的出现要更早一些,在 2001 年的时候发布了 0.1,彼时时序数据库还没有应用在监控领域,Zabbix 基于当时的环境采用了关系型数据库来存储数据。

最早的时序数据库 RRDTool 出现于 1999 年 7 月 16 日,Influxdb 在 2013 年 10 月 24 日发布了 0.0.1 版本,Prometheus 于 2014 年 3 月 13 日发布了 0.1.0 版本 ,直到 2016 年,时序数据库彻底火了起来。

现在 Zabbix 按照每 6 个月一个稳定版本,每 2 年一个大版本的节奏在逐步发展,当前是 5.x 版本,6.x 版本也在规划中了。

Prometheus 按照每 6 周一个小版本的迭代在逐步前进,目前已经在 2.X 时代,最新版本是 2.30.0。

站在当前这个时间节点,Prometheus 即将发布 2.31.0 ,Zabbix 也已经发布了 5.4.0 。Zabbix 看到了时序数据库在监控领域的前景,在 5.x 开始支持使用时序数据库来存储数据,并且在 4.4 的时候就支持收集 Prometheus 的 数据存储在自己的关系型数据库中。Zabbix 站在企业级监控系统的角度,开始支持包含各种监控工具,进一步向一个臃肿的大而全的系统演进,并且开始小范围的尝试新的技术。Prometheus 按照自己最初的设计,只做监控,其他部分交给更专业的人来做,基于时序数据库,基于 Golang,不断优化,提高性能。目前来看,Prometheus 基本已经是云原生监控系统的事实标准,最佳选择。Zabbix 扎根企业市场以功能大而全的优点毅力不倒。

二、 Zabbix 和 Prometheus 的优缺点

最近在使用Zabbix 时被同事写的一个接口调用的bug导致Zabbix 的主机信息、模版信息、以及他们的关联关系全丢了,因为配置了自动注册,在这些数据丢失以后,Zabbix Agent 又把自己注册了一次,然后通过备份数据恢复的时候这两部分就发生了冲突,一个表一个表的解决问题。恢复好以后,这个事情又发生了一次。不同的是,第一次恢复紧急恢复花费了一晚上十几个小时的时间,全部恢复大概花了一周时间,第二次全部恢复花了两个小时。

另外的一个事情就是Zabbix Server版本升级,由于一些安全原因和实际碰到的 BUG,我们决定对 Zabbix Server 进行版本升级。仅仅是从 4.4.0升级到4.4.10花费了大约一周时间,各种测试,各种升级回滚解决问题。当然这也和当前的部署结构有关系,结构不合理,负载不均衡等等。

这个月主要就耗费在这里了。

针对 Zabbix 总结一下,有以下的优点:
1、监控模版可以包含多个指标,在不涉及自定义采集脚本等其他方式的情况下,使用SNMP、Zabbix Agent 的情况下可以做到开箱即用;
2、指标和触发器(Zabbix的告警规则叫触发器)的关联交互挺好用;
3、宏和宏变量的使用可以大大的提高告警的便捷性,基本可以做到每个label 不同的阈值;
4、Zabbix 的指标采集挺丰富的,包括采集间隔,是否要一直采集还是每天固定时间段来采集;
5、Zabbix 的管理页面,这个不愧是企业级软件,Zabbix 很大一部分的优势是靠它来体现的。

说完了优点来看看缺点:

1、Zabbix 架构原生是单点,没有集群方案,官方推荐的是使用keepalived 来进行3个点的负载均衡,这个方案在现在来说还是有很大的优化空间的。

2、Zabbix 的数据存储使用关系型数据库,在 Zabbix 刚发布的时候,这个没的选择,但放在现在这是个很大的问题,当指标数量增加以后,数据的存储空间、查询时间都变成了一个恐怖的事情。当前使用了6TiB的空间来存储了每帧80万条数据,采集间隔一分钟,详细数据1个月,历史数据大概1年半的数据,Prometheus 存储比这个节省多了。当然zabbix 也可以支持更大的数据收集规模,只是不知道资源会按什么比例增长。

3、升级复杂,体验了4.4.0升级到4.4.10以后,升级太麻烦,使用Zabbix 你的团队最好配置一个DBA 来处理各种问题。

4、Zabbix 和 Grafana 的结合不太好,语句写起来挺生硬的,也能用,但是不如Prometheus 灵活。

对于prometheus 这个月我也做了例行升级,大概花了一个小时左右,我升级完了十多个实例,配套的Thanos 和存储数据的Minio。和Zabbix 相比,这太让人舒服了。

Prometheus 具备以下优点:
1、结构简单,但是可以水平扩展,通过和thanos 结合可以做到无缝的水平扩展。不喜欢thanos 也可以使用自带的联邦功能进行扩展,Prometheus 的思想就是:我尽量简单但是好用,剩下的功能尽管放给其他人做

2、采用时序数据库,大大的节省了存储空间,并且提升了查询效率。我使用3TiB 的空间存储了每帧300万条数据,30秒采集一次,大约有120万条数据是15秒采集一次,详细数据存2个月,5分钟降准数据存半年,一小时降准数据存一年,而且我还不需要DBA 参与。

3、采集配置简单,简单配置以后就可以收取丰富的指标,不用自己一个指标一个指标的添加。

4、原生支持收集很多服务暴露的监控数据,Zabbix 很难收集应用自身提供的监控数据。

对于Prometheus 的缺点,
1、当前告警规则无法快捷的支持每个label 一个阈值,要么统一阈值,要么一个label 一条规则,量大了以后真的不好管理。大家如果这方面有什么好的办法还请指导我一下。
其他感觉和zabbix 比起来没啥缺点了。

另外有一个不同点就是,当采集内容较多的时候会出现一个机器上有多个 Agent 的问题。对于这个方面来说,Zabbix 只有一个 Agent ,但是很多内容需要自己编写采集脚本,Agent 还是比自己编写脚本的可靠性更高一些。另外对于单节点多 Agent 来说,Prometheus 也有对应的解决方案。

三、Zabbix 和 Prometheus 的适用场景

在使用Zabbix 和 Prometheus 的过程中,曾经将 Zabbix 和 Prometheus 放在各种场景下进行过使用,比如单个集群、多个集群、超级集群、企业业务环境等等场景。

我们先来看看集群环境。
对于单个中小规模的集群(500或者 1000 节点以下)来说,使用Zabbix 和 Prometheus 没有什么差别,无论使用哪种工具,做好规划和设计,使用起来基本没有问题,单机的资源使用、数据库的压力、场景的复杂度,都不是太大的问题。随便使用就好。

对于多集群来说,我们需要考虑 Master 节点的资源使用情况、数据库的压力承载情况、集群扩展的方便性。对于 Zabbix 来说,当节点数量直线上升的时候,Master 的压力会一直增大,对于单点 Master 的配置要求越来越大,当数量达到一定规模以后,单点就无法支撑这个规模的系统,然而官方也没有提出很好的集群方案。另外当节点规模增大以后,数据库的压力会变大,监控数据的查询会变的很慢,数据库会变成一个集群来解决遇到的问题,硬件资源的成本会直线上升。对于集群扩展来说,Zabbix 可以基于自动注册和 Proxy 来实现,但是数据是采取 Agent 到 Server Push 回来的,当你想要摘除一个被监控集群的时候操作很繁琐。

对于Prometheus 来说,在多集群的时候,可以每个集群使用一个 Prometheus ,通过 Thanos 来进行汇总,水平扩展特别方便,也不会有单点压力很大的情况,而且可以通过 Label 来区分不同的集群,单点Server 承载节点的能力比Zabbix 强很多。而且 Prometheus 使用时序数据库来存储监控数据,可以用很少的硬件资源提供更强的查询能力。Prometheus 使用 从 Server 到 Agent 拉取的方式获取数据,可以在 Server 端很轻易的操作采集那些节点,放弃某些节点的采集。

对于单集群超过 5000 节点的超级集群,建议直接使用 Prometheus ,可以不用 Zabbix 了,性能差太多。在不考虑冗余的情况下,Prometheus 单点就可以支持 5000 节点存储 1 个月的监控数据,Zabbix 使用同配置的机器至少要 3~4 台机器才能实现相同的效果。而且 Prometheus 相较 Zabbix 维护简单,使用方便。

对于企业的业务环境来说,超过 2000 台节点、业务服务数量大于 1000 个的时候建议直接上 Prometheus 。这个时候是需要一个完整的监控观测系统,需要和 Grafana、Kafka、Redis、MySQL等等中间件和各种系统进行结合、直接获取服务自身暴露的监控指标,在这种场景下,Prometheus 是最适合的。Zabbix 和其他中间件的结合较差,完全依赖自定义脚本来实现,没有依托社区的力量。

四、小结

对于 Zabbix 和 Prometheus 的选取主要看自己的使用场景,Zabbix 和 Prometheus 都有大规模使用的场景,在使用过程中选取适合自己的才是最好的。

对于 Zabbix 和 Prometheus 我也在持续的使用,很多新的特性和功能也在持续探索验证当中,如果有新的发现也会和大家分享。

你可能感兴趣的:(1024程序员节)