在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语句执行完之后然后在进行查询，从导致上面出现的错误。
