DB磁盘满导致Zabbix Server Crash一例

故障描述

今天线上zabbix出现几次数据中断的情况，经排查为DB服务器磁盘空间不足导致的。还好我们目前我们zabbix，falcon两套监控系统并存，哈哈。

故障排查过程没什么技术含量，简单的将故障处理过程记录一下~

1，开始收到DB磁盘空间不足的告警(falcon)，DBA查看后表示剩余磁盘大，磁盘空间还有一百多G，没啥问题。

2，十几分钟刚好有业务线在查看监控数据，发现监控数据中断了，把问题报到我们这边。

3，开始着手排查：查看Zabbix Server进程都是OK存在的，端口监听也都没有问题；检查日志发下大量的query failed报错，报错信息如下：

48102:20170324:200108.112 [Z3005] query failed: [1030] Got error 28 from storage engine [insert into history (itemid,clock,ns,value) values (1288566,1490315706,484955330,0.000000),(1287666,1490315706,516539194,0.000000),(1116846,1490315706,517255643,0.230000),(1306326,1490315706,519850399,99.910019),(761887,1490315707,652732960,0.000000),(762427,1490315707,654663788,0.010000),(943207,1490315707,655098203,99.966644),(943567,1490315707,655193288,97.071841),(762367,1490315707,655228276,0.000000),(943147,1490315707,655652053,0.000000);
]

4，上述报错中的关键信息就是“query failed: [1030] Got error 28 from storage engine”，数据在插入DB的时候出问题，赶紧将问题报给DBA进行查看。发现连接数已经几乎没有了。

5，同时google了下，查到这个报错的原因:

Mysql error "28 from storage engine" - means "not enough disk space".

DBA查看之后，发现磁盘空间还有109GB。　　

6，尽管空间还有很多，但是日志输出是不会骗人的，赶紧删除可以删除的binlog、历史数据等来腾地儿喽~

7，果然，zabbix server在DB这边的磁盘空间清理之后恢复了写入。

 

参考链接：

http://stackoverflow.com/questions/10631387/1030-got-error-28-from-storage-engine

https://www.zabbix.com/forum/showthread.php?t=4203

 

关于故障期间的数据丢失，我们可以通过将zabbix server的日志中插入失败的SQL进行解析，重新写入即可。

后记

此处的故障是解决了，但是我们不该仅仅停留在担当救火队员的角色，我们还应该更深入的分析问题原因，利用技术、非技术的手段来杜绝这样的问题再次发生：

1. 故障时在磁盘空间占用超过95%之后才出现的问题，因此合理推断在某处有一个门限值的配置，而95%恰巧就是那个门限值，此处暂时将推断留在此处，后面验证之后，我会把排查结果更新在这里
2. 应该有监控手段来cover类似此处DB写入的状态
3. 日志监控应该尽快落实、推广，将这些zabbix server等平台的日志进行采集和告警