专栏首页blackpigletPrometheus vs Zabbix

Prometheus vs Zabbix

公司要上监控,Prometheus 是最热门的监控解决方案,作为喜新厌旧的程序员,我当然是选择跟风了,但上级更倾向于 Zabbix,那没办法,只能好好对比一番,给出几个靠谱的理由了。

Monitoring system

但稍稍深入一点,我就体会到,我之前其实并没有真的理解口口相传的 Prometheus 的优点,这次对比虽然是始于无奈,但还是蛮有意义的,正好总结一下自己粗浅的体会。

1. 对比

先对两者的各自特点进行一下对比:

Zabbix

Prometheus

后端用 C 开发,界面用 PHP 开发,定制化难度很高。

后端用 golang 开发,前端是 Grafana,JSON 编辑即可解决。定制化难度较低。

集群规模上限为 10000 个节点。

支持更大的集群规模,速度也更快。

更适合监控物理机环境。

更适合云环境的监控,对 OpenStack,Kubernetes 有更好的集成。

监控数据存储在关系型数据库内,如 MySQL,很难从现有数据中扩展维度。

监控数据存储在基于时间序列的数据库内,便于对已有数据进行新的聚合。

安装简单,zabbix-server 一个软件包中包括了所有的服务端功能。

安装相对复杂,监控、告警和界面都分属于不同的组件。

图形化界面比较成熟,界面上基本上能完成全部的配置操作。

界面相对较弱,很多配置需要修改配置文件。

发展时间更长,对于很多监控场景,都有现成的解决方案。

2015 年后开始快速发展,但发展时间较短,成熟度不及 Zabbix。

2. 解析

更进一步的分析两者的主要差异:

2.1 图形化还是配置文件

Zabbix 的图形化配置毫无疑问是完爆 Prometheus 的,但这真的是个优势吗?

细想起来还真未必。图形化确实省去了手动改配置文件和命令行的繁琐,但这种努力毫无疑问是已经做出了需要人工介入的假设。但 Prometheus 是为云原生环境而生的,这种情况下,环境是动态变化的,服务器会随时增减,人工介入不太现实,那么图形化在这种情况下意义就不大了,毕竟要做自动化,那就不必要过图形界面这一道了。这么看来 Prometheus 在图形化方面的简约也是有意的取舍。

2.2 时序数据库还是关系型数据

近几年兴起的监控系统大部分都选择了将数据存储在时序型数据库中,Prometheus 用的就是自研的 TSDB,Zabbix 则用的是 MySQL 或 PostgreSQL。对于时序型数据库我了解不多,粗浅的来看,Prometheus 的时序型数据库在高并发的情况下,读写性能是远高过传统的关系型数据库的,另外还提供了很多内置的基于时间的处理函数,简化数据聚合的难度。也许这不能简单的理解为两种数据库的特性造成的结果,但至少说明,对专门监控场景进行存储优化,是十分必要的。

2.3 服务发现

大家都知道 Prometheus 在收集数据时,采用的 Pull 模型(服务端主动去客户端拉取数据),而以 Zabbix 为代表的传统监控采用的 Push 模型(客户端发送数据给服务端)。Pull 模型在云原生环境中有比较大的优势,原因是分布式系统中,一定是有中心节点知道整个集群信息的,那么通过中心节点就可以完成所有要监控节点的服务发现,去拉取数据就好了;Push 模型倒是省去了服务发现的步骤,但每个被监控的服务都需要内置客户端,还需要配置监控服务端的信息,这加大了部署的难度,Push 模型在 OpenStack 和 Kubernetes 等环境中用的不多。

2.4 开发语言

Golang 和 C 语言的开发对比,这就不用多解释了,不是一个时代的语言,Golang 占绝对优势。PHP 写界面倒是很常规的选择,但无奈 Grafana 写界面都不用编程语言,JSON 和 YAML 就可以搞定。所以真的要做定制开发,Prometheus 的难度要小很多。

3. 总结

Zabbix 的成熟度更高,上手更快,但更好的集成导致灵活性较差,问题更大是,监控数据的复杂度增加后,Zabbix 做进一步定制难度很高,即使做好了定制,也没法利用之前收集到的数据了(关系型数据库造成的问题)。 Prometheus 基本上是正相反,上手难度大一些,但由于定制灵活度高,数据也有更多的聚合可能,起步后的使用难度远小于 Zabbix。

比较一番下来,我的建议是,如果是刚刚要上监控系统的话,不用犹豫了,Prometheus 准没错。

但如果已经对传统监控系统有技术积累的话,还是要谨慎考虑:如果监控的是物理机,用 Zabbix 没毛病,或者是环境变动不会很频繁的情况下,Zabbix 也会比 Prometheus 好使;但如果是云环境的话,除非是 Zabbix 玩的非常溜,可以做各种定制,那还是 Prometheus 吧,毕竟人家就是干这个的。

4. 参考文档

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 如何使用 Gin 和 Gorm 搭建一个简单的 API 服务 (三)

      这是系列文章的第三篇。下面是另外两篇的链接: 如何使用 Gin 和 Gorm 搭建一个简单的 API 服务(一) 如何使用 Gin 和 Gorm 搭建一...

    用户2443625
  • Ceph RGW bucket 自动分片介绍和存在的问题

    工作中存储集群使用了 Ceph 技术,所用的是版本是 Luminous 12.2.4,因为刚刚上手 Ceph,不少概念和问题也都是头一次听说,比如这次的自动分片...

    用户2443625
  • CephFS 使用

    之前介绍了 RBD 的使用方法,有了 RBD,远程磁盘挂载的问题就解决了,但 RBD 的问题是不能多个主机共享一个磁盘,如果有一份数据很多客户端都要读写该怎么办...

    用户2443625
  • java应用监控之prometheus核心组件

    上一篇我们对prometheus做了一个简单的介绍,介绍了prometheus的优势以及和其他监控系统的对比,今天分享一下prometheus的核心组件。

    用户4361942
  • Prometheus 入门教程(一):Prometheus 快速入门

    Prometheus 是任何一个高级工程师必须要掌握的技能。那么如何从零部署一套 Prometheus 监控系统呢?本篇文章将从 Prometheus 的原理讲...

    陈树义
  • Axure实现Tab选项卡切换功能

    版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/huyuyang6688/article/...

    DannyHoo
  • python网络爬虫(9)构建基础爬虫思路

    基础爬虫分5个模块,使用多个文件相互配合,实现一个相对完善的数据爬取方案,便于以后更完善的爬虫做准备。

    嘘、小点声
  • python网络爬虫(10)分布式爬虫爬取静态数据

    爬虫应该能够快速高效的完成数据爬取和分析任务。使用多个进程协同完成一个任务,提高了数据爬取的效率。

    嘘、小点声
  • Reactive(2) 响应式流与制奶厂业务

    在前一篇文章 从Reactive编程到“好莱坞” 中,谈到了响应式的一些概念,讲的有些发散。但仅仅还是停留在概念的层面,对于实战性的东西并没有涉及。所以大家看了...

    美码师
  • Reactive响应式流入门!

    在前一篇文章 从Reactive编程到“好莱坞” 中,谈到了响应式的一些概念,讲的有些发散。但仅仅还是停留在概念的层面,对于实战性的东西并没有涉及。所以大家看了...

    Java3y

扫码关注云+社区

领取腾讯云代金券