prometheus和zabbix的对比

2019/04/10 10:10
阅读数 96

前言:

  新公司要上监控,面试提到了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。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等平台上。
  核心组件主要是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时序数据库,不过目前成熟度还不高。

三、综合对比:

 

综合比对:

  如上面的表格,从开发语言上看,为了应对高并发和快速迭代的需求,监控系统的开发语言已经慢慢从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 准没错。

 

原文出处:https://www.cnblogs.com/xiaoyuxixi/p/12235979.html

展开阅读全文
打赏
0
0 收藏
分享
加载中
更多评论
打赏
0 评论
0 收藏
0
分享
返回顶部
顶部