在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 报警就不存在了。
zabbix监控大批量报警zabbix agent on **** unreachable for 5 minute
原文地址：http://9036423.blog.51cto.com/9026423/1693542
