公司要上监控，Prometheus 是最热门的监控解决方案，作为喜新厌旧的程序员，我当然是选择跟风了，但上级更倾向于 Zabbix，那没办法，只能好好对比一番，给出几个靠谱的理由了。
但稍稍深入一点，我就体会到，我之前其实并没有真的理解口口相传的 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 吧，毕竟人家就是干这个的。
