共计 2945 个字符，预计需要花费 8 分钟才能阅读完成。
起源：cnblogs.com/xiaoyuxixi/p/12235979.html
新公司要上监控，面试提到了 Prometheus 是公司须要的监控解决方案，我当然是抉择跟风了。
之前次要做的是 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 由 2 局部形成，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 准没错。
近期热文举荐：
1.1,000+ 道 Java 面试题及答案整顿 (2022 最新版)
2. 劲爆！Java 协程要来了。。。
3.Spring Boot 2.x 教程，太全了！
4. 别再写满屏的爆爆爆炸类了，试试装璜器模式，这才是优雅的形式！！
5.《Java 开发手册（嵩山版）》最新公布，速速下载！
感觉不错，别忘了顺手点赞 + 转发哦！
