上一篇把采集压力分散到 Proxy，但 Proxy 只能搬走部分采集工作，中心 Server 仍要接收数据、执行预处理、计算触发器、生成事件并写入数据库。监控规模扩大后，真正困难的不是找到一组“高性能参数”，而是识别当前瓶颈究竟位于采集、接收、预处理、缓存、数据库、housekeeping、触发器还是前端，并证明一次调整确实改善了目标。

本文以 Zabbix 7.0 LTS 为主要范围，把性能优化写成一套可重复的运行方法。它不提供脱离环境的“推荐参数表”，也不假设增加进程和内存一定有效。你将建立性能基线，读取 Zabbix internal items，判断队列和缓存，分析模板与采集间隔，理解数据库保留策略，设计变更、验证和回退。对于 MySQL、PostgreSQL、TimescaleDB 或其他受支持组合，具体数据库参数仍应由数据库负责人结合版本、内存、存储和工作负载决定。

性能问题先按数据路径定位

一条监控值从对象到图表，至少经过采集或接收、预处理、历史缓存、数据库同步、触发器计算、历史与趋势存储、API 或前端查询。任何一段饱和，用户看到的都可能是“最新数据延迟”或“页面很慢”。如果只盯 CPU 和内存，很容易在错误层面调参。

采集层瓶颈常见于被动 Agent、SNMP、HTTP、ODBC、JMX、IPMI 和外部检查。它们占用不同类型的 poller，慢响应和长超时会让进程长期繁忙。接收层瓶颈多见于大量主动 Agent、sender 或 Proxy 同时上报，trapper 和网络连接压力上升。预处理层瓶颈通常来自复杂 JavaScript、正则、Prometheus 文本解析、SNMP walk、依赖监控项扇出和错误重试。

写入层瓶颈表现为 write cache 待写数据增长、database syncer 繁忙、数据库延迟和磁盘 I/O 上升。触发器和值缓存问题则可能导致触发器计算频繁访问数据库。housekeeping 处理大量过期数据时会和在线写入争夺资源。前端慢可能源于大时间范围查询、仪表盘 Widget 过多、宏或权限解析、PHP 资源、数据库慢查询，也可能只是浏览器一次请求了过多数据。

Zabbix 内部性能指标看板

性能诊断的第一原则是沿数据路径找证据，而不是先修改配置。第二原则是区分瞬时峰值和持续饱和。某进程在整点短暂繁忙可能来自定时检查；持续接近满负荷并伴随队列增长，才说明供给长期不足。第三原则是先减少无效工作，再增加资源。一个错误模板每分钟采集几千个无用 item，增加 poller 只会让无效数据更快进入数据库。

建立可比较的性能基线

优化之前至少连续观察一个完整业务周期。普通环境可以覆盖一天，存在周末批处理、月结或备份窗口的环境要覆盖相应周期。基线需要同时记录业务输入、Zabbix 内部状态、操作系统、数据库和用户体验，单独一张 CPU 曲线不足以说明问题。

业务输入包括启用主机数、启用 item 数、required performance、主动与被动比例、Proxy 数、协议分布、日志型 item、低级发现规则、网页场景、当前问题数和前端并发。Zabbix 官方 internal checks 提供 zabbix[requiredperformance]，它近似对应系统信息中的“Required server performance, new values per second”。该值反映配置预期，不等于数据库实际写入。Zabbix 7.0 还提供 zabbix[vps,written] 观察实际写入数据库的历史值数量。

内部状态至少覆盖进程繁忙度、queue、配置缓存、写缓存、值缓存、趋势函数缓存、版本和运行时间。具体 key 及支持范围应以目标版本的 Internal checks 文档为准，不要从旧文章复制进程名称。Zabbix 7.0 对部分采集架构做过异步化和进程调整，例如网络发现使用 discovery manager 与 workers，因此跨版本对比时必须先确认指标语义。

操作系统侧记录 Server 与数据库节点的 CPU 使用和负载、内存与交换、磁盘延迟和队列、文件系统使用率、网络吞吐和丢包、进程重启、内核或文件描述符错误。数据库侧记录连接数、事务率、检查点或刷盘、缓存命中、锁等待、慢查询、表和索引大小、自动清理或维护状态。前端侧记录常用页面的响应时间、超时、PHP 或 Web 日志，以及具体查询范围。

推荐建立一张变更前基线表：

类别 指标 观察窗口 当前表现 目标
输入 required performance、实际写入 VPS 高峰与平峰 记录曲线 解释增长来源
队列 按延迟区间的 item 数 全天 是否持续累积 高峰后可回落
进程 各类 process busy 全天 饱和类型与时段 留有恢复余量
缓存 free、used、pused、pending 全天 是否逼近边界 不进入低内存状态
数据库 写延迟、锁、I/O、慢查询 全天 与 Zabbix 峰值关联 无持续写入阻塞
体验 最新数据延迟、页面响应 典型操作 可复现症状 达到业务目标

基线中的“目标”要从业务出发。例如告警允许延迟多少秒、断网回传需要多久完成、常用仪表盘允许多长加载时间、维护窗口可以接受多长暂停。没有目标就无法判断是性能问题还是主观感受，也无法决定是否值得承担调优风险。

用队列判断采集是否跟得上

Zabbix queue 表示预期执行时间已到但尚未完成的监控项。它是采集延迟的重要证据，但不能单独判定 Server 算力不足。目标不可达、DNS 失败、SNMP 超时、脚本阻塞、Proxy 离线和错误的更新间隔都会造成队列。

先按延迟区间观察队列。如果少量 item 在短延迟区间波动并很快回落，通常属于正常抖动；如果多个区间持续增长，需要按 item type、Proxy、主机组和接口缩小范围。队列集中在一个 Proxy，优先检查该 Proxy 和链路；集中在 SNMP，检查设备响应、并发和超时；集中在 unavailable 主机，检查不可达处理和模板是否仍保留大量检查。

不要看到 queue 就立即增加 StartPollers。更多进程会增加内存、数据库连接或网络并发，还可能同时打向响应缓慢的设备。正确顺序是识别队列类型，抽样验证目标响应，检查对应进程繁忙度和日志，确认当前并发确实不足，再小幅调整并观察。对于支持异步采集的类型，还应核对 MaxConcurrentChecksPerPoller 等当前版本参数，不能沿用旧版本“一个 poller 一次一个检查”的假设。

不可达主机需要单独治理。一批已下线但未禁用的设备会反复进入不可达流程，消耗 unreachable poller 和网络超时。主机生命周期应和资产、下线流程联动；计划维护使用维护窗口；长期不可用对象及时禁用。把超时从三秒增加到三十秒通常不会让设备恢复，只会让进程被占用更久。

从进程繁忙度找到拥塞点

zabbix[process,...] 系列 internal item 可以观察不同 Server 或 Proxy 进程的忙、闲状态。进程名称和参数在版本间可能变化，建立模板时要以官方文档和当前进程列表为准。判断时同时看平均、最大和时间分布，避免用单个尖峰下结论。

poller 繁忙时，先按检查类型分组。普通 poller、unreachable poller、HTTP agent poller、SNMP poller、pinger、Java poller、VMware collector 的工作不同。若只有一种类型饱和，应优化对应模板、依赖和目标端，而不是扩大所有进程。大量简单检查可以考虑主动 Agent 或 Proxy 分担；慢 SQL 应优化查询和数据库权限；HTTP 检查应限制响应体和超时。

trapper 繁忙时，检查主动 Agent、sender、Proxy 回传是否在同一时刻集中，网络是否存在重传，以及 Server 日志是否出现连接或处理异常。大量 Proxy 在中心恢复后同时回传，会产生短时峰值。此时除了进程数，还要观察预处理和数据库是否能接住后续数据，否则把入口加宽只会把瓶颈推到下一层。

preprocessing manager 或 worker 繁忙时，列出高频且包含预处理步骤的 item。依赖监控项可以减少重复采集，但一个 master item 扇出大量 dependent item，也会产生预处理工作。JavaScript、复杂正则和大文本解析应使用代表性数据测试；失败时反复重试或保留大文本会进一步放大成本。能在采集端过滤的内容，不要全部传到中心再丢弃。

history syncer 或数据库同步相关进程繁忙，且写缓存 pending 增长时，说明历史值进入数据库的速度跟不上。先检查数据库、存储和锁，不要只增加 syncer。更多同步进程可能提高并发，也可能增加锁和 I/O 竞争。数据库已经饱和时，继续增加写入者会恶化延迟。

alerter、escalator 或与通知相关进程繁忙，通常与告警风暴、媒介超时、Webhook 失败和重试有关。应先处理根因、事件关联、依赖、维护窗口和通知端容量。性能优化不能把“更快发送十万条重复告警”当作成功。

正确理解缓存

Zabbix Server 与数据库参数协同调优

Zabbix 使用多类共享内存缓存降低数据库访问并吸收短时波动。CacheSize 对应配置缓存；HistoryCacheSize 和 HistoryIndexCacheSize 服务于历史数据处理；TrendCacheSize 服务于趋势；ValueCacheSize 为触发器和计算提供近期值。当前版本还包含其他与特定功能相关的缓存，必须根据实际功能和官方参数文档判断。

缓存不足的证据不是“配置值看起来小”，而是 internal item 显示使用率长期逼近边界、free 很低、value cache 进入 low memory mode、日志明确报告共享内存不足，或写缓存 pending 在数据库短暂波动后无法恢复。若缓存使用稳定，盲目扩大只会占用内存，甚至迫使操作系统交换，反而降低性能。

配置缓存不足通常与主机、item、触发器、宏和配置规模有关。扩大前先清理废弃对象和失控 LLD。配置缓存调整后要确认进程启动和加载时间。值缓存低内存模式说明近期历史值无法有效保留，触发器计算可能更多访问数据库；除扩大缓存外，也要检查长时间窗口触发器、重复函数和不合理的表达式。

写缓存用于在写入数据库前暂存数据。pending 持续增长时，缓存只是延迟暴露数据库瓶颈。扩大它可以吸收短时写入抖动，但不能解决长期吞吐不足。每次调整都要计算总共享内存、进程私有内存、数据库客户端、操作系统页缓存和安全余量，不能把物理内存全部分配给 Zabbix。

缓存变更通常需要重启 Server，应放在维护窗口。变更前记录所有 cache internal item、进程内存和交换；变更后验证服务启动、配置加载、数据接收、触发器和前端，并持续观察至少一个高峰周期。如果新配置导致系统开始交换或其他服务内存不足，应立即回退。

优化采集配置比扩容更优先

Zabbix 监控项优化策略

监控系统最常见的浪费来自模板。通用模板为了覆盖更多场景，可能包含现场不需要的文件系统、接口、服务、日志和发现规则。模板上线前应建立“采集目的、使用者、保留期、告警或看板用途”四项检查。无法说明用途的 item 不应仅因为模板已有就长期启用。

采集间隔应匹配信号变化速度和处置速度。容量规划类指标没有必要每秒采集，故障检测类指标也不能全部延长到十五分钟。可以把指标分成快速故障信号、常规性能信号、容量趋势和审计状态，再分别设置更新间隔。触发器窗口要与间隔配套，避免五分钟采一次却使用几十秒窗口。

主动 Agent 适合大量主机和受限网络，可以减少 Server 主动轮询连接；被动 Agent 便于中心按需检查。选择依据是网络、安全、连接模式和运行管理，不应把主动模式宣传成任何环境都更快。对于跨地域对象，Proxy 仍是重要边界。

dependent item 适合一次取回结构化数据后拆分多个值，能减少对目标系统的重复请求。例如一个 HTTP 或 Agent master item 获取一组状态，再通过 JSONPath 等步骤生成 dependent item。但 master payload 过大、频率过高或依赖数量失控，会把压力转移到网络、预处理和存储。需要比较“减少的远程请求”和“增加的中心处理”。

LLD 规则必须有过滤、覆盖和生命周期策略。容器、临时接口、短生命周期文件系统和动态进程可能生成大量实体。过滤无关对象，为不同匹配条件设置不同间隔或保留，及时删除失效实体。观察 discovered item 和 trigger 的增长率，防止一次模板变更让配置缓存和数据库突然膨胀。

日志型 item 要限制匹配范围、文件轮转行为、每秒处理量和保留期。把完整应用日志长期写入 Zabbix 通常不是最佳选择；Zabbix 更适合提取故障事件或关键计数，全文检索应交给日志平台。错误的正则会产生大量无用值，也可能占用 Agent 和预处理资源。

触发器优化重点是减少无意义计算和告警风暴。使用触发器依赖表达上下游关系，合理设计恢复条件和滞回，避免多个模板对同一故障重复告警。长窗口趋势判断可使用适合的趋势函数，但要核对目标版本支持和数据保留。表达式越复杂越要用真实数据验证，不要只确认语法通过。

数据保留与 housekeeping

Zabbix 数据库增长主要来自 history、trends、events、problems、audit、discovery 等数据。history 保存原始值，trends 保存小时级聚合，两者用途不同。保留期应该由故障排查、容量分析、审计和成本共同决定，不是所有 item 都使用同一时间。

短期排障需要原始粒度，长期容量通常使用趋势即可。对变化慢且只用于年度容量的指标，可以缩短 history、保留较长 trends；对日志和文本，如果没有审计要求，应更谨慎地控制保留。保留策略调整前要确认仪表盘、报表、触发器函数和外部查询是否依赖原始数据。

housekeeping 会删除过期数据。大规模环境中，长期积压后一次删除大量记录可能产生数据库压力。官方 HousekeepingFrequency 和 MaxHousekeeperDelete 参数控制相关行为，但设置方式要结合版本和数据库。不要简单把 housekeeping 关闭后忘记数据生命周期，也不要在业务高峰执行重型清理。

Zabbix 数据库分区与历史数据清理流程

数据库分区或 TimescaleDB hypertable 可以改善时间序列数据维护，但这属于数据库架构变更，不是一段通用脚本。不同 Zabbix 版本、数据库引擎、已有表状态和升级路径差异很大。生产环境应采用 Zabbix 官方支持的数据库方案和对应文档，先备份并在等规模副本演练。不要直接运行来源不明、包含动态 SQL 和明文密码的分区脚本。

分区的收益主要在于按时间管理数据和删除旧分区，但它不会自动修复慢磁盘、错误查询或失控采集。分区键、未来分区创建、旧分区删除、索引、备份、复制、升级和监控都需要长期维护。实施前要写明负责人和失败回滚，而不是把脚本放进 crontab 就视为完成。

数据库优化的边界

数据库是 Zabbix 的核心状态与历史存储。优化前先确认 Zabbix 版本支持的数据库版本、字符集或排序规则、schema 状态和升级要求。AllowUnsupportedDBVersions 不是长期运行在不受支持数据库上的解决方案，它只会绕过保护。

不要给所有 MySQL 环境复制同一个 innodb_buffer_pool_size，也不要给所有 PostgreSQL 环境复制同一组 shared_buffers、work_mem 和 WAL 参数。参数取决于物理内存、是否与 Server 共机、连接数、存储、复制、备份和其他工作负载。尤其是 work_mem 这类按操作或连接消耗的参数，简单按总内存比例设置可能造成内存爆发。

数据库诊断应由实际等待事件驱动。CPU 高要区分计算和自旋；I/O 高要看读写、延迟和队列；连接多要看活跃与空闲；慢查询要结合执行计划；锁等待要找到持有者；PostgreSQL 要关注 autovacuum、表膨胀和检查点；MySQL 要关注 InnoDB 缓冲、redo、刷盘和锁。Zabbix 写入压力只是输入，数据库内部证据决定方案。

数据库与 Server 分离可以隔离资源和便于高可用，但会引入网络延迟。低时延、稳定和受控的网络比峰值带宽更关键。不要让数据库连接跨不可靠广域网。数据库高可用也必须验证故障切换时 Zabbix 客户端行为、读写主节点识别、连接恢复和数据一致性。

LogSlowQueries 可以让 Zabbix Server 记录超过阈值的数据库查询，数据库自身的慢查询与统计工具则提供更完整视角。开启详细日志要评估磁盘和敏感信息，采样结束后恢复合理级别。最终优化应落到 schema 支持、查询计划、存储、内存或工作负载，而不是长期依赖调试日志。

Server 与 Proxy 参数怎么改

Zabbix Server 配置文件中的进程和缓存参数很多，正确方法是从瓶颈映射到最小参数集合。配置缓存不足才考虑 CacheSize；HTTP agent 采集积压才分析 HTTP poller 与并发；ICMP 积压才看 pinger；VMware 监控才看 VMware collector 和 cache。没有启用的功能不应为了“高性能模板”启动大量进程。

参数的默认值、范围、是否可重载和版本变化必须查当前 zabbix_server 配置参数文档。旧文章中的默认值可能已经变化，部分参数会弃用或被异步框架替代。配置文件支持 Include 时，可以把本地覆盖放在单独文件，降低升级合并风险，并通过配置管理记录差异。

进程数调整以小步为原则。例如确认某类同步 poller 持续繁忙、目标响应正常、CPU 与内存有余量后，小幅增加对应进程，观察一个高峰周期。若 queue 改善但数据库写入或上下文切换恶化，说明瓶颈已转移或增量过大。变更记录要保留前后内部指标。

Proxy 参数同理。分布式环境中应分别观察每个 Proxy，而不是只看中心。某区域 queue 和 process busy 高，可能是 Proxy 资源、网络或目标端问题；中心正常不能证明区域正常。Proxy 缓存模式、离线缓存和数据库见上一篇，恢复回传时还要把中心容量纳入。

运行时控制命令可以用于部分缓存重载、日志级别或特定操作，但支持项随版本变化。执行前查官方 runtime control 文档，记录命令、目标进程和恢复操作。不要把临时提高 DebugLevel 当成长期配置，也不要在高峰对所有进程开启详细日志。

前端慢的诊断方式

Zabbix 前端性能优化路径

前端慢先复现具体页面、用户、时间范围和过滤条件。同一个页面管理员慢、普通用户正常，可能与权限和可见对象范围有关；短时间范围正常、九十天范围慢，可能是历史查询；只有大型 Dashboard 慢，可能是 Widget 数量和刷新频率；所有页面都慢，才更像 PHP、Web、数据库或网络的系统问题。

不要把 PHP memory_limit、执行时间和 OPcache 参数整体调大后宣布优化完成。先看 Web 与 PHP-FPM 日志、请求耗时、worker 使用、数据库慢查询和浏览器网络面板。内存限制不足会有明确错误；worker 不足会排队；数据库查询慢会在后端体现；浏览器一次下载过多点位则需要缩小查询。

仪表盘设计本身影响负载。多个 Widget 查询相同大范围、刷新间隔过短、默认选择全部主机、展示过多问题历史，都可能产生高开销。运维总览应突出当前状态和少量趋势，详情通过下钻页面按需查询。不同团队的看板分开，避免每个访问者加载全公司数据。

前端和 Server 可以独立扩展，但共享数据库仍可能是瓶颈。增加 PHP-FPM worker 前先确认数据库与内存能承受更多并发。反向代理缓存不适合随意缓存带权限和实时状态的 API 响应。HTTPS、会话和负载均衡配置要保证安全与一致性。

一次可靠的优化变更

性能优化应该像故障修复一样有假设。示例：“工作日十点到十一点 SNMP poller 持续繁忙，队列集中在某网络模板；抽样设备响应正常，CPU 和数据库有余量。假设现有 SNMP 并发不足。”这个假设比“Zabbix 卡，增加全部进程”更容易验证。

变更单至少包含症状、证据、影响、根因假设、修改项、预期指标、观察窗口和回退条件。一次只处理一个主要变量。如果同时改采集间隔、进程数、数据库和缓存，即使结果变好也无法知道原因，结果变坏也难以回退。

执行前保存配置、数据库备份策略和当前图表。涉及重启时建立维护窗口，避免重启本身触发告警。执行后先验证服务、版本、数据接收、触发器、通知和前端，再观察目标指标。不要只看目标指标下降，还要看 CPU、内存、I/O、数据库和相邻进程是否出现代价。

Zabbix 性能优化验证闭环

优化结果分三类。第一类是目标改善且没有明显副作用，可以保留并更新基线。第二类是目标不变，说明假设错误或调整不足，应回退并重新定位。第三类是目标改善但产生新瓶颈，例如 poller queue 降低而数据库 pending 上升，应评估整体业务结果，不能只庆祝局部数字。

回退条件要量化，例如服务启动失败、queue 比基线增加、写缓存 pending 持续增长、数据库延迟超过阈值、系统出现交换、前端错误率上升或告警延迟恶化。触发条件后先恢复原配置，再分析，不要在生产现场连续叠加更多参数。

三类典型场景

场景一是“最新数据晚十分钟”。先确认是所有主机还是单 Proxy、单协议。查看 queue 和 Proxy last access；若队列集中在 SNMP，抽查设备响应和对应 poller；若 Proxy 离线，检查链路与缓存；若 queue 不高但 latest data 晚，检查主动 Agent、trapper、预处理和数据库写入。只有证据指向某类进程不足时才调进程。

场景二是“数据库每天固定时段 I/O 飙升”。对照 housekeeping、备份、报表、分区维护和业务批处理时间。观察 write cache pending、history syncer 与数据库等待。如果与 housekeeping 对齐，先检查保留策略和积压，不要直接关闭清理；如果与备份对齐，调整备份方式或窗口；如果是采集峰值，回到模板和间隔。

场景三是“仪表盘打开慢但告警正常”。用普通页面和短时间范围对比，检查浏览器请求、PHP-FPM、数据库慢查询和 Dashboard Widget。减少默认全选、缩短初始范围、降低刷新、拆分总览与详情。若 Grafana 也查询同一 Zabbix 数据，下一篇还要检查插件查询、趋势切换和 API 权限。

模板上线前做性能评审

模板是性能变化最常见的入口，却经常只做功能验收。新模板或大版本更新前，应在代表性主机上统计实际创建的 item、trigger、graph、discovery rule 和 dependent item 数量，记录各类更新间隔、值类型、预处理步骤与历史保留。不要只看模板文件中的原型数量，因为 LLD 在不同主机上可能展开成完全不同的规模。

评审时先问每组数据服务于什么动作：故障告警、排障、容量、报表还是资产发现。用于告警的指标要验证触发与恢复；用于看板的指标要确认真的被查询；只为“以后也许有用”保留的高频原始值，应评估存储成本。一个模板如果无法说明主要数据的消费者，就不应直接批量关联数千台主机。

试点至少覆盖正常主机、资源较多的主机、网络较差的主机和一个会产生异常数据的主机。观察 Agent 或设备负载、Proxy/Server queue、对应进程、预处理失败、unsupported item、数据库增长和告警数量。LLD 要等待完整发现周期，并验证对象消失后的清理行为。短时间功能测试无法暴露实体膨胀。

模板版本要可追踪。记录来源、版本、修改项、适用 Zabbix 版本和回滚文件。自定义修改尽量通过克隆或明确的覆盖层管理，避免升级官方模板时丢失。批量发布按主机组分阶段执行，每一阶段比较 required performance、实际写入和数据库增长，再决定是否扩大。

性能事故先止损再调优

当队列、数据库或前端已经严重恶化时，目标首先是恢复监控核心能力，而不是现场寻找完美参数。先确认 Zabbix Server、数据库和关键 Proxy 是否存活，保护配置和事件数据；暂停正在进行的模板发布、自动发现扩张、批量导入或高成本报表；保留关键业务与基础可用性检查，避免无差别重启所有组件。

如果问题由某个新模板、脚本或采集任务触发，优先禁用或回滚这个输入。若大量下线设备造成超时，临时禁用对应主机或检查；若日志型 item 产生洪峰，停止相关采集并保留样本；若 Grafana 大屏持续发起重查询，先降低刷新或隔离访问。减少新增工作通常比盲目增加进程更快恢复稳定。

数据库写入受阻时，应由数据库负责人确认空间、锁、I/O、复制和备份任务。不要在压力最高时直接执行大表索引、全量清理或未经演练的分区改造。缓存能够提供的只是有限缓冲，磁盘满或事务阻塞必须处理根因。必要时根据业务优先级暂时减少非关键采集，但要记录数据缺口。

系统恢复后保存事故时间线：最早异常指标、配置变更、queue 与缓存变化、数据库等待、采取的止损动作和恢复点。随后在隔离环境复现根因，再决定永久优化。事故期间临时增加的日志级别、进程或缓存要复审并恢复，避免应急配置变成无人解释的长期基线。

反模式与风险

第一，直接采用网上的“大规模参数模板”。硬件、版本、协议和数据库不同，参数没有可移植性。第二，把所有缓存和进程同时调大。第三，把 queue 一概解释为 Server 性能不足。第四，用来源不明的分区脚本修改生产大表。第五，通过降低数据库持久性换性能，却不说明可接受的数据风险。

第六，为了减少数据量，随意延长关键故障指标的间隔。性能目标不能破坏监控目标。第七，只优化中心，不看 Proxy。第八，只看平均值，忽略恢复峰值和周期任务。第九，关闭 housekeeping 后没有替代生命周期。第十，优化后不记录基线，几个月后无法解释参数来源。

另一个危险做法是直接查询或修改 Zabbix 数据库来管理配置。官方 API 和前端负责维护对象关系与审计，手工改表可能破坏一致性，也会使升级困难。性能分析可以使用只读、经过审核的查询，但任何 schema 或数据变更都应遵循官方支持路径和数据库变更流程。

运行节奏与容量复审

每日检查重点是 queue、进程异常、Proxy last access、缓存低水位、数据库空间和明显延迟。每周检查 unsupported item、采集失败、LLD 增长、慢检查、告警风暴和前端高开销看板。每月比较 required performance、实际写入、历史表增长、主机与 item 增长、数据库容量和恢复回传表现。

版本升级、模板大改、纳管新区域、引入日志采集、批量开启网页或数据库检查前，要做容量评审。变更估算新增 item、间隔、值类型、预处理、保留和协议依赖，在小范围试点后用真实增量修正估算。容量规划不是年度硬件表，而是配置变更的一部分。

建议保留性能决策记录：为什么增加某类进程，为什么调整某缓存，观察了哪些指标，效果如何，何时复审。若某参数连续两次复审都没有对应瓶颈，可以考虑恢复默认或重新评估。长期堆叠参数会让系统变得不可理解。

交付检查

完成一次性能治理后，应能回答：当前 required performance 和实际写入是多少；高峰在哪个时段；最繁忙的进程是什么；queue 是否可回落；缓存是否有安全余量；数据库主要等待是什么；history 与 trends 保留是否符合用途；Proxy 恢复时中心能否承受；最慢的前端操作是什么；每项非默认参数对应哪条证据。

验证不能只看一天“没有报警”。至少覆盖一个业务高峰和一个周期维护任务，抽查最新数据、触发器、通知、图表、API 与前端。对数据库架构变更还要验证备份恢复和升级。所有结果写入运行文档，并把新基线用于下一次比较。

小结

Zabbix 性能优化不是抄参数，而是管理一条数据处理链。先用 required performance、实际写入、queue、process busy 和 cache 建立证据，再从模板、间隔、LLD、预处理、保留和告警设计减少无效工作；确认供给不足后，才调整对应进程、缓存、数据库或架构。每次只改变可解释的变量，用高峰周期验证，并准备明确回退。

下一篇将把 Zabbix 数据接入 Grafana。重点不是“装完插件能出图”，而是建立最小权限 API 账号、正确选择 history 与 trends、控制变量和查询范围，并把仪表盘作为可版本化、可验收的运行产品。

参考资料