之前紧张做的是 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。最新 HTTP 口试题整理好了，大家可以在Java口试库小程序在线刷题。
Prometheus 支持 PromQL 供应多维度数据模型和灵巧的查询，通过监控指标关联多个 tag 的办法，将监控数据进行任意维度的组合以及聚合。
Zabbix
Zabbix 由 2 部分构成，Zabbix Server 与可选组件 Zabbix Agent。Zabbix Server 可以通过 SNMP，Zabbix Agent，ping，端口监视等方法供应对远程做事器/网络状态的监视，数据网络等功能。
它可以运行在 Linux，Solaris，HP-UX，AIX，Free BSD，Open BSD，OS X 等平台上。最新 Linux 口试题整理好了，大家可以在Java口试库小程序在线刷题。
核心组件紧张是 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 准没错。
原文链接：https://mp.weixin.qq.com/s/3dEjEfbV_MOcq3XBdKhD6A
