图片来自 包图网
以前主要做的是 Zabbix，既然公司需要 Prometheus，那没办法，只能好好比较一下，了解一下，毕竟技多不压身。
但是稍微深一点，我就意识到 Prometheus 总结这两种监控方法的优点。
两种监控工具的历史简介
①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 都有自己的云原光环，自然可以友好合作。
②Zabbix
Zabbix 官方发行时间可追溯到 2012 年，时间比 Prometheus 早了四年。
Zabbix 是由 Alexei Vladishev 开源分布式监控系统是一种企业级的分布式开源监控方案。软件可以监控各种网络参数和服务器的健康和完整性。使用灵活的通知机制，允许用户为几乎任何事件配置基于电子邮件的报警。
这可以快速反馈服务器的问题。基于存储的数据，提供了优秀的报告和数据可视化功能。
架构对比
①Prometheus
Prometheus 的基本原理是通过 HTTP 定期捕获被监控组件的状态，只要任何组件提供相应的 HTTP 接口并符合 Prometheus 定义的数据格式可以访问 Prometheus 监控。
Prometheus Server 负责定期抓取目标 Metrics(指标)数据并存储在本地存储中。
Prometheus 用了一种 Pull(拉)获取数据的方式不仅降低了客户端的复杂性，而且客户端只需要收集数据，不需要了解服务端的情况，服务端可以更方便。
监测数据达到报警阈值Prometheus Server 会通过 HTTP 将报警发送到报警模块 alertmanger，触发电子邮件或 webhook。
Prometheus 支持 PromQL 通过监控指标提供多维数据模型和灵活查询，关联多个 tag 在任何维度上组合和聚合监控数据。
②Zabbix
Zabbix 由两部分组成，Zabbix Server 与可选组件 Zabbix Agent。Zabbix Server 可通过 SNMP，Zabbix Agent，ping，提供远程服务器/网络状态监控、数据收集等功能。
它可以在 中运行Linux，Solaris，HP-UX，AIX，Free BSD，Open BSD，OS X 等平台。
是主要的核心组件Agent 和 Server，其中 Agent 主要负责通过主动或被动的方式收集数据并发送到 Server/Proxy，此外，为扩大监控项，Agent 还支持自定义脚本的执行。
Server 主要负责接收 Agent 发送监控信息，汇总存储，触发报警等。
Zabbix Server 将收集到的监控数据存储到 Zabbix Database 中。Zabbix Database如果 支持常用的关系数据库MySQL、PostgreSQL、Oracle 等，默认为 MySQL，并提供 Zabbix Web 页面(PHP 编写)数据查询。
Zabbix 由于使用关系数据存储时序数据，在监控大规模集群时，往往缺乏数据存储。
所以从 Zabbix 4.2 版本后开始支持 TimescaleDB 时序数据库，但目前成熟度不高。
综合对比
例如，在上表中，为了满足高并发性和快速迭代的需要，监控系统的开发语言已经慢慢从 开始C 语言转移到 Go。
不得不说，Go 凭借简洁的语法和优雅的并发，在 Java 占业务发展，C 在底层开发的情况下，准确定位中间件开发需求，广泛应用于当前开源中间件产品。
从系统成熟度的角度来看，Zabbix 是老牌监控系统:Zabbix 出现于 1998，系统功能稳定，成熟度高。
而 Prometheus 这几年才诞生，虽然功能还在迭代更新，但站在巨人的肩膀上，在架构设计上借鉴了许多老牌监控系统的经验。
从数据存储的角度来看，Zabbix 采用关系数据库保存，极大地限制了 Zabbix 收集性能， Prometheus 自研一套高性能的时序数据库，在 V3 版本可以通过对接第三方时序数据库来扩展历史数据的存储，达到每秒数千万的数据存储。
从配置的复杂性来看，Prometheus 只有一个核心 server 组件，一个命令可以启动，其他系统配置相对麻烦。
从社区活动的角度来看，目前 Zabbix 比较活跃，但基本都是国内公司参与，Prometheus 在这方面有绝对优势。虽然社区活动不如，但遭受 CNCF 支持，后期发展值得期待。
从容器支持的角度来看，因为 Zabbix 出现较早，当时容器还没有诞生，自然对容器的支持也比较差。
而 Prometheus 的动态发现机制，不仅可以支持 Swarm 原生集群也支持 Kubernetes 容器集群监控是目前容器监控的最佳解决方案。
总结
综合来看，Zabbix 成熟度更高，起步更快，但更好的集成导致灵活性差，问题更大，监控数据的复杂性增加，Zabbix 很难进一步定制。即使定制做得很好，也不能使用以前收集的数据（关系数据库引起的问题）。
Prometheus 基本上恰恰相反，很难开始。但由于定制灵活性高，数据聚合可能性更大，启动后使用难度远小于 Zabbix。
但是，如果传统监控系统已经积累了技术，则应仔细考虑更换监控。
如果监控是物理机，使用 Zabbix 没毛病，Zabbix 在传统监控系统中具有绝对优势，特别是在服务器相关监控中。
即使环境变化不是很频繁，Zabbix 也会比 Prometheus 好用；但如果是云环境，除非是 Zabbix 玩得很滑，可以做各种定制，否则还是 Prometheus 毕竟人家就是这么做的。
Prometheus 开始成为主导和容器监控的标准，并在未来可见的时间内得到广泛应用。
假如刚要上监控系统，不要犹豫，Prometheus 准没错。
作者：小雨o0
陶家龙
出处：cnblogs.com/xiaoyuxixi/p/12235979.html
