起因
今天监控信息收到一个磁盘容量告警

问题定位
根据监控告警信息去相应服务器检查磁盘空间情况

使用df与du命令显示的结果不一致,/data分区主要用于应用服务部署运行,应用服务部署的tomcat服务,每天日志量增长比较大。前段时间手动清理过tomcat的历史日志,其他应用服务不存在占用磁盘空间增长太大的情况。首先想到的是日志文件在被程序打开的时候被删除了,因为之前遇到过这种情况。但是tomcat日志都是按天切割的,删除的都不是当前程序打开的文件。
还是使用lsof检查看下有没有程序打开已经被删除的文件

执行lsof | grep deleted命令后出来很多结果,再具体过滤/data分区目录结果。从查看结果看到还在打开已删除的日志文件的程序并不是tomcat服务,判断就是这些已打开被删除的文件空间还没被释放。
处理
根据查询结果显示,是一个日志收集程序在运行打开文件,可以重启这个服务也不会影响现业务运行,kill掉上面查询出来的进程PID(86964)释放磁盘空间

确认进程被kill后,再次检查磁盘空间情况

从从上图看到两个命令统计的结果已保持一致。
最后
Linux下df与du命令执行显示的结果不一致还有其他可能情况,今天遇到的是删除了还有程序打开使用的文件。之前还遇到过剩余磁盘空间充足,应用服务启动日志显示剩余磁盘空间不足的情况,那一次的情况是大量小文件占满了inodes空间导致不能创建新文件,只有根据日常运维经验快速定位解决问题。