Zabbix和Prometheus之间的优势
一、简介
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 都自带云原生的光环,天然能够友好协作。
2、Zabbix
Zabbix 官方的发行版本时间可以追朔到 2012 年,时间上比 Prometheus 早了四年。
Zabbix 是由 Alexei Vladishev 开源的分布式监控系统,是一个企业级的分布式开源监控方案。能够监控各种网络参数以及服务器健康性和完整性的软件。使用灵活的通知机制,允许用户为几乎任何事件配置基于邮件的告警。可以快速反馈服务器问题。基于已存储的数据,提供了数据可视化功能。
二、架构
1、Prometheus
Prometheus 的基本原理是通过 HTTP 周期性抓取被监控组件的状态,任意组件只要提供对应的 HTTP 接口并且符合 Prometheus 定义的数据格式,就可以接入 Prometheus 监控。
Prometheus Server 负责定时在目标上抓取 Metrics(指标)数据并保存到本地存储里面。
Prometheus 采用了一种 Pull(拉)的方式获取数据,不仅降低客户端的复杂度,客户端只需要采集数据,无需了解服务端情况,而且服务端可以更加方便的水平扩展。
如果监控数据达到告警阈值 Prometheus Server 会通过 HTTP 将告警发送到告警模块 alertmanger,通过告警的抑制后触发邮件或者 webhook。
Prometheus 支持 PromQL 提供多维度数据模型和灵活的查询,通过监控指标关联多个 tag 的方式,将监控数据进行任意维度的组合以及聚合。
2、Zabbix
Zabbix 主要Server和数据库2部分构成,Zabbix Agent属于可选组件根据需要选择即可。Zabbix Server 可以通过提供多种监控手段监视提供对远程服务器/网络状态的监视,数据收集等功能。可参考之前博文介绍此处不过多阐述。
核心组件主要是 Agent 和 Server,其中 Agent 主要负责采集数据并通过主动或者被动的方式采集数据发送到 Server/Proxy,除此之外,为了扩展监控项,Agent 还支持执行自定义脚本。
Server 主要负责接收 Agent 或者其它协议采集的监控信息,进行数据存储,展示、触发告警等。
Zabbix Server 将收集的监控数据存储到 Zabbix Database 中。Zabbix Database 支持常用的关系型数据库,如果 MySQL、PostgreSQL、Oracle 等,默认是 MySQL,Zabbix Web友好的前端页面展现及配置操作。在Zabbix 4.2 版本发布开始支持 TimescaleDB 时序数据库,如没有这方面的专业知识暂不建议使用。
三、优势与劣势
从开发语言为了应对高并发和快速迭代的需求,监控系统的开发语言已经慢慢从 C 语言转移到 Go。Go 凭借简洁的语法和优雅的并发,在 Java 占据业务开发,C 占领底层开发的情况下,准确定位中间件开发需求,在当前开源中间件产品中被广泛应用
从系统成熟度角度,Zabbix属于老牌监控系统,Zabbix在1998年就出现了系统功能比较稳定,成熟度较高。Prometheus 是最近几年才诞生新的监控工具,在功能在不断迭代更新,但站在巨人的肩膀之上,在架构设计上借鉴了很多老牌监控系统的经验。
从数据存储角度,Zabbix 采用关系数据库保存,极大限制了Zabbix采集性能,Prometheus自研一套高性能时序数据库,在V3版本可以达到每秒千万级别的数据存储,通过对接第三方时序数据库扩展历史数据存储。
配置复杂度Prometheus只有一个核心server组件,一条命令便可以启动,相比而言其它系统配置相对麻烦些。
社区活跃度目前Zabbix比较活跃,但基本都是国内的公司参与,Prometheus 在这方面占据绝对优势,社区活跃度虽然不如,但是受到 CNCF 的支持,后期的发展值得期待。
容器监控角度Prometheus相比Zabbix优势好很多,毕竟Kubernetes和Prometheus是Google Borg 的两个开源系统在适配程度可想而知。Prometheus的动态发现机制,不仅可以支持 Swarm 原生集群,还支持 Kubernetes 容器集群的监控,是目前容器监控最好解决方案。
四、结论
从整理来看,Zabbix的成熟度更高上手更快,但集成性较弱导致灵活性较差。特别是监控数据的复杂度增加后,Zabbix定制难度很高后续适配行较差,即便做了定制也没法完全利用历史数据。除非Zabbix只作为采集器数据全部存入数据仓库进行消费。
Prometheus 基本上是相反的前期上手难度可能大些,但定制灵活度高,数据也有更多的聚合可能,熟悉后使用难度远小于 Zabbix。
如果传统架构环境使用Zabbix作为基础监控系统是可行的,特别在服务器相关监控方面,占据一定优势。但如果是云环境Zabbix定制成本远高于Prometheus需考虑系统的稳定性、事件准确性的担忧。Prometheus正在成为主导及容器监控方面的标配,相信在未来可见的时间内将被广泛应用。
总而言之还是需要根据自身情况结合分析选择自己合适的监控工具满足符合企业业务的需要才是王道。
探索技术无限可能,博主具有丰富监控模板资源及开发能力和项目管理经验,欢迎添加交流一起探讨,解决你的技术难题!
微信号:king_songax
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。 如若内容造成侵权/违法违规/事实不符,请联系我的编程经验分享网邮箱:veading@qq.com进行投诉反馈,一经查实,立即删除!