结论先行：某次 Zabbix 6.0 LTS 分布式集群雪崩，根因是自定义模板中滥用极其复杂的 JSONPath 与正则预处理，导致 Proxy 端 Preprocessing Worker 长期 100% 满载。堆积的历史数据在洪峰释放时，由于大量乱序时间戳，瞬间击穿后端 PostgreSQL 14 (TimescaleDB) 的 Chunk 写入性能，引发 Server 端 History Syncer 全面夯死。核心解法是将重度解析逻辑下沉至 Agent 端侧（边缘计算），并调优 TimescaleDB 历史数据的乱序写入内存参数。
故障现场：Proxy 频繁断连与 Server 端 P99 延迟飙升
排查过程中，核心监控集群突然触发大面积“Zabbix proxy is unreachable”告警。初步观察 Zabbix Server 的核心指标，发现 P99 内部处理延迟从平时的 50ms 飙升至 3s 以上，同时 History Syncer 进程利用率直线打满到 100%。
登入其中一个出问题的 Proxy 节点抓取状态：
# 检查 Proxy 内部进程状态
zabbix_get -s 127.0.0.1 -k "zabbix[process,preprocessing worker,avg,busy]"
100.000000
# 查看 Proxy 日志，大量连接超时与积压
tail -n 50 /var/log/zabbix/zabbix_proxy.log
1345:202X1108:101231.123 Zabbix agent item "app.api.stats" on host "API-Server-01" failed: first network error, wait for 15 seconds
1320:202X1108:101345.543 proxy data dispatching delayed by 4520 seconds
更致命的是，当 Proxy 的 preprocessing worker 艰难处理完积压数据，开始向 Zabbix Server 批量推送时，Server 端的数据库层直接“躺平”。PostgreSQL 服务器的 Load Average 飙升至 120，磁盘 iowait 持续在 60% 以上。
为什么自定义模板的预处理会拖垮整个 Proxy 分布式架构？
在 Zabbix 的分布式架构中，Proxy 不仅仅是数据转发器。从 Zabbix 4.2 开始，为了减轻 Server 压力，所有的指标预处理（Preprocessing）都被前置到了 Proxy端执行。
在本次故障中，业务团队新接入了一个自定义模板，通过 HTTP Agent 主动拉取某个中间件的 /metrics 接口。该接口返回一个高达 3MB 的巨型 JSON 文本。该模板定义了 1 个 Master Item，并挂载了 800 多个 Dependent Items，每个 Dependent Item 都配置了复杂的 JSONPath 提取规则，外加正则表达式（Regular Expression）进行二次清洗。
底层原理在于：Zabbix 的预处理架构基于 Master-Worker 的进程间通信（IPC）模型。
preprocessing manager 接收到原始数据后，通过 Unix Socket 将庞大的 3MB 文本复制、分发给底层的 preprocessing worker。800 个 Dependent Item 意味着这 3MB 的文本要在内存中被拷贝并执行 800 次复杂的 JSONTree 解析与正则匹配。
当数百台主机同时拉取该指标时，Proxy 的 CPU 缓存和 IPC 队列瞬间被挤爆：
// zabbix/src/zabbix_proxy/preprocessing/preprocessing.c (伪代码逻辑)
// 每次执行预处理步骤时，巨大的 values 字符串需要在 manager 和 worker 之间传递
zbx_ipc_message_t *message;
zbx_ipc_client_send(client, ZBX_IPC_PREPROCESSOR_REQUEST, data, data_size);
单靠修改 zabbix_proxy.conf 里的 StartPreprocessors=50 根本无济于事，只会让系统的 Context Switch 飙升，加速内存 OOM。
数据库后端崩塌：TimescaleDB IOPS 饱和与 History Syncer 夯死
Proxy 积压了数小时的数据后，当处理完成并批量推给 Server 时，真正的灾难在数据库层爆发。Zabbix Server 的 History Syncer 进程开始向 PostgreSQL 疯狂写入 history 和 history_uint 表。
由于这批数据带有数小时前的历史时间戳，它们触发了 TimescaleDB 最惧怕的场景：跨 Chunk 的大批量乱序写入（Out-of-order writes）。 正常情况下，TimescaleDB 写入最新的 Chunk，完全在内存中顺序追加，速度极快。但大量几小时前的积压数据涌入，导致 PostgreSQL 不得不将之前已经压缩并落盘的多个旧 Chunk 重新加载到内存中执行解压、插入、再压缩操作。
通过 pg_stat_activity 捕获到了大量的锁争用：
SELECT pid, wait_event_type, wait_event, query
FROM pg_stat_activity
WHERE state = 'active' AND query ILIKE '%INSERT INTO history_uint%';
-- 结果显示大量进程阻塞在 IO 和 LWLock 上
pid | wait_event_type | wait_event | query
------+-----------------+----------------+----------------------------------------
24102 | IO | DataFileRead | INSERT INTO history_uint (itemid, clock, ns, value) ...
24103 | LWLock | buffer_mapping | INSERT INTO history_uint (itemid, clock, ns, value) ...
buffer_mapping 锁的集中爆发，证明 shared buffers 正在被高频的 Chunk 换页操作击穿，底层的 NVMe 硬盘 IOPS 被完全打满。
架构优化与防御性配置落地
为了彻底解决这一类“监控即雪崩”的问题，我们需要从采集端、传输端和存储端进行三维阻断。
1. 采集端：预处理逻辑下沉（Shift-Left Parsing）
不要在 Zabbix 中处理 GB 级别的正则和 JSON 解析。改用 Zabbix Agent 的 UserParameter 或外部脚本，利用 jq 这样的底层 C 工具在客户端机器本地完成数据扁平化，仅将解析好的 Key-Value 上报给 Zabbix。
如果必须保留 HTTP Agent 拉取，强制要求研发侧提供精简版 Metrics 接口，拒绝接收超过 50KB 的 JSON 报文。
2. 传输端：Proxy 预处理并发与积压限流
在 zabbix_proxy.conf 中，防御性地配置预处理进程，并控制向 Server 同步积压数据的速率：
# 限制预处理 Worker 数量，避免耗尽 Proxy 所在机器的 CPU
StartPreprocessors=15
# 避免 Proxy 恢复时向 Server 形成积压数据洪峰
ProxyDataFrequency=1
3. 存储端：TimescaleDB 的乱序写入与 Chunk 调优
调整 PostgreSQL 配置以应对偶发的乱序历史数据。增加 max_locks_per_transaction，并调优 TimescaleDB 的 Chunk 跨度与压缩策略。
在本次故障后，将 history_uint 的 chunk 时间跨度修改为 1 天（原默认或较小值可能导致过多的小 chunk 被频繁换入换出），并推迟压缩时间，给乱序数据留出缓冲窗口：
-- 修改 Chunk interval 为 1 天（86400000 毫秒）
SELECT set_chunk_time_interval('history_uint', 86400000);
-- 调整压缩策略，允许两天内的乱序数据直接写入未压缩的 Chunk
SELECT remove_compression_policy('history_uint');
SELECT add_compression_policy('history_uint', INTERVAL '2 days');
同时调整 postgresql.conf，将 shared_buffers 扩大至系统内存的 25%-40%，并设置 maintenance_work_mem = 2GB，加速 Chunk 的维护操作。
常见问题
Q1：如何快速定位是哪个自定义模板的哪个 Item 堵死了 Proxy 的 Preprocessing Queue？
在 Zabbix Server 上执行 SQL 查询，找出包含复杂正则或长 JSONPath 的大范围应用项：
SELECT h.host, i.name, p.params FROM item_preproc p JOIN items i ON p.itemid = i.itemid JOIN hosts h ON i.hostid = h.hostid WHERE p.type IN (11, 12); （11=XML XPath, 12=JSONPath）。或者通过打开 Proxy 的 DebugLevel=4，结合 grep "preprocessing worker" 过滤慢解析的 itemid。
Q2：Proxy 在高并发 IO 下，本地的 SQLite3 数据库频繁出现 “database disk image is malformed” 损坏，如何解决？
企业级环境（特别是 NVPS > 500 的场景）严禁在 Proxy端使用 SQLite。其文件级锁极易在磁盘 IO 高负载时造成数据损坏。建议一律替换为 MySQL (InnoDB) 或 PostgreSQL，并配置合理的 innodb_buffer_pool_size。
Q3：Zabbix Server 的 History Syncer 经常出现 100% busy，但后端数据库 IO 和 CPU 利用率都很低，这是为什么？
检查 Zabbix Server 的 ValueCacheSize。如果 Value Cache 内存耗尽或命中率极低（大量触发低频冷数据查询），History Syncer 会被迫在同步写入的同时去数据库执行同步的 SELECT 读操作来刷新 Cache，由于单线程阻塞等待返回，导致进程自身 busy，但这不会在数据库层体现为高资源消耗。解决思路是大幅提高 zabbix_server.conf 中的 ValueCacheSize。