一次公司zabbix大面积报警处理心得

刚到公司一周，作为一个运维小白还在正在熟悉公司的系统环境。

马上双十一来临，公司DBA发现监控主备数据库复制有问题，为防止双十一当天监控会突然炸掉，所以在今天下午三点钟左右对数据库进行重启操作。之前进行过N多次这样的操作，都顺利完成，因此没有在意会发生什么问题。
重启之后马上问题来了：（PS：这段时间没有对监控组件进行任何其他操作）




因为是重启数据库发生的该问题，首先想到的就是数据库重启之后其中一台数据库飘掉了，但是该问题很快被排除，因为重启的是备库，因此不存在飘掉的可能。
联系DBA 查看哪台数据库有连接，确认现在具体使用的是哪台数据库。同时根据公司建设的zabbix拓扑图查看各节点连接状态。
监控位执行重启zabbix_agentd操作，然而并没有什么用。
确认配置文件（zabbix_server.conf zabbix_agentd.conf配置文件主机名问题，IP问题），最终确认配置完全OK

此时想到是否因为重启数据库服务器后防火墙被重新打开
[root@localhost python]# service iptables status
iptables：未运行防火墙。
排除防火墙问题
此时已经过去一个多小时，仍然没有找到问题原因所在。
最快的解决方式就只剩下了重新建数据库，二话不说立马开始重新建库，将原来数据库数据重新导入新建的数据库。
重新建库后问题解决警报在慢慢解除，5分钟后3000多条报警慢慢变为800多条报警。
但这个时候新的问题出现了，主从数据库复制有延迟报警出现，查看显示主从复制延迟4分钟。查看服务器时间，发现两台数据库服务器时间不同步，重新同步两台服务器时间后报警解除。
最后总结：第一次大面积报警问题问题原因始终未找到，但是重新建库后报警解除，因此可以判断是数据库问题造成，结合重新建库后原来的报警解除但是出现主从数据库复制延迟，推测报警原因应该是数据库服务器时间不同步