Zabbix性能调优实践分享——上海宏时数据系统有限公司董玉凡
以下内容选自“2024Zabbix中国峰会”：
尊敬的各位参会嘉宾，大家好！我是上海宏时数据系统有限公司的董玉凡，今日分享的主题为《Zabbix性能调优三板斧》。本次内容将从以下三部分展开：
Zabbix性能瓶颈表现分析、性能优化核心原则以及实际案例经验分享。
一、Zabbix性能瓶颈表现
随着监控规模的扩展，Zabbix系统可能面临以下典型问题：
前端页面卡顿：队列刷新延迟（如30秒一次）、操作响应缓慢。
数据采集异常：监控项数据断点、采集队列堆积。
资源占用过高：进程负载不均、缓存利用率不足或溢出、数据库读写压力激增。
这些问题通常由配置不当、采集策略不合理或架构扩展性不足引发，需结合系统自监控数据精准定位。
二、Zabbix性能优化核心原则
✦第一板斧：配置优化
我们进行配置优化需要有所依据，而这里优化的依据就是自监控，筛查自监控系统中的异常指标，从而对症下药。
1.启用自监控模板
模板分类：远程/本地Server/Proxy健康监控模板（如Zabbix server health、Zabbix proxy health）。
关键配置：需正确配置模板宏（如{ZABBIX.PROXY.PORT}）及Agent代理绑定，确保自监控数据准确性。
如下列出一些我们做过的自监控模板。
2.参数动态调整
进程类参数：根据StartPollers、StartPreprocessors等进程利用率调整并发数量。
缓存类参数：优化HistoryCacheSize、TrendCacheSize等缓存配置，避免溢出或浪费。
超时与频率参数：合理设置Timeout、HousekeepingFrequency等，平衡实时性与资源消耗。
3.数据流转架
构通过配置缓存、预处理队列、历史数据同步等环节优化数据流效率，降低数据库负载。
✦第二板斧：数据采集优化
配置优化是针对性很强的优化方案，但本质上是头痛医头脚痛医脚，看似解决了眼前的问题，但大概率只是解决了表象问题。因此我们还需要进行数据采集的优化。
- 监控项精细化配置
类型选择：优先使用主动模式（如Zabbix Agent Active、SNMP Trapper），降低Server压力。
数据类型与间隔：根据监控内容选择数值型或字符型数据，动态调整采集间隔（如静态信息延长至小时级），比如CPU核数、主机名、文件系统的总大小等参数，可以适当拉长其数据采集间隔。
预处理策略：根据值变化的敏感度适当加上预处理过程，针对重复值启用Discard unchanged预处理，减少冗余数据写入。 - 数据保留策略
历史数据保留周期建议缩短至3个月，趋势数据可保留1年，结合MySQL表分区提升管理效率，降低数据库负载。
✦第三板斧：架构扩展优化
当你的监控体量足够大或者需求足够复杂的时候，前面两板斧的优化效果已经被数据量指数级上升带来的需求淹没的时候，这时我们就势必引入Proxy来分摊Server的负载。
高可用与负载均衡
Server HA集群：通过双机热备（如Server1/Server2）保障服务连续性。
横向扩展Proxy：通过Proxy分组（如GroupA/GroupB）分摊数据采集压力，支持海量节点纳管。
数据库优化
主从架构与表分区：采用MySQL主从复制，配置innodb_buffer_pool_size等核心参数。
混合存储模式：结合Memory、Hybrid模式优化高频读写场景性能。
以上三板斧都能够合理使用的话，在大多数监控场景下，Zabbix的监控性能是没有任何问题的。
三、Zabbix优化案例实践
案例1：系统监控场景
规模：纳管6000+节点（含数据库、操作系统、硬件设备、中间件、应用），部署6台Proxy，监控项超100万，触发器35万+。
优化措施：
启用Proxy分组与HA集群，NVPS（每秒新值数）达2万+。
MySQL表分区配置，历史数据保留3个月，趋势数据保留1年。
自监控显示配置同步与历史同步进程负载稳定，系统持续运行超1年。
案例2：网络设备监控场景
规模：纳管5000+网络节点（路由器、防火墙、交换机），监控项200万+，触发器150万+。
优化措施：
被动模式为主，调整StartSNMPTrapper等进程参数适配网络设备特性。
数据库采用主从同步，表分区策略与系统监控场景一致，NVPS达1.7万+。
总结
Zabbix性能调优需遵循配置优化→采集策略优化→架构扩展的递进原则，结合自监控数据精准施策。通过上述“三板斧”，可显著提升大规模监控场景下的系统稳定性与效率。
未来，随着Zabbix 7.0对HA集群与Proxy分组的增强，将进一步支持企业级复杂监控需求。
