一、监控工具的历史简介
1.1 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都自带云原生的光环,天然能够友好协作。
1.2 Zabbix
Zabbix官方的发行版本时间可以追朔到2012年,时间上比prometheus早了四年,Zabbix是由Alexei Vladishev开源的分布式监控系统,是一个企业级的分布式开源监控方案。能够监控各种网络参数以及服务器健康性和完整性的软件。使用灵活的通知机制,允许用户为几乎任何事件配置基于邮件的告警。这样可以快速反馈服务器的问题。基于已存储的数据,提供了出色的报告和数据可视化功能。
二、架构对比
2.1 Prometheus
Prometheus的基本原理是通过HTTP周期性抓取被监控组件的状态,任意组件只要提供对应的HTTP接口并且符合Prometheus定义的数据格式,就可以接入Prometheus监控。
Prometheus Server负责定时在目标上抓取metrics(指标)数据并保存到本地存储里面。Prometheus采用了一种Pull(拉)的方式获取数据,不仅降低客户端的复杂度,客户端只需要采集数据,无需了解服务端情况,而且服务端可以更加方便的水平扩展。
如果监控数据达到告警阈值Prometheus Server会通过HTTP将告警发送到告警模块alertmanger,通过告警的抑制后触发邮件或者webhook。Prometheus支持PromQL提供多维度数据模型和灵活的查询,通过监控指标关联多个tag的方式,将监控数据进行任意维度的组合以及聚合。
2.2 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时序数据库,不过目前成熟度还不高。
三、综合对比
Prometheus | Zabbix | |
发行时间 | 2016 | 2012 |
开发语言 | Go | C + PHP |
性能 | 支持万为单位 | 上限约10W节点 |
社区支持 | 相对比Zabbix,但数据人数据与日俱增,社区活跃 | 应用广泛,支持较成熟,遇到的问题都能搜索到 |
容器支持 | 不仅支持swarm原生集群,还支持K8S容器集群的监控,目前容器监控最好的解决方案 | Zabbix出现比较早,当时容器还没有诞生,自然对容器的支持也比较差 |
企业使用 | 基本上使用K8S与容器的企业,Prometheus是最好的选择 | 在传统监控中,尤其是在服务器相关监控方面,占绝对优势 |
部署难度 | 只有一个核心server组件,一条命令便可以启动 | 多种系统,多种监控信息采集方式 |
- 开发语言:为了应对高并发和快速迭代的需求,监控系统的开发语言已经慢慢从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 准没错。