标签： Zabbix

近期处理了一起极具破坏性的监控系统瘫痪事故。现象非常经典：Zabbix Server 内部队列（Queue）在十分钟内飙升至 10 万以上，海量 nodata 触发器误报风暴瞬间淹没了告警通道，Zabbix Web 前端直接 502。最终结论很简单：业务团队在 Zabbix 中挂载了一个低效的自定义模板，每 30 秒通过被动模式（Passive Check）拉取一次包含海量无用信息的 500KB JSON 报文，并直接存入 history_text 表。这种把关系型数据库当日志库用的粗暴操作，直接打满了 Zabbix Proxy 的同步通道，并引发了后端 MySQL InnoDB 的脏页刷新风暴（Page Flush Storm）。

解决这类问题，单纯调大 Zabbix 的 HistoryCacheSize 或升级数据库磁盘只是扬汤止沸。真正的解法在于架构级的防御设计：在边缘端（Proxy/Agent）前置预处理（Preprocessing），剥离无效载荷，配合 MySQL 历史表分区（Table Partitioning）与 InnoDB 落盘策略调优，才能彻底稳住底盘。

案发现场与深层诊断

排查过程中，第一眼看到的是 Zabbix Server 自身的监控指标全盘崩溃。 提取 Zabbix Server 日志，满屏的告警触目惊心：

Zabbix server history syncer processes more than 75% busy
Zabbix server poller processes more than 75% busy
[Z3005] query failed: [1205] Lock wait timeout exceeded; try restarting transaction

直接通过运行时控制命令导出诊断信息：

zabbix_server -R diaginfo="historycache"

查看输出，History Cache 和 History Index Cache 的剩余空间几乎为零。这说明 Zabbix Server 的数据接收层已经被塞满，而负责将数据落盘的 History Syncer 进程被卡死。

此时切到后端 MySQL 节点，跑一下 iostat -x 1，发现数据盘的 %util 长期死锁在 100%，写入延时（w_await）飙升到 200ms 以上。 登入 MySQL 查看引擎状态：

SHOW ENGINE INNODB STATUS\G

发现 Modified db pages 指标极高，Buffer Pool 的脏页比例突破了 innodb_max_dirty_pages_pct 的阈值。Page Cleaner 线程疯狂刷盘，引发了严重的 I/O 拥塞，导致事务提交时写 Redo Log 发生等待。

究竟是哪个业务指标在疯狂灌水？直接查 Zabbix 数据库的 items 表：

SELECT h.host, i.key_, i.delay, i.value_type 
FROM items i 
JOIN hosts h ON i.hostid = h.hostid 
WHERE i.status = 0 AND i.value_type IN (1, 4) -- 1: character, 4: text
ORDER BY i.delay ASC LIMIT 10;

真相大白：某个新上线的微服务，为了图省事，写了一个自定义脚本获取应用状态，返回的是一个完整的、未经任何裁剪的巨型 JSON 结构。更致命的是，配置为 Text 类型，每 30 秒采集一次，且通过被动模式（Zabbix Server/Proxy 主动建立 TCP 连接去拉取）。

为什么这个操作不可原谅？

在运维架构中，监控系统是生命线，对监控系统本身进行 DoS 攻击是极其低级的错误。

1. 被动模式阻塞 Poller 进程：被动模式下，Zabbix Poller 需要等待 Agent 执行脚本并返回结果。当脚本执行耗时或报文过大时，TCP 会话长期占用 Poller 进程。默认几百个 Poller 瞬间耗尽，其他正常主机的 CPU、内存采集自然被挂起，引发大面积 nodata 误报。

2. 关系型数据库的文本噩梦：Zabbix 依赖的 MySQL InnoDB 对高频、大字段（Blob/Text）的插入极度不友好。海量的无序大文本写入不仅无法有效压缩，还会导致 Redo Log 极速轮转，触发 Checkpoint 强行刷脏，打爆磁盘 IOPS。把 Zabbix 当作 ELK 或 Prometheus（TSDB）来用，是典型的架构选型错位。

止血与根治方案

应对这种监控血崩，必须分级处理，先止血，再重构。

第一步：紧急熔断，恢复全局监控 直接在数据库层面禁用该危险模板的所有监控项，并清理历史缓存，重启 Server：

UPDATE items SET status = 1 WHERE key_ LIKE 'custom.app.json_dump%';

systemctl restart zabbix-server

第二步：利用 Zabbix Preprocessing 进行边缘降维 如果业务确实需要从该 JSON 中提取状态码，绝对不应将原始 JSON 透传给 Server。 利用 Zabbix 4.0 引入的 Preprocessing（预处理）功能，在 Agent 或 Proxy 端完成数据解析：

• 监控项类型改为 Numeric (unsigned)。

• 在 Item 的 Preprocessing 标签页添加：JSONPath -> $.data.status_code。 这样，Zabbix Proxy 拉取到 500KB 的 JSON 后，仅提取出数字状态码（如 200 或 500），再由 Proxy 将这几个字节的整型数据上报给 Server。网络带宽占用降低了 99.9%，数据库写入压力直接消失。

第三步：主动模式改造 将 Item 类型从 Zabbix agent 更改为 Zabbix agent (active)。把连接发起方从 Server/Proxy 转移到 Agent 端，彻底释放 Server 端宝贵的 Poller 进程池。

第四步：MySQL 数据库底层防御性调优 针对 Zabbix 这种典型的“重写轻读”场景，必须对 InnoDB 进行专项调优：

# my.cnf
# 牺牲极端的 ACID 保证，换取成倍的写入吞吐量。Zabbix 丢失最近 1 秒的数据完全可接受。
innodb_flush_log_at_trx_commit = 2 

# 提升 Buffer Pool 命中率，通常设为物理内存的 60%-70%
innodb_buffer_pool_size = 32G 

# 匹配 SSD 的真实 IOPS 能力，避免 Page Cleaner 罢工
innodb_io_capacity = 3000
innodb_io_capacity_max = 6000

# 优化大事务日志
innodb_log_file_size = 2G

同时，强烈建议对 Zabbix 的 history 系列表（尤其是 history_uint 和 history）实施按天分区（Table Partitioning）。Zabbix 内部的 Housekeeper 线程执行 DELETE 语句清理旧数据时会产生海量碎片和全表锁；改成分区表后，清理历史数据仅需一条 ALTER TABLE DROP PARTITION，瞬间完成且零磁盘 I/O。

同类问题排查清单（Troubleshooting Checklist）

1. Server 性能自证：检查 Zabbix 内部监控指标 zabbix[process,history syncer,avg,busy] 和 zabbix[process,poller,avg,busy]，若持续 >75%，说明落盘或采集被阻塞。

2. 大对象排查：在 Zabbix DB 执行 SELECT key_, delay FROM items WHERE value_type=4 AND status=0; 揪出文本类高频轮询项。

3. Proxy 积压检查：通过 zabbix[proxy,{$PROXY_NAME},lastaccess] 监控 Proxy 心跳延迟，若延迟激增，多为 Proxy 本地 SQLite/MySQL I/O 瓶颈或 Server 拒收。

4. 数据库 I/O 饱和度确认：使用 iostat -dmx 1 观察 w/s 与 %util，结合 MySQL SHOW ENGINE INNODB STATUS 中的 Log sequence number 推进速度，判断是否遭遇 InnoDB 脏页刷新瓶颈。

排查某次监控系统大面积告警延迟事故，Zabbix Dashboard 显示待处理队列（Queue）堆积突破 20 万，告警通知 P99 延迟达到夸张的 2 小时。最终定位：业务团队滥用自定义模板，通过 log[] 键值将大段 Java 报错栈直接写入 Zabbix，导致 history_str 和 history_text 表数据暴增；同时 Zabbix 原生 Housekeeper 清理过期数据时触发海量 DELETE 操作，彻底打爆 MySQL InnoDB 的 IOPS，引发 History Syncer 进程全部夯死。解决方案极其粗暴且有效：彻底关闭 Zabbix 原生 Housekeeper，将所有历史与趋势表改造成 MySQL 按天/按月分区表（Table Partitioning），用 DROP PARTITION 替代 DELETE。

故障现场极具讽刺意味：监控系统本身成了最需要被监控的系统。登录 Zabbix Server 节点，系统负载（Load Average）出奇的低，但查看 zabbix_server.log，满屏的红色告警：

Zabbix server history syncer processes more than 75% busy
Zabbix server trapper processes more than 75% busy
[Z3005] query failed: [1205] Lock wait timeout exceeded; try restarting transaction [delete from history_text where itemid=19283 and clock<1698710400]

History Syncer 是 Zabbix 将内存缓存数据刷入数据库的核心进程，它被堵死，意味着前端 Poller 和 Trapper 收集到的数据全憋在 Server 的 Shared Memory 里，最终导致采集停滞、队列爆炸。

切到 MySQL 数据库节点，罪魁祸首立刻浮出水面。执行 iostat -dx 2 观察磁盘，数据盘的 %util 死死钉在 100%，w/s （每秒写 IO）达到磁盘物理极限，await 延迟飙升到 800ms 以上。 进入 MySQL 终端敲下 SHOW FULL PROCESSLIST;，看到几十个处于 updating 或 Locked 状态的 SQL 线程，全部是类似这样的语句：

DELETE FROM history_str WHERE itemid=40281 AND clock < 1698710400 LIMIT 5000;
DELETE FROM history_text WHERE itemid=40282 AND clock < 1698710400 LIMIT 5000;

技术逻辑其实非常清晰。把关系型数据库当做时序数据库（TSDB）来用，本身就是一种架构妥协。在 InnoDB 引擎中，执行 DELETE 语句删除几百万行历史数据，简直是运维自杀。DELETE 并不是简单地抹掉磁盘空间，而是会产生海量的 Undo Log（用于回滚）和 Redo Log（用于崩溃恢复），同时需要更新 B+ 树索引，引发大量的数据页分裂与 Buffer Pool 内存淘汰（Churn）。 当这种重度 IO 操作遇上业务团队滥用 Zabbix 收集文本日志（把 Zabbix 当 ELK 用），history_text 表的一行数据可能高达几 KB。Housekeeper 一启动，瞬间的随机写 IO 洪峰直接把底层存储击穿。

为什么说这种配置不可原谅？因为在超过万级 NVPS（每秒处理新值数）的中大型 Zabbix 架构中，依赖原生 Housekeeper 清理数据是标准的新手雷区。Zabbix 官方手册虽然提过分区表的替代方案，但默认安装依然开启 Housekeeper，这坑了无数没有经历过数据量毒打的运维。

止血与根治方案：

第一步，紧急止损。立刻修改 zabbix_server.conf，将 Housekeeping 的频率设置为 0，切断 IO 洪峰的源头，并重启 Zabbix Server，等待队列慢慢消化。

# zabbix_server.conf
HousekeepingFrequency=0

第二步，架构重构，实施 MySQL 表分区（Table Partitioning）。 原理很简单：将时间序列数据按时间（clock 字段）分散到不同的物理文件中。当需要删除过期数据时，直接 ALTER TABLE ... DROP PARTITION。在文件系统层面，这等同于直接 rm -f 一个物理文件，时间复杂度为 O(1)，瞬间释放空间，彻底零 IO 负担，不会产生任何 Undo Log。

针对 Zabbix 历史表的改造核心 SQL 如下（以 history_uint 为例）：

-- 确保表结构没有外键，且时钟字段是主键/唯一键的一部分
ALTER TABLE history_uint PARTITION BY RANGE (clock) (
    PARTITION p20231101 VALUES LESS THAN (UNIX_TIMESTAMP('2023-11-02 00:00:00')),
    PARTITION p20231102 VALUES LESS THAN (UNIX_TIMESTAMP('2023-11-03 00:00:00')),
    -- 预先建好未来的分区
    PARTITION p_future VALUES LESS THAN MAXVALUE
);

配合一个定时执行的 Shell 或 Python 脚本（业内常用 zabbix-mysql-partitioning.pl 脚本），每天零点自动检查并 DROP 掉过期的历史分区，同时 ADD 未来的新分区。

最后，强烈建议剥离 Zabbix 的文本日志收集职能。Zabbix 核心是数值型时序监控（float/uint），日志型（str/text）数据一律丢给 Filebeat + Elasticsearch 或 Promtail + Loki 去处理。在监控架构里，强行让一个工具做所有事，最后通常是什么都做不好。

同类问题排查清单（Zabbix 性能雪崩速查）

1. Zabbix 内部队列指标：在 Zabbix Frontend 检查 Administration -> Queue。如果延迟集中在 10 分钟以上，且大部分是 Zabbix agent (active) 或 Trapper，大概率是 Server 性能瓶颈而非网络问题。

2. 底层数据库 IOPS 饱和度：通过 iostat -dx 1 或 Node Exporter 的 node_disk_io_time_seconds_total 指标，排查底层数据盘 %util 是否长期处于 90%+。如果是，立即停止 Zabbix Server 进程以保护 DB。

3. Housekeeper 配置确认：检查 Zabbix Server 配置中的 HousekeepingFrequency、MaxHousekeeperDelete。大规模场景下必须置 0 关闭，改用 DB 原生表分区或直接使用 TimescaleDB/ClickHouse 作为后端。

4. 滥用监控项审查：在 MySQL 执行 SELECT itemid, COUNT(*) FROM history_text GROUP BY itemid ORDER BY COUNT(*) DESC LIMIT 10;，揪出产生大量文本型历史数据的 Top 10 监控项（Items），并在 Zabbix 页面中直接 Disable，切断污染源。

5. 缓存击穿指标：查看 Dashboard 中的 Zabbix cache usage, % free。如果 History index cache 或 Value cache 经常跌破 5%，说明 CacheSize 和 HistoryCacheSize 配置过小，或者存在大量低频的长周期聚合查询在刷缓存。