企业官网建设流程全解析

简介：这份PDF操作记录面向使用Zabbix 7.0 LTS开展监控系统运维的工程师，聚焦MySQL/MariaDB中历史记录与趋势表持续增长带来的数据库性能压力，以及housekeeper进程繁忙告警等常见问题。内容以数据库分区优化为主线，梳理分区脚本的准备与执行、分区过程的定期自动运行、Zabbix前端历史与趋势保留天数配置，以及保留周期调整、操作前备份和大型库执行耗时较长等注意事项；对分区删除相较SQL DELETE更高效的原因也有说明，便于理解方案边界与落地条件。压缩包共1个PDF文件，大小约835KB，结构紧凑，适合在数据库服务器旁查阅对照。已有357人学习，对于正在规划数据保留策略、希望降低旧数据删除开销并提升数据库维护效率的运维人员，可作为实施前的方案核对与操作参照。

1. 装 Zabbix 7.0 LTS 前先想清楚：数据库分区不是装完再补的插件

给一台 8 核 16G 的虚机装 Zabbix 7.0 LTS，最容易翻车的不是前端 502，而是数据库历史表在两周后把磁盘写满。Zabbix 7.0 LTS 部署本身不复杂，MySQL/MariaDB 建库、导入 schema、改 zabbix_server.conf、起前端，半天能跑；真正决定这套监控能不能长期跑的是 history 和 trends 表的分区。没做分区，housekeeper 删旧数据越来越慢，前端空图、日志里出现 1526 错误都不奇怪。这份记录适合正在装 Zabbix 7.0 LTS、准备把 MySQL/MariaDB 历史表分区一起落地的开发者，也适合接手旧监控环境要补分区的人。下面按环境、安装、分区、排查、验证的顺序走。

2. 环境与版本清单：Zabbix 7.0 LTS 配 MySQL 8.0 的取舍

2.1 操作系统、数据库与 PHP 的版本组合

我一般先把版本钉死再动手，Zabbix 7.0 LTS 这条线最怕拿旧镜像里的 MySQL 5.7 或 PHP 7.4 硬上。Zabbix 7.0 对数据库和 PHP 都有门槛，MySQL 8.0 系列、MariaDB 10.5 以上更合适，PHP 至少 8.0，前端依赖的 mysqlnd、gd、bcmath、mbstring、xml、ldap 扩展要一次装齐。RPM 系发行版 9 的默认仓库通常能给到 PHP 8.0 或 8.1，够用；如果发行版仓库里 PHP 版本太低，就不要混装第三方 PHP 源，先把仓库版本对齐再装 Zabbix 包，否则前端安装向导会卡在扩展检查页。

版本组合我习惯按下面这张表核对，装之前跑一遍命令，把输出贴到变更记录里，后面排错时能少猜很多。

cat /etc/os-release mysql --version php -v httpd -v chronyc tracking

这段命令不带业务参数，作用是先把实际版本抓出来。mysql --version看的是客户端版本，服务端版本还要进库跑SELECT VERSION();；php -v只显示 PHP 主版本，扩展是否齐全要看php -m。我遇到过客户端是 8.0、服务端还是 5.7 的机器，安装包一路通过，导入 schema 时才报字符集和索引长度问题，返工成本比一开始核对高得多。

php -m | egrep 'mysqlnd|gd|bcmath|mbstring|xml|ldap'

php -m列出已加载扩展，egrep过滤 Zabbix 前端常用的几个。缺mysqlnd时前端连不上数据库，缺gd时图表生成会出问题，缺bcmath时部分数值计算会告警。这里不要用php -m | grep mysql代替，mysqli和mysqlnd不是一回事，Zabbix 7.0 的前端检查项认的是实际能力。

2.2 资源规划与目录、端口、账号约定

测试环境把 Zabbix server、数据库、前端放同一台虚机很常见，生产环境我一般会拆开：数据库单独一台，Zabbix server 和前端一台，agent 跟被监控机走。磁盘不要只按“装完能跑”算，history 保留 7 天、trends 保留 365 天是最常见的起点，监控项越多，history_uint和trends_uint涨得越快。分区脚本的作用是让旧数据按分区整块删掉，不是让磁盘容量凭空变大，容量规划还是要先做。

目录和账号先约定好，后面命令里就不容易写错。Zabbix server 配置在/etc/zabbix/zabbix_server.conf，前端文件在/usr/share/zabbix，日志在/var/log/zabbix，SQL 脚本包解出来的 schema 在/usr/share/zabbix-sql-scripts。数据库账号我一般就叫zabbix，只授权zabbix库，不给全局权限；系统用户zabbix由包自动创建，不要手工改它的家目录权限。

端口方面，Zabbix server 默认监听 10051，agent 默认 10050，前端走 80 或 443，数据库 3306 只对本机或内网开。SELinux 开着的时候，Apache 连 Zabbix server 和数据库需要额外布尔值，后面安装章会写。时间同步不要省，分区边界按clock字段做 RANGE，主机时间漂移会让“今天”的分区看起来对不上。

getent passwd zabbix ss -lntp | egrep '10051|10050|3306|:80|:443' df -h /var/lib/mysql /var/log/zabbix

getent passwd zabbix确认系统用户存在，ss -lntp看端口有没有被旧服务占用，df -h看数据库和日志分区余量。我踩过一次 3306 被旧测试库占用的坑，Zabbix server 起不来，日志只写连接失败，翻半天才发现是端口冲突。先把这些底账摸清，后面装包和导入 schema 会顺很多。

3. 安装 Zabbix 7.0 LTS：从仓库、数据库到前端登录

3.1 配置 Zabbix 7.0 仓库并安装 server、frontend、agent

仓库这一步我不建议直接抄公网地址，内网环境就把 Zabbix 7.0 的包同步到本地镜像，baseurl指向镜像目录，gpgcheck按镜像策略开。下面这段是仓库文件的结构示例，baseurl里的“你的镜像地址”要换成实际可达路径，不要原样执行。

sudo tee /etc/yum.repos.d/zabbix.repo >/dev/null <<'EOF' [zabbix] name=Zabbix 7.0 LTS baseurl=http://你的镜像地址/zabbix/7.0/el/$releasever/$basearch/ enabled=1 gpgcheck=0 EOF sudo dnf makecache sudo dnf install -y zabbix-server-mysql zabbix-web-mysql zabbix-apache-conf \ zabbix-sql-scripts zabbix-selinux-policy zabbix-agent

baseurl是包仓库根路径，$releasever和$basearch由 dnf 自动展开；gpgcheck=0只适合内网受控镜像，公网或不可信源不要关校验。安装包列表里zabbix-server-mysql是 server 端，zabbix-web-mysql是前端，zabbix-apache-conf带 Apache 配置片段，zabbix-sql-scripts里有导入用的 schema，zabbix-selinux-policy减少 SELinux 拦截。装完先别急着起服务，数据库还没初始化。

Web 服务和 PHP 依赖一起补齐：

sudo dnf install -y httpd php php-fpm php-mysqlnd php-gd php-bcmath \ php-mbstring php-xml php-ldap sudo systemctl enable --now httpd php-fpm

httpd是 Apache 服务，php-fpm提供 PHP 处理；如果发行版包里的 Zabbix Apache 配置走的是 mod_php，php-fpm可以不启，具体看/etc/httpd/conf.d/zabbix.conf里的 handler。php-mysqlnd是数据库驱动，php-gd画图，php-bcmath处理精度，php-mbstring和php-xml给前端解析用。装完跑一次php -m复核，不要等前端向导报错再补。

3.2 初始化 MySQL 8.0 并导入 Zabbix schema

数据库我一般用 MySQL 8.0，装完先做安全初始化，再建库建用户。下面命令里的密码是占位符，执行时换成自己的强密码，不要留在 shell 历史里。

sudo dnf install -y mysql-server sudo systemctl enable --now mysqld sudo grep 'temporary password' /var/log/mysqld.log sudo mysql_secure_installation

mysqld是 MySQL 服务名，grep那行取初始临时密码，mysql_secure_installation按提示改 root 密码、删匿名用户、禁 root 远程登录。临时密码只在首次初始化日志里出现，拿不到就查/var/log/mysqld.log的时间戳，不要反复重装数据库。

建库和授权：

CREATE DATABASE zabbix CHARACTER SET utf8mb4 COLLATE utf8mb4_bin; CREATE USER 'zabbix'@'localhost' IDENTIFIED BY '替换成强密码'; GRANT ALL PRIVILEGES ON zabbix.* TO 'zabbix'@'localhost'; GRANT EVENT ON zabbix.* TO 'zabbix'@'localhost'; SET GLOBAL log_bin_trust_function_creators = 1; FLUSH PRIVILEGES;

utf8mb4_bin是 Zabbix 库常用排序规则，不要随手改成utf8mb4_general_ci。GRANT EVENT是给后面 MySQL 事件调度器创建分区事件用的，没有这个权限创建事件会失败。log_bin_trust_function_creators=1是让开启 binlog 的实例允许创建存储过程，分区脚本里全是存储过程，不开会在导入时报 1418。这个参数是全局的，分区过程创建完可以按安全策略决定是否恢复。

导入 schema：

zcat /usr/share/zabbix-sql-scripts/mysql/server.sql.gz | \ mysql -uzabbix -p zabbix

zcat解压 gzip 后通过管道交给mysql，-uzabbix是数据库用户，-p会交互式提示密码，最后面的zabbix是目标库。schema 文件路径随包版本可能变化，找不到就用rpm -ql zabbix-sql-scripts | grep server.sql定位。导入完成后进库看表：

SELECT COUNT(*) AS table_count FROM information_schema.tables WHERE table_schema = 'zabbix'; SHOW TABLES LIKE 'history%'; SHOW TABLES LIKE 'trends%';

第一句看表数量，第二、三句确认history、history_uint、trends、trends_uint这些分区目标表存在。新库导入通常很快，大库或磁盘慢的机器要留时间，不要在导入中途重启数据库。

3.3 改 zabbix_server.conf 与 PHP 时区，启动服务

server 配置只改必要项，下面这段是最小集合：

DBHost=localhost DBName=zabbix DBUser=zabbix DBPassword=替换成强密码 DBSocket=/var/lib/mysql/mysql.sock ListenPort=10051

DBHost本机可以写localhost，走 socket 时DBSocket要对准实际路径；DBName、DBUser、DBPassword跟前面建库一致；ListenPort默认 10051，被占用就换。配置文件在/etc/zabbix/zabbix_server.conf，改完不要直接覆盖整份文件，用grep -n找到原行再改，避免把包自带的注释配置弄丢。

PHP 前端参数：

max_execution_time = 300 memory_limit = 128M post_max_size = 16M upload_max_filesize = 2M max_input_time = 300 date.timezone = UTC

这些值写在/etc/php.ini或/etc/php.d/下的独立 ini 里，date.timezone按业务时区改，测试环境用 UTC 最省事。max_execution_time太小会在前端安装向导超时，memory_limit太低会在图表页白屏。改完重启 PHP 和 Apache。

SELinux 和防火墙：

sudo setsebool -P httpd_can_connect_zabbix on sudo setsebool -P httpd_can_network_connect_db on sudo firewall-cmd --permanent --add-service=http sudo firewall-cmd --permanent --add-service=https sudo firewall-cmd --permanent --add-port=10051/tcp sudo firewall-cmd --reload

httpd_can_connect_zabbix让 Apache 能连 Zabbix server，httpd_can_network_connect_db让前端能连数据库，两个布尔值在生产 SELinux enforcing 下很关键。防火墙只放前端和 server 端口，数据库 3306 不要对全网开。

启动服务：

sudo systemctl enable --now zabbix-server zabbix-agent httpd php-fpm sudo systemctl status zabbix-server --no-pager sudo tail -n 50 /var/log/zabbix/zabbix_server.log

zabbix-server起不来先看日志最后 50 行，常见是数据库密码错、schema 没导入、SELinux 拦截。zabbix-agent的Server和ServerActive要指向 Zabbix server 地址，Hostname跟前端添加主机时一致。浏览器打开http://服务器IP/zabbix走前端安装向导，数据库信息填前面建的库，时区按业务选，完成后用 Admin 登录改默认密码。

4. 数据库分区落地：zbx_db_partitiong.sql 导入与自动调度

4.1 导入分区脚本前先改保留天数

分区脚本zbx_db_partitiong.sql里的默认值是历史 7 天、趋势 365 天，这个组合适合大多数起步环境。脚本会创建partition_create、partition_drop、partition_maintenance、partition_verify等存储过程，partition_verify负责把普通表第一次转成分区表，partition_maintenance负责按保留天数删旧分区、提前建未来分区。分区按clock字段做 RANGE，删旧数据用DROP PARTITION，比DELETE轻得多。

先把脚本包解出来，确认文件：

tar -zxvf zbx_db_partitiong.tar.gz ls -l zbx_db_partitiong.sql grep -n "partition_maintenance(SCHEMA_NAME" zbx_db_partitiong.sql

tar -zxvf解压，grep找到partition_maintenance_all里各个表的调用行。确认默认数字跟你想要的天数是否一致，不一致再改。改之前备份原文件，分区脚本本身不大，但改错参数会让保留天数跑偏。

cp zbx_db_partitiong.sql zbx_db_partitiong.sql.bak sed -i "s/'history', 7, 24, 3/'history', 30, 24, 3/g; \ s/'history_log', 7, 24, 3/'history_log', 30, 24, 3/g; \ s/'history_str', 7, 24, 3/'history_str', 30, 24, 3/g; \ s/'history_text', 7, 24, 3/'history_text', 30, 24, 3/g; \ s/'history_uint', 7, 24, 3/'history_uint', 30, 24, 3/g; \ s/'trends', 365, 24, 3/'trends', 400, 24, 3/g; \ s/'trends_uint', 365, 24, 3/'trends_uint', 400, 24, 3/g" \ zbx_db_partitiong.sql

这段sed把历史表保留天数从 7 天改成 30 天，趋势表从 365 天改成 400 天，24表示按 24 小时一个分区，3表示提前创建未来 3 个分区。参数顺序是SCHEMA_NAME, 表名, 保留天数, 分区小时间隔, 预创建数量。改完再用grep复核一遍，不要只看命令没报错就放心。

grep -n "partition_maintenance(SCHEMA_NAME" zbx_db_partitiong.sql

确认无误后导入：

mysql -u zabbix -p zabbix < zbx_db_partitiong.sql

<把脚本喂给 mysql，-u zabbix -p交互式输密码，最后一个zabbix是库名。新库导入很快，大库第一次执行分区可能持续较久，最好放维护窗口。导入完成后看存储过程：

SELECT ROUTINE_NAME FROM information_schema.ROUTINES WHERE ROUTINE_SCHEMA = 'zabbix' AND ROUTINE_NAME LIKE 'partition%';

能看到partition_create、partition_drop、partition_maintenance、partition_maintenance_all、partition_verify这些过程，说明脚本导入成功。看不到就检查是不是导到了别的库，或者数据库用户权限不够。

4.2 用 MySQL Event Scheduler 每 12 小时跑一次分区

分区过程建好不会自己跑，必须挂调度。MySQL 事件调度器是我更常用的方式，少一个 cron 依赖，日志也能在数据库里查。先开调度器：

[mysqld] event_scheduler=ON log_bin_trust_function_creators=1

配置文件放/etc/my.cnf.d/zabbix-partition.cnf，[mysqld]段不要写错。event_scheduler=ON让事件生效，log_bin_trust_function_creators=1是给存储过程创建留的开关。改完重启：

sudo systemctl restart mysqld mysql -u zabbix -p -e "SHOW VARIABLES LIKE 'event_scheduler';"

SHOW VARIABLES输出ON才继续。如果是OFF，先检查配置文件有没有被 include，再检查 MySQL 是否真的重启了。这个点很容易翻车：改了配置没重启，或者配置写进了[client]段，服务看着正常，调度器就是不工作。

创建事件：

CREATE EVENT IF NOT EXISTS zbx_partitioning ON SCHEDULE EVERY 12 HOUR DO CALL partition_maintenance_all('zabbix');

EVERY 12 HOUR是执行频率，CALL partition_maintenance_all('zabbix')是实际动作，参数是库名。12 小时一次比每天一次更从容，分区创建和删除都不容易堆在一起。创建完查事件：

SELECT EVENT_NAME, STATUS, INTERVAL_VALUE, INTERVAL_FIELD, LAST_EXECUTED FROM information_schema.EVENTS WHERE EVENT_SCHEMA = 'zabbix'\G

STATUS应该是ENABLED，LAST_EXECUTED在执行过一次后才有值。刚创建时看不到执行记录正常，等下一个 12 小时窗口，或者手动CALL partition_maintenance_all('zabbix');跑一次看输出。

如果环境不能用事件调度器，cron 是备选。密码不要直接写在命令行里，用--defaults-extra-file：

sudo install -m 600 /dev/null /etc/zabbix/.my.cnf sudo tee /etc/zabbix/.my.cnf >/dev/null <<'EOF' [client] user=zabbix password=替换成强密码 host=localhost EOF sudo crontab -e

cron 行：

30 03 * * * /usr/bin/mysql --defaults-extra-file=/etc/zabbix/.my.cnf zabbix -e "CALL partition_maintenance_all('zabbix');" >> /var/log/zabbix/partition.log 2>&1

30 03 * * *是每天凌晨 3:30，--defaults-extra-file读权限 600 的配置文件，避免密码出现在ps里。日志追加到/var/log/zabbix/partition.log，目录要提前确认 zabbix 或 root 可写。

4.3 前端管家与分区天数对齐，避免双重删除

分区脚本接管旧数据删除后，Zabbix 前端的内务管家要关掉历史趋势删除，否则两边同时删，保留天数会对不上。进前端：管理 → 一般 → 管家，取消“开启内部管家”里历史记录和趋势相关的勾选，勾选“覆盖监控项趋势期间”，历史填 7 天、趋势填 365 天——如果你脚本里改成了 30 天和 400 天，这里就填 30 和 400，必须跟脚本一致。

这一步是血泪经验：前端填 7 天、脚本保留 30 天，前端看起来只有 7 天数据，数据库里却留了 30 天分区；反过来前端填 30 天、脚本只留 7 天，第 8 天分区被删，前端图表直接断档。两边天数对齐后，分区删除只由脚本负责，前端只负责展示和清理配置。

4.4 保留天数变更：新建过程再改事件，不重跑脚本

上线后发现历史保留 7 天太短，或者趋势 365 天占磁盘太多，不要重新导入整个脚本，也不要在原过程上直接改到一半。做法是新建一个过程，再让事件指向新过程。下面示例把历史改成 30 天、趋势改成 400 天：

DELIMITER $$ CREATE PROCEDURE partition_maintenance_all_30and400(SCHEMA_NAME VARCHAR(32)) BEGIN CALL partition_maintenance(SCHEMA_NAME, 'history', 30, 24, 3); CALL partition_maintenance(SCHEMA_NAME, 'history_log', 30, 24, 3); CALL partition_maintenance(SCHEMA_NAME, 'history_str', 30, 24, 3); CALL partition_maintenance(SCHEMA_NAME, 'history_text', 30, 24, 3); CALL partition_maintenance(SCHEMA_NAME, 'history_uint', 30, 24, 3); CALL partition_maintenance(SCHEMA_NAME, 'trends', 400, 24, 3); CALL partition_maintenance(SCHEMA_NAME, 'trends_uint', 400, 24, 3); END$$ DELIMITER ;

DELIMITER $$是为了让 mysql 客户端把整段过程当成一个语句，过程体里的分号不会被提前截断。新过程名带天数，方便回滚和辨认。创建完先手动跑一次：

CALL partition_maintenance_all_30and400('zabbix');

确认输出里能看到partition_create和partition_drop的记录，再改事件：

ALTER EVENT zbx_partitioning ON SCHEDULE EVERY 12 HOUR DO CALL partition_maintenance_all_30and400('zabbix');

ALTER EVENT只改调度动作，不删旧过程。旧过程保留着，出了问题可以改回去。cron 方案同理，注释旧行、加新行，不要直接覆盖到没法回滚。前端管家里的天数也要同步改成 30 和 400，三处一致才算完成。

5. 避坑与排查：分区脚本跑不起来时先看这五处

5.1 现象：前端空图并报 1526 表没有分区

现象是前端最新数据空图，Zabbix server 日志里出现[Z3005] query failed: [1526] Table has no partition for value ...。原因通常是分区边界没有覆盖当前时间，事件调度器没跑、跑失败了，或者服务器时间跳到未来，partition_maintenance还没创建对应分区。解决顺序是先看事件执行记录，再手动补一次分区。

SELECT EVENT_NAME, STATUS, LAST_EXECUTED FROM information_schema.EVENTS WHERE EVENT_SCHEMA = 'zabbix'; CALL partition_maintenance_all('zabbix');

LAST_EXECUTED为空或很久没更新，说明调度没生效；手动CALL后看输出有没有创建新分区。如果手动也报错，检查event_scheduler和存储过程是否存在。补完分区后再看前端最新数据，通常几十秒内恢复。

5.2 现象：event_scheduler 是 OFF，分区数量不增长

现象是数据库里SHOW VARIABLES LIKE 'event_scheduler';返回OFF，information_schema.PARTITIONS里分区数量几天不变。原因是配置文件没写对位置，或者改完没重启 MySQL。解决是确认[mysqld]段下有event_scheduler=ON，重启后复查。

sudo grep -R "event_scheduler" /etc/my.cnf /etc/my.cnf.d/ 2>/dev/null sudo systemctl restart mysqld mysql -u zabbix -p -e "SHOW VARIABLES LIKE 'event_scheduler';"

grep -R看配置落在哪个文件，systemctl restart后必须复查变量。不要只看systemctl status显示 active 就认为配置生效，MySQL 的参数是启动时读的。

5.3 现象：历史数据保留天数与前端管家打架

现象是前端图表只显示 7 天，数据库里却有 30 天分区；或者前端配置 30 天，第 8 天图表断档。原因是前端管家和分区脚本各管一套删除逻辑，天数不一致。解决是把前端“历史数据存储期”“趋势数据存储期”改成跟脚本一致，并关闭内部管家对历史趋势的删除。

改完不要只刷新页面，等一个调度周期再看分区列表和前端图表。天数对齐后，旧分区只由DROP PARTITION删除，不会再出现两边抢着删的情况。

5.4 现象：cron 日志为空或密码出现在进程列表

现象是/var/log/zabbix/partition.log一直为空，或者ps里能看到mysql -u zabbix -p密码。原因是 cron 没执行、日志目录不可写，或者密码直接写在命令行。解决是用--defaults-extra-file，并检查 cron 服务与日志权限。

sudo systemctl status crond --no-pager sudo ls -ld /var/log/zabbix sudo tail -n 50 /var/log/zabbix/partition.log sudo crontab -l

crond没起、crontab 没保存、日志目录权限不对，都会让日志为空。密码放配置文件后，ps里只看得到--defaults-extra-file，看不到明文。配置文件权限设 600，属主按 cron 执行用户来。

5.5 现象：大库首次分区长时间锁表

现象是第一次执行partition_maintenance_all后，数据库写入变慢，Zabbix server 日志出现查询超时。原因是大表第一次从普通表转分区表，或者一次删除大量旧分区，元数据操作会持锁。解决是放维护窗口，先在测试库演练，确认耗时再上生产；首次分区前做备份，不要在生产高峰跑。

mysqldump --single-transaction --routines --triggers \ -u zabbix -p zabbix > /backup/zabbix_before_partition.sql

--single-transaction对 InnoDB 尽量不锁表，--routines把存储过程一起备出来，--triggers备触发器。备份文件不要放数据库同盘，避免磁盘满时一起丢。首次分区耗时跟表大小、磁盘 IO 有关，新库几分钟，大库数小时都出现过，窗口要留够。

6. 装完怎么验证：三条命令确认 Zabbix 7.0 LTS 分区真的在跑

6.1 数据库侧验证：分区边界与事件执行记录

先看分区边界，确认最新分区覆盖了当前时间：

SELECT TABLE_NAME, PARTITION_NAME, PARTITION_DESCRIPTION, TABLE_ROWS FROM information_schema.PARTITIONS WHERE TABLE_SCHEMA = 'zabbix' AND TABLE_NAME IN ('history', 'history_uint', 'trends', 'trends_uint') ORDER BY TABLE_NAME, PARTITION_ORDINAL_POSITION DESC LIMIT 12;

PARTITION_DESCRIPTION是边界时间戳，最后几个分区应该覆盖今天和未来几天；TABLE_ROWS只是估算值，不用太较真。再看事件：

SELECT EVENT_NAME, STATUS, LAST_EXECUTED FROM information_schema.EVENTS WHERE EVENT_SCHEMA = 'zabbix'\G

STATUS为ENABLED，LAST_EXECUTED有近期时间，说明调度在跑。两条都正常，数据库侧基本过关。

6.2 前端侧验证：最新数据、管家告警与日志

前端看“最新数据”有没有持续刷新，监控 → 最新数据里选一个主机看时间戳；再看“管理 → 一般 → 管家”，历史趋势天数与脚本一致。日志侧跑：

sudo tail -n 100 /var/log/zabbix/zabbix_server.log | egrep -i 'housekeeper|partition|1526|error'

没有housekeeper processes more than 75% busy持续刷屏，没有 1526，说明分区接管了旧数据删除。我一般还会等一个 12 小时周期，再查一次LAST_EXECUTED，确认不是手动跑一次就完事。

从那以后我每次上线分区前都强制走一遍备份、空库演练、天数对齐这三步，宁可多花半小时，也不在凌晨被空图叫起来。希望帮到你。

本文还有配套的精品资源，点击获取