问题原因&通用解决步骤
频繁收到es数据节点磁盘使用监控告警，到es上查看，磁盘使用率40%，因此登录该告警服务器，df -h 查看，如图
发下根目录使用超过了80%，因此持续告警，按照以往办法，直接du查看根目录哪个目录占用最大，清理即可
根目录超过了80%告警，其中data是数据盘，挂载在另外的文件系统上，不属于根目录所在文件系统。那么直接使用du命令 du -h --max-depth=1 查看根目录哪个目录占用磁盘空间最大就行了
发下除了/data目录，其它目录属于根目录，加起来不过7G，那么其它磁盘被什么占用了呢？
对于遇到df 和du结果不一致的情况，基本断定是文件虽然删除了，但是文件句柄仍然被持有，因此磁盘空间未释放，可以使用lsof命令( list open files)查看
查看根目录打开的文件，搜索删除的文件 lsof -n / |grep deleted (这里/是根目录)
怀疑是进程25550或25587持有删除文件的句柄，分别查看进程是哪些应用
分别是es应用和es中间件进程，大概原因是es应用进程25550持有删除文件的句柄导致的，因此重启此应用即可（kill也可以，但是可能会引起生产问题）。
原理解释：
du命令会对待统计文件逐个调用fstat这个系统调用，获取文件大小。它的数据是基于文件获取的，所以有很大的灵活性，不一定非要针对一个分区，可以跨越多个分区操作。如果针对的目录中文件很多，du速度就会很慢了。
df命令使用的事statfs这个系统调用，直接读取分区的超级块信息获取分区使用情况。它的数据是基于分区元数据的，所以只能针对整个分区。由于df直接读取超级块，所以运行速度不受文件多少影响。
du和df不一致情况
常见的df和du不一致情况就是文件删除的问题。当一个文件被删除后，在文件系统 目录中已经不可见了，所以du就不会再统计它了。然而如果此时还有运行的进程持有这个已经被删除了的文件的句柄，那么这个文件就不会真正在磁盘中被删除， 分区超级块中的信息也就不会更改。这样df仍旧会统计这个被删除了的文件。
如何记忆这3个命令
du ->Disk Usage
df ->Disk Free
lsof ->list open files
翻车记录
重启es后，发下磁盘占用还是存在，没办法，先重启了虚拟机，还是一样，最后无奈只能先unmount数据盘/data试试
然后du -h --max-depth=1
原来根目录/data有数据，然后挂载了数据盘后，把原/data的内容隐藏了。
解决办法：先迁移/data/数据，然后清除/data数据，然后挂载磁盘到/data，最后启动es