​一、监控工具简介

1、Zabbix

Zabbix 是由Alexei Vladishev开源的分布式监控系统，是一个企业级的分布式开源监控方案。2004年3月发布1.0 稳定版，比Prometheus早了10年以上。能够监控各种网络参数以及服务器健康性和完整性的软件。使用灵活的通知机制，允许用户为几乎任何事件配置基于邮件的告警。

后端使用数据库存储监控配置和历史数据，可以较为方便地对接数据分析、报表定制等渠道，在前端开放了丰富的 RESTful API 供第三方平台调用，整体架构符合当前 DevOps 的趋势。

2、Prometheus

Prometheus是由前Google员工创办公司SoundCloud开发的开源监控报警系统和时序列数据库。相对于k8s是Google Borg系统的开源实现，Prometheus是Google BorgMon的开源实现。

Prometheus 由两个部分组成，一个是监控报警系统，另一个是自带的时序数据库（TSDB）。

Prometheus 在开源社区十分活跃，在 GitHub 上拥有四万多Star，并且系统每隔两三周就会有一个小版本的更新，Prometheus 与它的“师兄”k8s 自带云原生的光环，天然能够友好协作。

二、架构对比

1、Zabbix 架构

Zabbix Server​

核心组件，C 语言编写，负责接收 Agent、Proxy 发送的监控数据，也支持 JMX、SNMP 等多种协议直接采集数据。同时，它还负责数据的汇总存储以及告警触发等。

Zabbix Proxy​

可选组件，对于被监控机器较多的情况下，可使用 Proxy 进行分布式监控，它能代理 Server 收集部分监控数据，以减轻 Server 的压力。

Zabbix Agentd​

部署在被监控主机上，用于采集本机的数据并发送给 Proxy 或者 Server，它的插件机制支持用户自定义数据采集脚本。

Agent 可在 Server 端手动配置，也可以通过自动发现机制被识别。数据收集方式同时支持主动 Push 和被动 Pull 两种模式。

• Database​

用于存储配置信息以及采集到的数据，支持 MySQL、Oracle 等关系型数据库。同时，最新版本的 Zabbix 已经开始支持时序数据库，不过成熟度还不高。

• Web Server​

Zabbix 的 GUI 组件，PHP 编写，提供监控数据的展现和告警配置。

2、Prometheus架构

• Prometheus Server​

用于定时抓取数据指标（metrics）、存储时间序列数据(TSDB)，TSDB在存储监控的性能会优于传统关系型数据库。

• Jobs/exporters​

Prometheus 使用各种 exporter 进行监控，exporter 的功能类似于 Zabbix 的 Agent，负责收集监控对象端的数据。

• Pushgateway​

监控端的数据会用push的方式主动传给此组件，随后被 Prometheus 服务定时 pull 此组件数据即可。

• Alertmanager​

报警组件，类似于Zabbix的Action，可以进行报警触发，比如发送短信和邮件。

Web UI 用于多样的UI展示，一般为Grafana，还有一些例如配置自动发现目标的小组件和后端存储组件。

三、Zabbix和Prometheus优劣 

1、Zabbix的优势

• 产品成熟​

由于诞生时间长且使用广泛，拥有丰富的文档资料以及各种开源的数据采集插件，能覆盖绝大部分监控场景，支持很多不同类型的设备和平台。

• 采集方式丰富​

支持Agent、SNMP、JMX、SSH 等多种采集方式，以及主动和被动的数据传输方式，Agent可以更好地进行统一标准化配置。

• 较强的扩展性​

支持 Proxy 分布式监控，有Agent 自动发现功能，插件式架构支持用户自定义数据采集脚本。

• 配置管理方便​

能通过Web界面进行监控和告警配置，操作方便，上手简单。

2、Prometheus的优势

• 较强的处理能力​

监控数据直接存储在 Prometheus Server 本地的时序数据库中，单个实例可以处理数百万的 Metrics。

• 灵活的数据模型​

引入了Tag，属于多维数据模型，聚合统计更方便，支撑不同团队个性化展现。

• 强大的查询语句​

PromQL 允许在同一个查询语句中，对多个 Metrics 进行加法、连接和取分位值等操作。

• 支持云环境​

能自动发现容器，同时 K8s 和 Etcd 等项目都提供了对 Prometheus 的原生支持，是目前容器监控最流行的方案。

3、对比

Zabbix 属于老牌的监控系统，资料多，功能全面且稳定，90%以上的配置可以通过Web 端统一操作和实现，比强依赖于配置文件的 Prometheus 要更为方便。

Prometheus有灵活的数据模型、更成熟的时序数据库，大数据量情况下性能更高。支持和Grafana 做快速集成，组合美观且强大的可视化体验，支持为不同团队提供更个性化的展现。

纯容器的环境，毫无疑问Prometheus是更适合的选择，Prometheus是天生为容器化平台打造的监控系统，环境很复杂，有各种操作系统、硬件、中间件、数据库、机房等，那么Zabbix更适合的监控平台，Zabbix兼顾了监控的深度和广度，实现了统一监控平台的目的；但当监控服务器上万，或者监控周期较长，超过了一年，需要面向不同团队灵活可视化展现时，Prometheus又有很强的优势。

四、Zabbix使用现状

公司按照业务线已经划分多套zabbix，运行稳定，但监控数据分散，无法集中化管理，多维度可视化能力较弱，数据存储周期过短，不方便容量预测和管理。

实时监控数据

监控趋势图

主机组

​

1、Zabbix 数据库表结构

1）配置数据

① hosts表

存储被监控主机的信息。

常用字段介绍如下：

• Hostid：唯一标识Host在Zabbix及数据库中的id。不同表之间的关联也要用hostid。
• Proxy_hostid：若启用“proxy-server”架构，才会出现被监控机器的proxy_hostid。
• Host：被监控机器的名字。
• Status：机器目前的状态。“0”为正常监控，“1”为disable。

② items表

存储所有监控项，利用hostid在items表中查询该主机有那些监控项，itemid为监控项的id，name为监控项的名称，key_为键值，也就是表达式，怎么对监控项取值。

• itemid：item的id。
• type：item的type，和前端见面配置item的type的对应。数据库中，这一列的值是0到17的数字，分别代表不同的类型。
• hostid：item所在的host的hostid。如果该item是属于template，那么这里显示的是templateid。
• name：item的名字。
• key_：item的key。
• status：item的状态。
• value_type：item返回值的类型，配置item时候配置的“Type of Information”。

③ hosts_groups表

存储了host（主机）与host groups（主机组）的关联关系。

④ Host_groups表

主机组，zabbix上主机组命名规范化，方便多维度查找。

姓名_部门_产品_集群名

⑤ problem表

存储问题事件。

查询当前未恢复的问题事件Top10  并将时间戳转换为格式化时间。

SELECT p.eventid as 事件id,FROM_UNIXTIME(p.clock,'%Y-%m-%d %H:%i:%s') as clock,p.name as 触发事件,p.severity as 事件等级 FROM problem p WHERE p.source='0' AND p.object='0' AND NOT EXISTS (SELECT NULL FROM event_suppress es WHERE es.eventid=p.eventid) AND p.r_eventid IS NULL ORDER BY p.eventid DESC LIMIT 10;

2）历史数据

Zabbix系统针对每个监控项在每次采集时所收集到的数据，这个数据保存Zabbix系统数据库的历史表中。监控的主机的数量较多的时候，zabbix系统每台产生的数量是非常庞大的，这对数据库是一种负担。建议对数据库进行分区或尽量减小历史数据的保留天数，以免给数据库系统带来很大的压力。

①history表：​存储信息类型为浮点数的监控项历史数据。

• history_log表：​存储信息类型为日志的监控项历史数据。
• history_str表：​存储信息类型为字符的监控项历史数据。
• history_text表：​存储信息类型为文本的监控项历史数据。
• history_uint表：​存储信息类型为数字(无正负)的监控项历史数据。

② history表结构

• itemid: 监控项唯一标识id。
• clock: 时间戳整数部分。
• value：监控项的值。
• ns：纳秒数。

查询 2022/06/07 00:00:00 -2022/06/08 00:00:00 itemid 29175 浮点数监控项历史数据。

select itemid,from_unixtime(clock) as time,value from history where itemid=29175 and clock >= unix_timestamp('2022/06/07 00:00:00') and clock <= unix_timestamp('2022/06/08 00:00:00');

五、super_exporter

为了解决zabbix存在的不足，我们进行了zabbix和Prometheus融合监控项目，通过为每套zabbix数据库开发部署一套super_exporter，定期从数据库抓取该zabbix下的所有监控服务器性能数据，上报给Prometheus。为了减轻主数据库压力，提升响应速度，为每套zabbix新增一个独立从库，专门为super_exporter抓取数据使用。

prometheus配置抓取任务，主机多的情况下，单个zabbix下总监控项会达到上万，性能优化后确保总执行时间不超过30s。

Metrics返回该zabbix管理的所有监控主机对应的多个监控项性能指标，涉及dba,host,产品部门，产品，集群，机房等标签。

super_exporter从hosts表获取本zabbix实例管理的监控主机集合，从hstgrp表获取主机对应运维负责人、部门、产品、集群名等业务层多维数据。从zabbix实例本身部署情况获取机房位置等数据，从items获取需要集中管理的监控项，从history类表抓取最近采集周期的监控数据。

六、Grafana展现

通过抓取zabbix汇聚的监控数据，存于TSD时序数据库，利用PromQL语言进行相关监控项的多标签聚合计算。使用grafana灵活强大的多维度可视化能力，方便及时地进行性能风险识别，进行长生命周期的资源容量预估。

通过数据行列转化，实例健康指数积分计算和排序，风险实例头部展示，临近性能值趋势对比，实时查看实例整体运行情况。

实时聚合多机房zabbix监控告警，集中化展现当前告警项；同时记录历史告警，审计告警趋势。

zabbix和prometheus融合，能够结合zabbix的成熟生态、配置灵活性和Prometheus的存储、展现优势，提供更强大的监控能力，支撑家庭业务百亿级人机物连接相关监控数据存储。单个Prometheus支持百万级Metrics,但随着接入zabbix的增多，监控数据时间存储周期拉长，未来将引入Thanos进行Prometheus长期化存储。同时super_exporter未来对接cmdb系统，匹配更多的业务标签数据，支持更多维的统计计算能力，满足公司不同团队的定制化数据展示需求。​