zabbix 的一次优化尝试

背景

笔者维护的 zabbix 数据库，由于监控几千台机器，几百个监控项，后台数据库压力比较大。zabbix 数据默认存放在 MySQL，基本 SQL 都是自己生成，当监控的机器数多了，监控项也多了之后，很多低效 SQL 的问题就暴露出来了。下面记录下对 zabbix 的运维改造过程。

问题

• 读写量大。写量每天 1 亿次，曾一度超过微博最大端口的写量。读量每天 2 亿，也排在所有端口读量的前 6 名。
• 数据量大。history、history_uint 表，trends 表等是不断积累的。
• zabbix 自带有定期删除的机制，但每次删除从库就延迟，加上读写量又大，从库延迟追不回来。
• 很难备份。
• 读写都在主库上，主库压力较大

改造

针对以上这些问题，开始了一步步的改造，只要是能优化、容易优化的方法基本都使了。

• 读写分离。zabbix 本身不支持读写分离，业务层面使用 oneproxy，而后台则使用主从架构，用 DNS 做的负载均衡，在从库上表现就是轮询多个 ip。这有个问题，虽然主库压力小了，但从库压力相对大了。线上服务器基本是 8 核，32-64 G 内存，sas raid 10 配置，因为机器资源不够，怕影响其它服务也不能混跑，因此只配了一主两从。大部分读都切到从库了，主库上还是有部分读。
• 部分表用 tokudb 压缩。先清空一遍 history 和 trends 表，再将引擎改为 tokudb ，分 100 个分区。