prometheus与zabbix监控的对比介绍

一、普米与zabbix基本介绍

1、prometheus介绍

Prometheus的基本原理是Prometheus Server通过HTTP周期性抓取被监控组件的监控数据，任意组件只要提供对应的HTTP接口并且符合Prometheus定义的数据格式，就可以接入Prometheus监控。
工作流程大致分为收集数据，存储数据，展示监控数据，监控告警。
核心组件包括：
Exporters：监控数据采集器
Prometheus Server：负责对监控数据的获取，存储以及查询
AlertManager：告警流程管理
PushGateway：当网络需求无法满足时就可以使用PushGateway作为中转站。
Prometheus后端数据库用的自带的时序数据库TSDB，按时间索引性能更高。也支持其他远端数据库，但效率会有所下降。

普米架构图

2、Zabbix介绍

Zabbix的基础原理是Zabbix Server抓取监控组件的监控数据或者接收主动推送监控数据。支持在每个网络区域内部署一个Zabbix Proxy，即 Zabbix 的代理服务器，代理服务器采集当前区域的监控组件的监控数据。并将采集到的数据推送给 Zabbix Server 进行后续处理，
工作流程大致分为agent发送数据，sever存储数据，展示监控数据，监控告警。
核心组件：
Agent：主要负责采集数据并通过主动或者被动的方式采集数据发送到Server/Proxy，除此之外，为了扩展监控项，Agent还支持执行自定义脚本。
Server：要负责接收Agent/Proxy发送的监控信息，并进行汇总存储，触发告警等。
Zabbix Web ： zabbix的GUI接口，通常与server运行在同一台机器上
Proxy：可选组件，常用于分布式监控环境中，代理Server收集部分被监控数据并统一发往Server端，减轻Sever端负载。
Zabbix Database支持常用的关系型数据库，如MySQL、PostgreSQL、Oracle等，默认是MySQL。现6.0版本支持TimescaleDB，关系数据库较常用，学习成本低。

zabbix架构图

二、功能测试对比

1、基础监控指标对比

注：本次监控指标测试以主要在用的LINUX、mysql对象为例。

监控LINUX主机指标对比：
Zabbix内置指标通过agent进行采集，agent安装后需要配置文件。
prometheus由官方提供node_exporter采集器进行采集。直接解压缩运行。

监控mysql指标对比：
Zabbix支持agent、agent2两种客户端，agent2集成部分数据库、ceph、red采集插件，不需要在客户端另外配置。
Prometheus由官方提供mysqld_exporter采集器进行采集。

监控指标测试结论：
采集指标项上：Prometheus相较zabbix监控指标项更细。
采集频率上：zabbix可根据指标自定义频率，prometheus通过统一参数scrape_interval配置采集频率。
自定义监控指标上：zabbix提供agent+自定义脚本方式采集、配置繁琐， prometheus需要对源码进行二次开发困难。
采集分组情况上：Zabbix可通过agent采集多个业务组件，管理方便。 Prometheus需要部署多个exporter采集不同的业务组件，服务端口不固定。

2、云原生k8s监控对比

Zabbix 6.0 LTS新增Kubernetes监控功能
多个维度采集指标：
Kubernetes节点和pods的自动发现和监控
无代理方式采集Kubernetes pods和节点的信息
获取Kubernetes节点主机高水平信息：
kube-controller-manager、kube-apiserver、kube-scheduler、kubelet

监控部署方式
ZABBIX6.0提供HELM方式部署，将ZABBIX AGENT和ZABBIX PROXY等部署在Kubernetes集群中。并提供相应的模板，对Kubernetes集群进行自动发现及数据采集。

测试结论
ZABBIX6.0LTS版本虽然支持Kubernetes监控，原生模板监控项目前无法满足所需采集指标，需再自定义定制更丰富的监控项。
Prometheus监控Kubernetes更有优势，k8s组件自带采集接口，普米自动发现k8s组件Targets，抓取metrics数据，且两者出自于统一基金会，适配度更佳，对集群数据采集更全面。

3、高可用架构对比

zabbix高可用 
Zabbix6.0 支持原生 Zabbix server 高可用HA集群。
Zabbix HA由多个zabbix_server实例或节点组成。每个节点独立配置，集群为主备模式，standby（备用）节点不进行数据收集、处理或其他任务，并且不监听端口，并保持一个最少的数据库连接。
在 Zabbix 仪表板或Runtime运行时的命令行上可监控 Zabbix 集群的状态。
Zabbix 支持部署Zabbix proxy ，有利于分担 Zabbix server 的负载。

普米高可用
支持Federation联邦集群机制。集群分布式类似于nginx的负载均衡模式。
联邦集群核心在于每一个prometheus server都包含一个用于获取当前实例中监控样本的接口 ，每个server处理接收监控数据。
不同类型的采集任务划分到不同的 Prometheus 实例中去执行，进行功能分片。

对比优缺点
高可用配置方面：Zabbix HA 配置简单，操作维护成本低。
普米需要考虑数据持久化的问题。分层架构带来的配置复杂，维护成本较高。
联邦模式可以实现prometheus监控prometheus。

4、部署方式、版本升级方式对比

zabbix部署、升级方式
支持 二进制文件安装、源代码包安装、容器中安装三种方式。
容器化部署和版本开发迭代最简单快捷，zabbix各组件容器中单独运行，互不影响。
纯容器化部署存在采集压力过大影响容器集群、数据持久化问题。
需部署客户端agent采集程序。
zabbix版本升级过程复杂，特别跨版本的升级，需完成大量检查、验证工作。升级版本sever和proxy需保持一致，agents 不是强制性的（但推荐）。

普米部署、升级方式
支持源代码包安装、容器中安装两种方式。监控、告警和界面都分属于不同的组件，都需要安装。
容器化部署更简单快捷，容器适配性更好。
客户端需安装exporter采集器命令。
普米目前版本更新不大，2.0升级包含许多向后不兼容的更改，官方也无实际升级步骤，只有更新版本的迁移指南。

两者对比优缺点
都可以容器化部署，普米部署更方便些。
zabbix客户端需安装agent服务，普米客户端安装exporter命令，zabbix-agent安装维护更复杂繁琐。
zabbix版本升级过程更复杂且迭代比较快。

三、选型建议-prometheus和zabbix全面对比情况

  所以，需要根据不同的IT架构选型适合当前环境的监控软件，在传统架构里zabbix更有优势，但在云原生下现阶段还是普米用的多点。

     There are many things that can not be broken！

     如果觉得本文对你有帮助，欢迎点赞、收藏、评论！