Zabbix 是一款常用的监控工具，它可以监控网络设备、服务器、应用程序等多种资源的状态。目前，使用 Zabbix 最大的瓶颈是数据库，维护好 Zabbix 的数据存储和告警，就能很好地应用 Zabbix 构建监控系统。

Zabbix 的数据主要存储在 history 和 trends 的2个表中，Zabbix 使用 SQL 删除查询从数据库中删除旧数据，可能会对数据库性能产生负面影响。随着时间推移，这两个表性能变差，我们非常容易收到误告警信息，严重影响查看真正出现问题的告警信息。

以上问题可以通过改造存储分区表轻松解决，实现快速清理历史数据，减少数据存储容量。下面通过一次成功的客户案例，向大家分享云掣快速定位 Zabbix 误告警原因 ➡️ 寻找解决方案 ➡️ 选择适合实际情景应用方案的全流程，详解存储分区表改造的整个过程，希望能够对面临同样数据库运维问题的人提供一定的支持与帮助。

背景

在维护客户监控系统的过程中，我们遭遇了一个极为棘手的状况。Zabbix 监控系统中，大量 Agent 不可达告警如潮水般涌来，然而令人费解的是，实际被监控端的 agent 状态明明一切正常，相关截图清晰地显示着这一矛盾情况。

经过深入调查，发现该问题的导火索是一次计划内的 RDS 重启维护操作。在此次维护之后，告警便接踵而至。但从数据库的各项指标来看，其运行状况又处于正常水平，毫无异样之处。这一异常现象无疑给监控系统的稳定性与可靠性带来了巨大的冲击，后续我们深入剖析这一问题的根源所在，并探寻行之有效的解决方案，以恢复监控系统的精准与稳定。

问题分析

首先，我们确认了当前的Zabbix架构：Zabbix Server、Zabbix Proxy和Zabbix Agent的分布式监控架构。这种架构的优势在于减轻Zabbix Server的负担，并实现集中式和分布式监控。

补充：Zabbix Proxy可以代表Zabbix Server收集性能和可用性数据。通过这种方式，Proxy可以自己承担一些收集数据的负载，并减轻Zabbix Server的负担。此外，当所有Agents和Proxy都向一个Zabbix Server报告并且所有数据都集中收集时，使用Proxy代理是实现集中式和分布式监控的最简单方法。

我们按照层级关系排查问题：

 首先第一个链路节点：Zabbix Agent

排查实际对应 Agent 主机运行状态正常，网络也均正常。

 中间链路节点：Zabbix Proxy

排查各监控指标没有明显异常。

 最外层链路节点：Zabbix Server

排查 Zabbix Server 主机相关监控指标，发现存在两处异常：

 utilization od Housekeeper internal processes 使用率已达 100%，如下图。

 Zabbix 误告警时，队列中有大量数据堆积，如下图。

进一步分析发现，实际误告警出现的时间刚好接近历史数据清理的时间，所以判断是历史数据过大，Housekeeper清理历史数据期间达到瓶颈导致出现大量数据队列堆积，从而触发了误告警。

补充：Housekeeper的作用是为了防止数据库持续增大，Zabbix有自动删除历史数据的机制，即Housekeeper，而在频繁清理历史数据的时候， Housekeeper进程突然开始繁忙。

处理方案

方案一：减少历史数据保留时长

既然是清理历史数据导致的，那么首先从历史数据入手，核查历史数据对应的数据库文件大小。

history: 185.94 GBhistory_uint: 242.71 GB

进一步确认这些历史数据的目前配置的保留时间，客户侧 Zabbix 历史数据保留时间为90天，历史趋势数据保留时间为 180天。

历史数据（history）和趋势数据（trends）是Zabbix中存储收集到的数据的两种方式。

补充：历史数据是指每一个收集到的监控数据， 趋势数据是指按小时统计计算的平均值数据。一般来讲，强烈建议将历史数据保留时长设置得尽可能的小。这么做可以让数据库不会因存储了大量的历史数据，导致超负荷运行。可以选择长时间的保留趋势数据，来替代长期需要的历史数据。例如：设置成保留14天历史数据和5年的趋势数据。

为了短期内可以尽快解决该问题，首先和客户沟通是否可以减少历史数据保留时长，最终客户侧要求历史趋势数据至少保留 90 天。

所以这里首先将历史数据设置为 30 天。历史趋势数据设置为 90天。

但是实际观察下来发现，因为客户目前采集的数据量比较大，这个举措效果不是很明显，偶尔还是有误告警的情况。

方案二：存储分区表改造

为了彻底解决 Housekeeper 清理历史数据期间导致的误告警问题，我们决定将历史存储数据进行分区改造。

当使用 MySQL 作为 Zabbix 的存储数据库时，在定期清理数据的时候，会消耗大量的服务器 CPU 和数据库的性能。因为删除的时候使用的是 Delete 语句清理，如果表的数据量很大，执行效率会变的非常差。不仅耗费大量的计算资源，还会引发数据库性能的衰退，最终累及整个监控平台的运行速度和响应。

将 Zabbix 底层表改造为分区表，Delete 清理数据的动作，变为 Drop 分区，从 DML 转化为 DDL 语句，对服务器和数据库负载影响减少了数倍，清理数据的动作也变的轻量化。

接着我们将介绍改造的整个过程：

准备工作

分区表在改造的时候，会全程锁表。根据历史经验，200G 的大表，改造为分区表需要 6 小时。Zabbix 一共有两张大表，大致需要 13 小时。所以不能直接到生产 Zabbix 数据库上执行，一般需要重新 clone 一台数据库，然后在 clone 数据库中进行分区改造，最后再切换到生产环境，这样在改造的时候，报警机制是可用的，切换的影响只有丢失 13 小时的监控数据。

如果使用的 RDS，可以直接使用基于时间点恢复 clone 实例。如果使用的是本地自建的 MySQL，可以使用 Xtrabackup 进行数据备份，然后还原到新实例。

分区改造

这一步，已经准备好了 clone 实例，此时就是对该实例进行分区改造。在存储过程创建代码这块可以修改历史数据和趋势数据的保留策略，例如下方表示保留 30 天的历史数据，保留 90 天的趋势数据。

这一步，已经准备好了 clone 实例，此时就是对该实例进行分区改造。在存储过程创建代码这块可以修改历史数据和趋势数据的保留策略，例如下方表示保留 30 天的历史数据，保留 90 天的趋势数据。

获取分区表改造 SQL 代码文件：

# 下载代码文件curl -O https://bestmonitoringtools.com/dl/zbx_db_partitiong.tar.gz# 解包tar -zxvf zbx_db_partitiong.tar.gz

连接数据执行 SQL 语句，这一步仅创建存储过程，所以非常快。

mysql -h mysql-host -u root -p '' < zbx_db_partitiong.sql

在存储过程第一次执行的时候，会把原表改为分区表，这一步需要消耗大量的时间，取决于你的数据量。

mysql -h mysql-host -u root -p '' --database Zabbix -e'CALLpartition_maintenance_all('Zabbix');'

定时维护分区

改造为分区表后，清理数据的动作变成了分区的创建和删除，需要周期维护。这里推荐使用 MySQL 原生的定时调度功能，阿里云 RDS for MySQL 也支持使用定时调度。

确认是否开启 MySQL 定时调度功能：

SHOW VARIABLES LIKE 'event_scheduler';

创建定时调度任务：

CREATE EVENT zbx_partitioning ON SCHEDULE EVERY 12 HOUR DO CALLpartition_maintenance_all('Zabbix');

查询任务执行情况：

SELECT * FROM INFORMATION_SCHEMA.events;

Zabbix Web 端配置禁用内部的Housekeeping

如果图片不明了，请按照以下步骤在 Zabbix 前端上配置管家

• 导航到“管家”部分：“管理”→“一般”→“管家"；

• 删除“历史记录和趋势”部分下“开启内部管家”中的复选标记；

• 在“历史记录和趋势”部分的“覆盖监控项趋势期间”上打勾；

• 在“历史记录和趋势”部分下，为趋势和历史记录定义“数据存储期”的天数（必须与数据库分区中配置的天数相同–历史记录应为60天，趋势图应为90天，如果您未更改脚本中的默认设置）；

• 点击“更新”按钮。

总结

通过方案二的执行操作，将历史数据存储进行分区表改造后，"utilization od Housekeeper internal processes "从 100% 下降至 15% 左右，性能优化了 4 倍左右，并且从根源上彻底解决了 Zabbix 误告警问题。

云掣专注于可观测运维，致力解决企业上云难、用云难、管云难三大问题。基于云数据库提供7*24小时保障服务，提供开发支持、数据库体系规范、持续优化、数据库架构支持，保障企业数据库高效稳定运行。全面提升企业的运维效率和稳定性，助力企业完成云时代的数字化转型，满足客户在数据库管理和云迁移方面的多样化需求！

参考资料

https://bestmonitoringtools.com/zabbix-partitioning-tables-on-mysql-database/

拓展知识

HousekeepingFrequency介绍：Zabbix执行Housekeeping的频率(单位为小时)。Housekeeping 负责从数据库中删除过期的信息。注意: 为了防止 Housekeeper 负载过大 (例如, 当历史和趋势周期大大减小时), 对于每一个监控项，不会在一个 Housekeeping 周期内删除超过4倍 HousekeepingFrequency 的过期数据。因此, 如果 HousekeepingFrequency 是 1小时, 一个周期内不会删除超过4小时的过期信息 (从最旧的数据开始) 。备注: 为降低 Server 压力， Housekeeping 将在 Server 启动以后，延迟30分钟执行。因此, 如果 HousekeepingFrequency 是1小时, Server 启动30分后执行第一次 Housekeeping , 然后按1小时为周期重复执行。从 Zabbix 2.4.0 以后有了这种延迟行为。从 Zabbix 3.0.0 开始，可以设置 HousekeepingFrequency 为0来禁止自动 Housekeeping。此时 Housekeeping 只能通过 Housekeeper_execute 启动， 在一个 Housekeeping 周期内删除的过期信息时长为从最后一次 Housekeeping 以来到配置周期的4倍，不少于4小时且不大于4天。

《数据资产管理白皮书》下载地址：https://www.dtstack.com/resources/1073/?src=bbs

《行业指标体系白皮书》下载地址：https://www.dtstack.com/resources/1057/?src=bbs

《数据治理行业实践白皮书》下载地址：https://www.dtstack.com/resources/1001/?src=bbs

《数栈V6.0产品白皮书》下载地址：https://www.dtstack.com/resources/1004/?src=bbs

想了解或咨询更多有关袋鼠云大数据产品、行业解决方案、客户案例的朋友，浏览袋鼠云官网：https://www.dtstack.com/?src=bbs

同时，欢迎对大数据开源项目有兴趣的同学加入「袋鼠云开源框架钉钉技术群」，交流最新开源技术信息，群号码：30537511，项目地址：https://github.com/DTStack