Prometheus vs Zabbix

转载地址：https://www.jianshu.com/p/b3a261d1502b

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 吧，毕竟人家就是干这个的。