Prometheus和zabbix
Prometheus和zabbix
普罗米修斯和zabbix分别是什么?都是监控
普罗米修斯:是由go语言开发的开源监控、报警 、时序数据库(按照时间排列的数据)的组合。是一个基于时间序列的数值数据的容器监控解决方案。
k8s的流行带动其发展。可以监控主机,服务,容器,支持多种exporter采集数据(依赖exporter数据采集),支持pushgateway(prometheus生态系统的重要组件,主要用于解决prometheus无法直接获取监控指标的问题,允许任何用户向它推送自定义监控指标,然后 Prometheus定时从pushgateway中拉取数据)进行数据上报,支撑上万台规模集群。
特点:多维度数据模型,通过多维度对数据建模和查询
有灵活的查询语言,提供灵活的promQL查询方式,提供http接口。
不依赖分布式存储,通过Prometheus自带的时许数据库完成每秒百万级存储,还可以对接第三方数据库。
支持多种图表和界面展示,Grafana第三方工具展示模型
通过服务发现 或静态 配置来发现目标服务对象
以http方式 通过pull模型拉取时间序列数据
监控原理:
Prometheus server定时在目标上抓取metrics(指标)数据
会将获取到的监控数据打包成一个可以访问的web页面,访问指定url来确定主机的状态
采取分布式拉取模式,更适合云原生和动态环境(k8s)
zabbix:
是一个监控平台。
分布式监控软件,高度集成的网络监控解决方案。
开源免费。支持分布式监控,支持数据持久化保存。
通过c/s模型收集数据,B/S模型在web端展示和配置。
特点:
(跨平台,支持分布式,集中管理,可以画图,持久化,多条件警告,强扩展性,应用广泛。)
有丰富的模板
自定义监控
多项完善的报警机制
适合分布式监控
集中管理系统,高度集成。
开源免费
构成:
server,web页面 ,数据库,agnet,proxy
(基于LAMP模型)
Prometheus zabbix 区别
普罗米修斯倾向微服务,适用容器化,动态伸缩场景优势明显,适用于大规模分布式系统监控,很好应对动态变化环境
zabbix:传统系统监控,功能全面,适合企业级静态环境,传统服务器、网络设备
| Prometheus | zabbix | |
|---|---|---|
| 数据采集 | pull模型(主动拉取目标暴露的指标) | push/pull混合(agent支持主动以及被动) |
| 存储引擎 | 时间序列数据库 | mysql/postgreSQL等 |
| 服务发现 | 原生动态(k8s) | 手动配置或脚本自动化 |
| 云原生/容器化环境 | 适配k8s | 定制开发,更适合静态 |
| 传统服务器监控 | 需要搭配exporter | 内置完善 |
| 微服务 | 支持微服务,多维度表亲聚合。 | 依赖自定义脚本,插件 |
| 网络设备监控 | 不支持 | 内置SNMP/ICMP等协议 |
| 存储 查询 | 时序存储高性能,默认15天,长期对接 Thanos/VictoriaMetrics | 支持长期存储,查询性能低 |
| 报警和可视化 | 通过 Alertmanager 实现,图片需要单独部署Grafana | 内置告警和web图表 |
对于真实物理机选择
各有各自的优势
Prometheus应用场景:
在云原生混合场景,存在k8s ,是开发运维团队,熟悉开源工具链,可投入时间自定义和深度整合可视化,大规模集群监控,侧重应用层监控。
zabbix应用场景:
是传统数据中心物理机,需要深度监控硬件健康 ,依赖SNMP/IPMI协议
快速部署,低代码需求
强警告与事件管理
需要异构环境统一管理:混合物理机,虚拟机,网络设备且需要一站式监控。
企业环境 一般使用zabbix作为基础监控平台,Prometheus作为云原生应用监控。
云原生:通过容器化技术,微服务架构等深度融合具备以下特性:
容器化:Docker
动态编排:k8s管理集群
微服务化:应用拆分为小的单元,可独立开发和扩展部署
不可变基础设施:通过代码定义(IaC)
声明式API:通过声明期望状态(而非过程步骤)管理系统,提升自动化程度。
k8s使用Prometheus
更多推荐
所有评论(0)