HDUO Lab

深入 Zabbix Proxy 雪崩排查：断网恢复引发的 Trapper 耗尽与 MySQL InnoDB 锁死实战

作者：

ningniu

在

, ,

某次排查过程中，某跨机房专线发生了一次约 15 分钟的抖动，导致该机房的 Zabbix Proxy 节点与中心 Zabbix Server 短暂失联。当专线恢复的瞬间，中心 Zabbix Server 瞬间陷入瘫痪：Load Average 飙升至 120+，监控大盘变成一片空白，所有告警通道静默。最终排查结论极其经典——典型的“重试风暴与并发写入雪崩”。Proxy 在离线期间囤积了海量历史数据，恢复网络后全量、高并发地向 Server 端倾泻。Server 端的 Trapper 进程瞬间耗尽，且底层 MySQL 因未做针对性调优，在海量并发 INSERT 下触发 InnoDB 严重锁等待（Lock wait timeout）与 IO 饱和，最终拖垮了整个监控体系。

将企业级监控系统当成黑盒跑默认配置，是对生产环境的极度不负责任。监控系统的架构设计同样需要“防御性编程”思维，任何一个下游组件的故障恢复，都不应该成为压垮中心节点的最后一根稻草。

案发现场：队列爆炸与 DB 假死

故障发生时，登录中心 Zabbix Server，终端已经非常卡顿。第一时间查看系统指标与核心进程状态：

  1. 系统负载极高，IO 成为瓶颈 执行 top 发现 mysqld 进程 CPU 占用达到 600%，但更致命的是 %wa（IO Wait）高达 45%。

  2. Zabbix Server 内部运行状态崩溃 查看 /var/log/zabbix/zabbix_server.log，满屏的告警日志： text 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 [insert into history_uint (itemid,clock,ns,value) values ...] server is out of memory: out of memory (allocating 4294967296 bytes) Trapper（负责接收 Proxy 数据）和 History Syncer（负责将数据刷入 DB）进程全部处于打满状态。

  3. MySQL 锁等待与堆积 直连 MySQL 数据库，执行 SHOW PROCESSLIST，看到上百个状态为 update 的线程，全部卡在写入历史表： sql INSERT INTO history_uint (itemid,clock,ns,value) VALUES ... 查看 SHOW ENGINE INNODB STATUS\G，发现大量的 Record Lock 争用，Buffer Pool 命中率急剧下降，磁盘 IOPS 被写 Redo Log 和 Flush Page 彻底榨干。

根因剖析：为什么一次断网恢复会引发全局瘫痪？

问题的核心在于 Zabbix Proxy 的离线缓存机制 与 中心数据库的并发写入能力 极度不匹配。

在分布式架构中，Zabbix Proxy 在与 Server 断开连接时，会将采集到的监控数据缓存在本地（默认是 SQLite 或轻量 MySQL/PostgreSQL）。当网络恢复，Proxy 会尝试将离线期间积压的数据（通过 DataSenderFrequency 控制周期）打包发送给 Zabbix Server（端口 10051）。

雪崩的传导链条如下：

  1. Proxy 数据洪峰：一个承载了 10,000 NVPS（每秒新值）的 Proxy，断网 15 分钟会囤积约 900 万条数据。网络恢复后，Proxy 会以极具攻击性的方式将这些数据并发推向 Server。

  2. Trapper 耗尽：Zabbix Server 的 StartTrappers 进程负责接收这些数据，存入内存共享池。面对突发洪峰，Trapper 进程瞬间被全部分配完毕，导致其他正常的 Proxy 或 Agent Active 检查也无法建立连接，监控出现全局断点。

  3. History Syncer 阻塞：内存池迅速填满，StartHistorySyncers 进程开始疯狂从内存中提取数据拼接成 INSERT 语句写入 MySQL。

  4. MySQL InnoDB IO 饱和与锁死： 这是最致命的一环。如果 MySQL 采用了默认的 innodb_flush_log_at_trx_commit = 1，意味着每一次 History Syncer 的批量事务提交，都会强制触发一次 Redo Log 的 fsync 刷盘。 机械硬盘或普通 SSD 的 IOPS 瞬间被击穿。IO 阻塞导致 INSERT 事务执行变慢，持有的行锁或间隙锁迟迟不释放。新的写入请求被阻塞（Lock wait timeout），进而导致 History Syncer 挂起，最终内存池爆满，Zabbix Server 进程直接 OOM 崩溃。

止血与根治方案：防御性监控架构的落地

面对这种雪崩，常规的重启服务毫无意义，启动后几秒钟内又会被积压的数据再次击穿。正确的止血操作是：先切断洪峰源头，再提升消化能力。

紧急止血操作：

  1. 停掉故障节点的 zabbix_proxy 服务。

  2. 重启中心 zabbix_server，让其消化掉内存中和 DB 中积压的残余事务，确保其他机房的监控恢复正常。

  3. 如果 Proxy 积压数据已经失去时效性且无关紧要，直接清空 Proxy 侧本地 DB 的 proxy_history 表（极其暴力的断臂求生，视业务容忍度而定）。

深度调优与根治配置（必须落地的最佳实践）：

1. MySQL 底层性能释放（关键） 监控数据是典型的“写多读少、允许极少量丢失”的时序数据。严格的 ACID 对 Zabbix 历史表来说是性能毒药。

# /etc/my.cnf
# 牺牲极为罕见的 MySQL 宕机（非 OS 宕机）时 1 秒的数据，换取成百上千倍的写入性能提升
innodb_flush_log_at_trx_commit = 2 

# 将 Buffer Pool 设置为物理内存的 60%-70%，让尽可能多的数据在内存中合并写入
innodb_buffer_pool_size = 64G 

# 提升 IO 线程数，榨干 NVMe SSD 的并发能力
innodb_read_io_threads = 16
innodb_write_io_threads = 16
innodb_io_capacity = 5000
innodb_io_capacity_max = 10000

注：对于 TB 级别的企业级 Zabbix，强烈建议对 history 和 history_uint 表实施按天/周的 MySQL Table Partitioning（表分区），利用 DROP PARTITION 替代 Zabbix 自带的 Housekeeper 删除过期数据，这能彻底解决 Housekeeper 引发的数据库 CPU 毛刺死锁。

2. Zabbix Server 并发与缓冲调优 扩展 Server 的吞吐管道，并增加共享内存以缓冲洪峰。

# /etc/zabbix/zabbix_server.conf
# 增加处理 Proxy 数据的 Trapper 进程（视代理数量和内存而定）
StartTrappers=50
# 增加历史数据同步进程，加速刷盘
StartHistorySyncers=30
# 扩大缓存池，避免瞬间 OOM 或假死
CacheSize=8G
HistoryCacheSize=2G
HistoryIndexCacheSize=512M

3. Proxy 侧的防御性限流 控制离线数据的囤积量和发送频率，避免在恢复时“一波流”带走中心端。

# /etc/zabbix/zabbix_proxy.conf
# 离线数据最多保留时长（小时）。断网太久的数据直接丢弃，保全大局
ProxyOfflineBuffer=2
# 控制 Proxy 发送数据的频率，避免过高的并发连接
DataSenderFrequency=1

排查清单：Zabbix 并发写入雪崩同类问题速查

  1. 检查 Zabbix Server 内部队列与进程瓶颈：使用 zabbix_get -s 127.0.0.1 -k "zabbix[process,history syncer,avg,busy]" 获取内部指标，超过 75% 即需警惕 DB 写入瓶颈。

  2. 排查 MySQL InnoDB 锁等待：在 MySQL 执行 SELECT * FROM information_schema.innodb_trx WHERE trx_state = 'LOCK WAIT'; 揪出阻塞源头，通常是 Housekeeper 与 History Syncer 发生了锁冲突。

  3. 确认磁盘 IO 饱和度：使用 iostat -xz 1 观察 %util 和 await，如果 %util 长期 100% 且以写 IO 为主，必须立刻调整 innodb_flush_log_at_trx_commit。

  4. Housekeeper 负载自查：如果未开启 DB 表分区，检查 zabbix_server.log 中 housekeeper 每次删除数据耗时，若超过 1 分钟，必须调整 MaxHousekeeperDelete 或尽快实施分区改造。

更多文章