在9月4号和9月9号,公司的监控平台zabbix发生过俩次大规模的zabbix监控报警,都是zabbix agent on **** unreachable for 5 minute不可达,每次都是所有监控的主机发生这种报警。
故障描述:所有被监控的主机报警,所有图形数据都出现中断
操作:第一时间是在zabbix server 端执行zabbix_get 命令,发现可以得到数据,并且在命令面前添加time命令。显示出来得到的数据时间也是一个比较短的范围内的。
结果:过了10来分钟之后所有的报警就在一瞬间消失或者说恢复了,并且所有图形上面的数据都恢复了,图形整个都是连贯的。
检测:在报警消失之后第一时间我做的就是看日志,zabbix_server端的日志,在server端的日志
日志: cannot send list of active checks to [****]: host [****] not found
item "vfs.fs.size[C:,used]" on host "" failed: first network error, wait for 15 seconds
诸如此类的日志,当时我链接的客户端,客户端的日志基本上都是一些链接10051端口失败,系统中断之类的报警,然后我百度和必应许多,但是却基本上没有找到解决我的办法,无奈之下只有去请教同事。
今天事情我想应该是解决了的,因为最后我们都是无法找到问题,最后去考系统日志,即是/var/log/message里面的,在系统日志里面一直报俩种错误:
16:17:24 localhost kernel: nf_conntrack: table full, dropping packet.
localhost rsyslogd-2177: imuxsock begins to drop messages from pid 21607 due to rate-limiting
说的是表已经满了,开始丢包。另外一个是rsyslog日志数据丢失。
一开始我并没有注意,但是我的运维boss认为这是和zabbix数据无法获取有关系,然后我们就慢慢的排查和搜寻资料,最后我们发现iptables防火墙服务居然启动了,一开始zabbix配置的时候大家都晓得一般都会把防火墙和selinux关闭,但是现在的情况明显是因为防火墙将数据抵挡了,导致数据表满了之后开始丢包了。
然后我使用root用户在/root目录下的.bash_history里面有人使用iptables -L这个查看防火墙规则的命令,最后我boss告诉了我:
切记:在防火墙关闭状态下,不要通过iptables指令(比如 iptables -nL)来查看当前状态!因为这样会导致防火墙被启动,而且规则为空。虽然不会有任何拦截效果,但所有连接状态都会被记录,浪费资源且影响性能并可能导致防火墙主动丢包!
好了。最后把防火墙关闭之后
16:17:24 localhost kernel: nf_conntrack: table full, dropping packet 报警就不存在了。
补充:
报警提示数据不可达,仅仅只是数据收集延迟而已,在图形上面可以比较明显的看到数据是从最新时间到过去的6-7分钟左右的数据是空白的,并且在随着报警时间的持续,这端空白数据是平移的,意思就是在最新6-7分钟的数据是缺失的,并且只缺失6-7分钟的数据,随着时间的推移,这段空白数据也会平移,后面缺失的数据就会补齐,那么就是意味着数据并没有缺失,只不过是读取时间过长而已。
所以照成这种情况很有可能是因为数据库查询做照成的,因为开启了数据库的慢日志,所以在慢日志里面大部分都是属于insert语句,并且插入一条insert语句居然需要6秒多,所以我认为插入数据非常的慢导致数据库里面并没有最新的6-7分钟的数据,导致zabbix的web界面显示最新6-7分钟数据的 缺失,从而导致批量的unreachable的报警,最后是更改了mysql数据的配置文件my.cnf里面的三个参数:
innodb_buffer_pool_size
innodb_log_file_size
innodb_flush_log_at_trx_commit (这个很管用)
参考资料链接:http://www.cnblogs.com/whiteyun/archive/2011/12/01/2270132.html
另外:
在server端我的huosekeeper并没有关闭,所以每过一段时间huosekeeper就会执行delete这个语句在数据库中,我想有可能会不会mysql的锁表机制,在对历史数据表进行删除的时候,zabbix的web页面的select语句会不会在等待的队列中直到delete语句执行完之后然后在进行查询,从导致上面出现的错误。