Bootstrap

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 个分区。
;