1・Prometheus VS Zabbix
2・监控系统选型的一些考量
・图形化还是配置文件
"Zabbix图形化操作简单，易上手；
Prometheus配置文件上手难度较高，易展开自动化。"
・时序数据库还是关系型数据
Prometheus 的时序型数据库在高并发的情况下，读写性能是远高过传统的关系型数据库的，另外还提供了很多内置的基于时间的处理函数，简化数据聚合的难度。
・服务发现
"Prometheus 在收集数据时，采用的 Pull 模型（服务端主动去客户端拉取数据），Pull 模型在云原生环境中有比较大的优势，原因是分布式系统中，一定是有中心节点知道整个集群信息的，那么通过中心节点就可以完成所有要监控节点的服务发现，去拉取数据就好了；
Zabbix 监控采用的 Push 模型（客户端发送数据给服务端）。Push 模型倒是省去了服务发现的步骤，但每个被监控的服务都需要内置客户端，还需要配置监控服务端的信息，这加大了部署的难度，Push 模型在 OpenStack 和 Kubernetes 等环境中用的不多。"
・开发语言
"定制开发，Prometheus 的难度要小很多。Grafana 写界面都不用编程语言，JSON 和 YAML 就可以搞定；
Zabbix前端用PHP，一般的上手难度；
Prometheus后端：Golang的优点：
良好的跨平台，可交叉编译
简单的工程管理，通过文件夹系统管理，没有类似Makefile的工程管理文件
静态编译，没有动态库的依赖，部署方便，编出来只有一个可执行程序
语法简单易学
天生支持并发，goroutine和channel，适合服务器编程
Golang相对C语言的缺点：损失10%左右的性能"
・总结
"Zabbix 的成熟度更高，上手更快，但更好的集成导致灵活性较差，问题更大是，监控数据的复杂度增加后，Zabbix 做进一步定制难度很高，即使做好了定制，也没法利用之前收集到的数据了（关系型数据库造成的问题）。
Prometheus 基本上是正相反，上手难度大一些，但由于定制灵活度高，数据也有更多的聚合可能，起步后的使用难度远小于 Zabbix。"
・Prometheus 的局限
"Prometheus 是基于 Metric 的监控，不适用于日志（Logs）、事件（Event）、调用链（Tracing）。
Prometheus 默认是 Pull 模型，合理规划网络，尽量不要转发。
对于集群化和水平扩展，官方和社区都没有银弹，需要合理选择 Federate、Cortex、Thanos 等方案。
监控系统一般情况下可用性大于一致性，容忍部分副本数据丢失，保证查询请求成功。
Prometheus 不一定保证数据准确，这里的不准确一是指 rate、histogram_quantile 等函数会做统计和推断，产生一些反直觉的结果。二是查询范围过长要做降采样，势必会造成数据精度丢失，不过这是时序数据的特点，也是不同于日志系统的地方。"
网友评论