HDUO Lab

标签： 分布式监控

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

    某次排查过程中，某跨机房专线发生了一次约 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 或尽快实施分区改造。

  • 深入 Zabbix 监控雪崩排查：LLD 发现风暴引发的 Proxy 缓存积压与 History Syncer 夯死实战

    近期处理了一起 Zabbix 6.0 LTS 集群雪崩事故。根因是某业务线引入劣质自定义 LLD 模板，单机生成逾万监控项，引发 Proxy 缓存打满与 History Syncer 进程 100% 繁忙，最终压垮后端 DB IO 导致全局断连。核心解法：阻断异常 LLD 发现、调优 Zabbix 核心缓存参数，并将底层存储彻底迁移至 PostgreSQL + TimescaleDB 解决写入墙问题。

    故障现场：Queue 积压与 Poller 满载

    排查过程中，监控大屏首先报警的是 Zabbix Queue 严重积压，延迟超过 10 分钟的 item 数量直线飙升破 5 万。登录 Zabbix Server 核心节点，top 命令显示 Load Average 飙升至 80+，系统 iowait 长期盘踞在 40% 以上。

    查看 Zabbix Server 日志 /var/log/zabbix/zabbix_server.log，满屏都是极其致命的告警：

    Zabbix server history syncer processes more than 75% busy
Zabbix server history syncer processes more than 100% busy
server is out of memory: Out of memory (data: 256M, index: 64M)
cannot accept connection from proxy "cn-sh-proxy-01": max number of Trapper processes reached

    切到前端分布式 Proxy 节点 /var/log/zabbix/zabbix_proxy.log，同样处于崩溃边缘：

    cannot send proxy data to server at "10.0.0.10": Zabbix server connection failed
history cache is full, sleeping for 1 second

    表象很清晰：数据写不进数据库，导致 Zabbix Server 的 History Syncer（负责将内存数据刷入 DB 的核心进程）全部夯死。Server 端 Trapper 进程耗尽，导致 Proxy 无法上报数据，Proxy 本地的 HistoryCache 被打爆，最终整个监控链路瘫痪。

    为什么一个简单的自定义模板能搞垮整个监控集群？

    很多开发在写 Zabbix 监控脚本时，缺乏“防御性编程”思维。抓取故障现场的 Proxy sqlite3 库（或本地临时文件），发现罪魁祸首是一个名为 Custom_K8s_Pod_Discovery 的 LLD (Low-Level Discovery) 脚本。

    该脚本通过 Python 遍历全量 Pod 状态，但没有做任何 Limit 限制和状态机过滤。单台 Kubernetes Node 上的脚本直接返回了近 5MB 的 JSON Array：

    {
  "data": [
    {"{#PODNAME}": "web-api-7b89f...", "{#NAMESPACE}": "prod", "{#CONTAINER}": "nginx"},
    // ... 往下还有 15000+ 个对象
  ]
}

    Zabbix LLD 引擎在处理这个宏大 JSON 时，会为每一个 {#PODNAME} 动态生成 5 个 Item（CPU、内存、网络 IO 等）。 算一笔账：1 台机器抛出 15000 个实体 $\times$ 5 个 Item = 75000 个监控项。 如果是 100 台节点的集群，瞬间生成 750 万个新监控项。

    这些海量监控项每 30 秒采集一次数据，疯狂涌入 Zabbix Proxy。 Proxy 的默认 HistoryCacheSize 仅有区区 16M，瞬间被打满。随后 Proxy 将庞大的 Payload 塞给 Zabbix Server，Server 端的 History Syncer 试图将这几百万条并发写入后端的 MySQL history_uint 表。MySQL InnoDB 面对这种毫无规律的极高频并发 Insert，B+ 树页分裂严重，NVMe 磁盘的 IOPS 直接打满，写延迟达到 500ms 以上，彻底堵死。

    架构级改造：从 MySQL 到 PG+TimescaleDB

    在千万级 Item 的企业监控场景下，MySQL 表分区脚本（如常用的 partitioning.sql 存储过程）不仅维护极其痛苦，且对历史数据的清理依然会产生锁争用。

    解决写入瓶颈的最终态方案，是利用原生时序数据库。Zabbix 从 5.0 开始深度支持 PostgreSQL + TimescaleDB 扩展，将 history 相关的表转化为 hypertable，实现按时间维度的透明 Chunk 分片。

    迁移与落地步骤：

    1. 部署 PostgreSQL 14 与 TimescaleDB 插件。

    2. 导入 Zabbix 基础 Schema 后，务必执行 TimescaleDB 转换脚本：

    # Zabbix 6.0 环境下开启 TimescaleDB 支持
zcat /usr/share/doc/zabbix-sql-scripts/postgresql/timescaledb.sql | sudo -u zabbix psql zabbix
    1. 在 Zabbix Server 开启内部历史数据压缩（极大降低磁盘 IO 并节省 70% 空间）：
    -- 连接到 zabbix 库
UPDATE config SET db_extension='timescaledb', history_compression_status=1, history_compress_older='7d';

    切换到 TimescaleDB 后，Zabbix History Syncer 的写操作变成了针对内存中最新 Chunk 的顺序追加写（Append-only），避开了全表扫描和巨型 B-Tree 维护，单机轻松抗住 10万+ QPS 的监控项写入。

    调优与防御性配置落地

    底层存储问题解决后，必须对 Zabbix 核心配置进行防御性加固，防止类似 LLD 风暴再次冲垮服务。

    1. Zabbix Server 核心参数重调

    编辑 /etc/zabbix/zabbix_server.conf：

    # 根据物理内存，大幅提高历史缓存，作为 DB 抖动时的缓冲池
HistoryCacheSize=2G
HistoryIndexCacheSize=256M
ValueCacheSize=1G

# 增加数据刷盘进程数（需结合 DB 最大连接数考量）
StartHistorySyncers=30

# 增加处理 Proxy 和 Agent 主动上报的 Trapper 进程
StartTrappers=100

# 禁用 Server 端轮询，强制全部走 Proxy 分布式采集
StartPollers=0

    2. Zabbix Proxy 缓冲防御

    编辑 /etc/zabbix/zabbix_proxy.conf：

    # 提高 Proxy 侧的缓存，容忍更长时间的 Server 端断连
HistoryCacheSize=1G
HistoryIndexCacheSize=128M

# 严格控制外部脚本超时时间，防止进程卡死（默认3秒，最大不超过10秒）
Timeout=10

    3. 数据预处理（Pre-processing）截流

    针对自定义监控项，强制要求在 Zabbix Web UI 的 Item Preprocessing 中配置以下规则：

    • Discard unchanged with heartbeat (心跳抑制): 如果监控值没有变化，直接在 Proxy/Server 端丢弃，只在达到 heartbeat（如 1 小时）时强制写入一次。这能削减 60% 以上的无用状态写入。

    • 正则表达式过滤: 对 LLD 发现的文本进行白名单截断，丢弃非核心进程的数据。

    常见问题

    Q1: Proxy 报错 “Zabbix server connection failed”，但网络 Ping 和 Telnet 都通，如何排查？ 通常不是网络问题，而是 Zabbix Server 端的 Trapper 进程全忙。检查 Zabbix Server 监控大屏上的 Zabbix server trapper processes busy 指标是否达到 100%。若是，需调大 StartTrappers，或检查是否有超大 Payload 正在阻塞网络层解析。

    Q2: 监控项经常出现断点，日志提示 “first network error, wait for 15 seconds”，如何优化？ 这是 Poller 进程在执行某些慢请求（如大文本抓取、远端 API 调用）时超时了。Zabbix 默认超时 Timeout=3 秒。建议将耗时任务改成 Agent 端的异步 Crontab 写入本地文件，Zabbix 只做简单的 vfs.file.contents 读取；或者将 Timeout 谨慎上调至 10。

    Q3: 迁移到 TimescaleDB 后，Zabbix 的 Housekeeper 还需要开启吗？ 绝对不需要对历史表开启。开启 TimescaleDB 后，应在 Zabbix UI 的 “Administration -> General -> Housekeeping” 中，勾选 Override item history period 并启用内部机制。旧数据的清理会由 DB 原生的 drop_chunks() 函数瞬间完成，而不是 Housekeeper 一行行执行极度耗 IO 的 DELETE 语句。

    Q4: 怎样防止自定义 LLD 脚本再次引发灾难？ 运维必须剥夺业务组直接创建 LLD Template 的权限。通过 CI/CD 管道扫描业务侧提交的脚本，限制 LLD 返回的 JSON 最大数组长度（如不超过 200）。此外，在 Zabbix 中利用 “LLD overrides” 功能，强制要求匹配特定正则的对象才能触发 Item 发现。

  • 深入 Zabbix 监控雪崩排查：Proxy 积压引发的 History Syncer 阻塞与数据库底层调优实战

    Zabbix 队列风暴的元凶往往不是 Server 计算能力不足，而是底层数据库 IO 瓶颈与 Proxy 离线数据猛灌。本文通过排查某次 NVPS 突发至 35k 导致的 History Syncer 打满与监控瘫痪事件，深入解析 MySQL 8.0 针对 Zabbix 写入优化的底层逻辑，并给出 Proxy 防御性配置与模板预处理过滤的实战方案。

    故障现场：History Syncer 进程 100% 死亡螺旋

    某次排查过程中，一套承载 20,000+ 主机、2,000,000+ 监控项的 Zabbix 6.0.22 LTS 集群突发严重告警。现象非常典型：

    1. Zabbix Queue 爆炸：延迟超过 10 分钟的 item 数量瞬间飙升到 150,000 以上。

    2. 内部进程打满：Zabbix Server 告警 Zabbix server history syncer processes more than 100% busy。

    3. 前端瘫痪：Web 界面卡死，报 Zabbix server is not running: the information displayed may not be current。

    查看 zabbix_server.log，满屏的慢查询和超时：

    23851:20231012:142211.512 [Z3005] query failed: [1205] Lock wait timeout exceeded; try restarting transaction [insert into history_uint (itemid,clock,ns,value) values (152342,1697101321,213412,0),(...)]
23851:20231012:142215.123 server #12 active [history syncer #4]
23851:20231012:142215.123 Zabbix server history syncer processes 100% busy

    很明显，数据落盘卡住了。History Syncer 负责将内存 cache 中的监控数据批量写入底层 MySQL。一旦它被阻塞，Server 内存中的 History Cache 会迅速耗尽，触发自我保护机制，拒绝接收任何新数据，最终导致 Poller 和 Trapper 进程全部雪崩。

    登陆底层 MySQL 8.0.34 节点，敲下 iostat -x 1，看到数据盘的 %util 稳稳地锁死在 100%，await 高达 200ms+。

    为什么 Proxy 断网恢复会导致 Zabbix Server 瞬间雪崩？

    排查发现，在雪崩发生前 15 分钟，某跨机房专线发生了短暂抖动。该机房部署了 3 台 Zabbix Proxy（Active 模式），承载了约 8,000 台主机的监控抓取。

    这里牵扯到 Zabbix Proxy 的底层工作机制。Proxy 默认会将采集到的数据暂存在本地的 SQLite3（或 MySQL）中。当与 Server 断开连接时，Proxy 会根据 ProxyOfflineBuffer 的配置（默认 1 小时）在本地堆积数据。

    雪崩的逻辑链条：

    1. 专线抖动，3 台 Proxy 与 Server 失联，期间不断采集并缓存数据到本地。

    2. 专线恢复，Proxy 瞬间将积压的数十万条历史数据打包。

    3. Proxy 根据 DataSenderFrequency=1（每秒发送）无脑向 Server 的 Trapper 进程猛灌。

    4. Server 的 Trapper 进程将海量数据塞入 History Cache。

    5. History Syncer 进程全速运转，向 MySQL 发起天量 INSERT INTO history... 请求。

    6. MySQL InnoDB Buffer Pool 的脏页刷新速率跟不上写入速率，Redo Log 爆满，触发同步刷盘，导致 IO 彻底僵死。

    防御性配置：限制 Proxy 突发流量

    为了防止类似情况再次发生，必须对 Proxy 的回传机制进行限流。

    1. 调优 Proxy 端缓存发送频率与体积 不要让 Proxy 一次性将积压数据全吐出来。在 zabbix_proxy.conf 中调整：

    # ProxyOfflineBuffer=1 # 离线缓存保留时间，不要设置太大，无意义的历史数据宁可丢弃
DataSenderFrequency=1
# 增加批量发送的限制（隐式受制于 Server 端 Trapper 进程处理能力）

    注：Zabbix 6.0 引入了 Proxy 内存缓存机制，但在面对海量离线回传时，核心仍是保护 Server 的 DB IO。

    2. 调优 Server 端接收与刷盘并发 在 zabbix_server.conf 中调整：

    # 控制 Trapper 进程数，不要无限调大，防止压垮 History Cache
StartTrappers=50
# 增加 History Cache 大小，做大内存缓冲池，争取时间
HistoryCacheSize=2G
HistoryIndexCacheSize=512M
# 增加 Syncer 进程数，但不要超过 DB 磁盘阵列的物理 IO 并发能力上限
StartHistoryPollers=20

    数据库底层调优：拯救被压垮的 MySQL 8.0

    Zabbix 是一个典型的“读少写极其密集”的系统，标准的 MySQL 默认配置在这里就是灾难。针对本次 IO 瓶颈，我们在 my.cnf 中进行了以下针对性调优。

    1. 禁用 Doublewrite Buffer 与放宽事务持久性

    由于 Zabbix 数据并非金融级账本，丢失一两秒的监控数据完全可以接受。

    [mysqld]
# 核心：将事务刷盘策略改为 2。每次提交仅写入 OS Cache，每秒刷盘一次。
# 直接将 IOPS 需求降低一个数量级。
innodb_flush_log_at_trx_commit = 2

# 针对支持原子写的存储设备（如现代 NVMe SSD 或部分企业级 SAN），关闭双写缓冲
innodb_doublewrite = 0

# 优化 Redo log 大小，防止频繁触发 Checkpoint 导致 IO 抖动
innodb_redo_log_capacity = 4G # MySQL 8.0.30+ 的新参数，替代旧的 innodb_log_file_size

    2. 匹配硬件的 InnoDB IO 刷盘能力

    MySQL 默认假设你的磁盘很慢（innodb_io_capacity=200），这会导致在 SSD 环境下脏页刷得太慢，最终堆积引发急剧抖动。

    # 根据实际 FIO 测试结果配置
innodb_io_capacity = 3000
innodb_io_capacity_max = 6000
innodb_flush_sync = OFF # 避免 Checkpoint 时卡死用户查询

    3. 表分区与废弃 Housekeeper

    导致底层 IO 缓慢的另一个隐患是 Zabbix 自带的 Housekeeper 清理进程。它通过 DELETE FROM history WHERE clock < ... 清理过期数据，这在海量数据下会产生巨大的锁竞争和 Undo Log 开销。

    必须彻底关闭 Housekeeper 对历史表和趋势表的清理： Web 界面：Administration -> General -> Housekeeping，关闭 History and Trend 的 Enable internal housekeeping。

    替代方案：使用 MySQL 表分区（Table Partitioning）。 每天为 history、history_uint、history_str 等表建一个新分区，清理数据时直接 ALTER TABLE ... DROP PARTITION，这是元数据操作，耗时 0.1 秒，没有任何 IO 负担。

    自定义模板防作死指南：在 Proxy 侧掐断垃圾数据

    数据库调优只是续命，真正的治本之策是降低 NVPS（New Values Per Second）。排查中发现，某开发团队的自定义模板中，有一个抓取应用日志错误状态的 item，类型居然是 Text，且每 5 秒抓取一次。无论状态是否改变，全量文本都在往 DB 里塞，直接打爆了 history_str 表。

    过滤绝招：Discard unchanged with heartbeat

    利用 Zabbix 的 Preprocessing（预处理）功能，直接在 Proxy 内存中过滤掉无用数据，根本不让它通过网络发给 Server。

    配置步骤：

    1. 打开 Item 的 Preprocessing 选项卡。

    2. 添加 Step：Discard unchanged with heartbeat。

    3. 参数设置为 1h（或 3600s）。

    原理解析： 如果该 Item 的值相比上次抓取没有发生变化，Proxy 会直接将这个数据丢弃，不往 Server 发送。只有当值发生变化，或者超过设定的 heartbeat 时间（比如 1 小时没有变化），才会发送一次数据保持激活。 仅仅配置了这一项，我们的整体 NVPS 从 35,000 直接断崖式下降到 12,000，MySQL IO 负载瞬间降至 15% 以下。

    常见问题

    Q1：Web 界面经常报 Zabbix Server is not running，但查看进程都在，怎么回事？ 通常是因为 PHP 前端通过 TCP 10051 端口请求 Server 的 StartTrappers 进程超时。大概率是因为 History Syncer 阻塞，导致 Trapper 进程全都在等待获取 Cache 锁。检查数据库负载，或适当增加 StartTrappers 数量。

    Q2：StartPollers 到底设置多少合适？为什么我设了 1000 还是不够？ 千万不要无脑调大 Poller 数量。Poller 过多会导致严重的上下文切换和内存消耗。查看 Zabbix server data collector processes 图表，如果 Poller 使用率长期 > 75%，首先应该考虑将监控项改为 Active 模式（让 Agent 主动推），或者把采集任务剥离给下层 Proxy。

    Q3：存在大量 SNMP 监控导致 Poller 经常超时卡死，如何缓解？ SNMP 采用 UDP，极易丢包阻塞。最佳实践：1) 将 SNMP 采集全部下放给专属的 Zabbix Proxy，将故障隔离；2) 在 Host 级别勾选 Use bulk requests；3) 在 zabbix_server.conf 和 zabbix_proxy.conf 中增加 Timeout=15（默认只有 3 秒，对于老旧交换机绝对不够）。