zabbix proxy/node 的使用总结教训

这两个的运用场景可以参见官方的这个文档
实际情况是,我们是同机房的不同 vlan 通过 proxy 收集,跨机房的则通过 node 跟目前的 master 并行。proxy 以及 node 的操作都没什么难度。这里跟大家说说我们在拆分 node 的一些教训。

# zabbix_server -n 20 -c /etc/zabbix/zabbix_server.conf
Dropping foreign keys ………………………………………. done.
Converting tables ………………………. done.
Creating foreign keys ………………………………………. done.
Conversion completed successfully.

上面这个如此简洁的 stdout 其实是我们新上的一个 zabbix server 做的 node,item 少的很。但是,当拿一个跑了有大半年的 zabbix server(跟那个新的 zabbix server 跨机房) 做 node 的时候,情况就不是那么美好了。

执行上面这条命令其实执行的是 src/libs/zbxdbhigh/dbschema.c 这个文件里面的 db_schema_fkeys 以及 db_schema_fkeys_drop 里面的 sql 语句。
慎重提醒,如果你的 zabbix 以及跑了很长的时间,像我们,单单 history_uint 表做了 partition 之后还有接近 1亿 的条目。要执行完上面的所有的 sql 语句会花费很长的时间。
之前对这个命令没有很好的理解,以为最多几分钟就能搞定的。结果等了几十分钟还没结束,幸好 zabbix_server 会把 slow query 打印在屏幕上,才能找到原来是上面那个 dbschema.c 文件里面执行的 sql。
另外,下面这条语句也能看到目前的 process:
> select * from information_schema.processlist  where info != 'NULL';

另外,官方说上面那个命令只能执行一遍,中途不能按 ctrl+c 停止,一直等到了最终执行完毕,整个过程持续了 6h+。

zabbix_server [310083]: Warning: slow query: 2965.823846 sec, "update history set itemid=itemid+1001000000000000 where itemid>0"
zabbix_server [310083]: Warning: slow query: 12539.601075 sec, "update history_uint set itemid=itemid+1001000000000000 where itemid>0"

基础设施做的不好,后期的维护成本会相应的变高。付出的人力精力时间也会成倍的增加,并且需要承担更大的风险。因此,这类基础性的设施是越早做越好。