prometheus和zabbix的对比.docx

《prometheus和zabbix的对比.docx》由会员分享，可在线阅读，更多相关《prometheus和zabbix的对比.docx（3页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、prometheus 和 zabb i x 的对比一、两种监控工具的历史简介：prometheus：Kubernetes自从2012年开源以来便以不可阻挡之势成为容器领域调度和编排 的领头羊，Kubernetes是Google Borg系统的开源实现，于此对应Prometheus则 是Google BorgMon的开源实现。Prometheus是由SoundCloud开发的开源监控报 警系统和时序列数据库。从字面上理解，Prometheus由两个部分组成，一个是监 控报警系统，另一个是自带的时序数据库(TSDB) o 2016年，由Google发起的 Linux基金会旗下的原生云基金会(Clo

2、ud Native Computing Foundation)将 Prometheus纳入其第二大开源项目。Prometheus在开源社区也十分活跃，在 GitHub上拥有两万多Star,并且系统每隔一两周就会有一个小版本的更新，而 Prometheus与它的“师兄” Kubernetes都自带云原生的光环，天然能够友好协 作。 zabbix：zabbix官方的发行版本时间可以追朔到2012年，时间上比prometheus早了 四年，Zabbix是由Alexei Vladishev开源的分布式监控系统，是一个企业级的分 布式开源监控方案。能够监控各种网络参数以及服务器健康性和完整性的软件。使

3、用灵活的通知机制，允许用户为几乎任何事件配置基于邮件的告警。这样可以快速 反馈服务器的问题。基于已存储的数据，提供了出色的报告和数据可视化功能。二、架构对比:Prometheus：bwkl and view dashboardsPromDashpushgatewayemailaleftmanagerPagerDutymetncsLocalStorageclient litxarynode / containershort-lived jobPrometheus的基本原理是通过HTTP周期性抓取被监控组件的状态，任意组件 只要提供对应的HTTP接口并且符合Prometheus定义的数据格式，就可

4、以接入 Prometheus 监控。Prometheus Server负责定时在目标上抓取metrics （指标）数据并保存到本 地存储里面。Prometheus采用了一种Pull （拉）的方式获取数据，不仅降低客户 端的复杂度，客户端只需要采集数据，无需了解服务端情况，而且服务端可以更加 方便的水平扩展。如果监控数据达到告警阈值Prometheus Server会通过HTTP将告警发送到告 警模块alertmanger,通过告警的抑制后触发邮件或者webhook0Prometheus支持 PromQL提供多维度数据模型和灵活的查询，通过监控指标关联多个tag的方式， 将监控数据进行任意维度的

5、组合以及聚合。Zabbix：JVM AgentSNMP AgentZabbix ServerZabbix Webzabbix 由 2 部分构成，zabbix server 与可选组件 zabbix agento zabbix server可以通过SNMP, zabbix agent, ping,端口监视等方法提供对远程服务器/ 网络状态的监视，数据收集等功能，它可以运行在Linux, Solaris, HP-UX, AIX, Free BSD, Open BSD, OS X 等平台上。核心组件主要是Agent和Server,其中Agent主要负责采集数据并通过主动 或者被动的方式采集数据发送到

6、Server/Proxy,除此之外，为了扩展监控项， Agent还支持执行自定义脚本。Server主要负责接收Agent发送的监控信息，并进 行汇总存储，触发告警等。Zabbix Server将收集的监控数据存储到Zabbix Database中。Zabbix Database支持常用的关系型数据库，如果MySQL、 PostgreSQL Oracle 等，默认是 MySQL,并提供 Zabbix Web 页面（PHP 编写）数 据查询。Zabbix由于使用了关系型数据存储时序数据，所以在监控大规模集群时常常 在数据存储方面捉襟见肘。所以从Zabbix 4.2版本后开始支持TimescaleD

7、B时序 数据库，不过目前成熟度还不高。三、综合对比：发行时间开发语言性能社区支持容器支持企业使用部署难度Prometheus2016go支持万为单位相对不如zabbix，但 人数与日俱增不仅支持swarm原生集群， 还支持Kubernetes容器集群 的监控，是目前容器监控最好 解决方案。基本上使用ku bernetes 与容器的企业， prometheus是最好的 的。只有一个核心server组 件，一条命令便可以启动zabbix2012c+php上限约10000节 点应用广泛，支持较成 熟,遇到的问题都能 搜索到Zabbix出现得匕檄早,当时 容器还没有诞生，自然对容器 的支持也比较差。在

8、传统监控系统中，尤 其是国艮务器相关监控 方面，占据绝对优势。多种系统，多种监控信息综合比对:如上面的表格，从开发语言上看，为了应对高并发和快速迭代的需求，监控系 统的开发语言已经慢慢从C语言转移到G。不得不说，G。凭借简洁的语法和优雅 的并发，在Java占据业务开发，C占领底层开发的情况下，准确定位中间件开发 需求，在当前开源中间件产品中被广泛应用。从系统成熟度上看，Zabbix是老牌 的监控系统：Zabbix是在1998年就出现的，系统功能比较稳定，成熟度较高。而 Prometheus是最近几年才诞生的，虽然功能还在不断迭代更新，但站在巨人的肩 膀之上，在架构设计上借鉴了很多老牌监控系统的

9、经验；从数据存储方面来看， Zabbix采用关系数据库保存，这极大限制了 Zabbix采集的性能，而Prometheus 自研一套高性能的时序数据库，在V3版本可以达到每秒千万级别的数据存储，通 过对接第三方时序数据库扩展历史数据的存储；从配置复杂度上看，Prometheus 只有一个核心server组件，一条命令便可以启动，相比而言，其他系统配置相对 麻烦，从社区活跃度上看，目前Zabbix比较活跃，但基本都是国内的公司参与， Prometheus在这方面占据绝对优势，社区活跃度虽然不如，但是受到CNCF的支 持，后期的发展值得期待；从容器支持角度看，由于Zabbix出现得比较早，当时 容器

10、还没有诞生，自然对容器的支持也比较差。而Prometheus的动态发现机制， 不仅可以支持swarm原生集群，还支持Kubernetes容器集群的监控，是目前容器 监控最好解决方案。总结:综合来看，Zabbix的成熟度更高，上手更快，但更好的集成导致灵活性较 差，问题更大是，监控数据的复杂度增加后，Zabbix做进一步定制难度很高，即 使做好了定制，也没法利用之前收集到的数据了（关系型数据库造成的问题）。 Prometheus基本上是正相反，上手难度大一些，但由于定制灵活度高，数据也有 更多的聚合可能，起步后的使用难度远小于Zabbixo但如果已经对传统监控系统 有技术积累的话，还是要谨慎考虑更换监控。