一次磁盘空间被日志文件占满的排查记录

上周三上午，监控先报了一条磁盘使用率超过90%的告警。根分区只剩不到2GB，一周涨了将近30GB，显然是有东西在持续写盘。

先确认告警是不是真的。用df -h看各挂载点，根分区使用率到了94%，数据盘却只有40%；再用df -i看inode使用率，只有12%，可以排除小文件耗尽inode的情况。

接下来定位大文件。先用du -sh /*扫根目录，/var占了28GB；再往下钻，du -sh /var/log/*很快锁定到/var/log/app/app.log，一个日志文件21GB。用find /var/log -type f -size +1G交叉确认，只有一个文件符合条件，就是它。

查到文件后别急着删，先确认三件事：进程还在往里面写吗，日志能不能丢，删除后空间会不会回来。lsof查到应用进程正持有这个文件句柄，说明直接rm只会删掉目录项，进程继续往旧句柄里写，空间要等进程退出才释放，治标不治本。

再看为什么会写这么多。用tail -n 200看日志尾部，同一条数据库连接超时错误每秒重复几十条；grep -c数一下，一个小时就写了400多万行。根源是一处重试逻辑：失败后没有退避等待，立即重试，错误日志每条又带了完整堆栈，单条约2KB，量就是这样堆起来的。

清理要分两步走。应急先释放空间：用: > app.log把文件截断为空，正在写的进程不用重启，空间立刻回来，服务也不中断。注意不要用rm，以免句柄问题让空间迟迟不释放。同期把日志级别临时调到WARN，止住洪水。

但这只是止血。根治要做三件事：第一，给这处重试加上指数退避和最大重试次数，失败三次后走降级而不是无限重试；第二，把日志滚动配起来，logrotate按天切分、保留7天、超过500MB自动切，旧日志gzip压缩；第三，把磁盘告警阈值从90%提前到75%，对/var/log单独做趋势告警。

复查时磁盘使用率回落到58%，日志恢复到每小时几十MB。最后补了一条巡检：每周看一次各目录增长量，超过5GB的目录要讲清楚原因。

这次排查不到两小时，教训是磁盘告警不能只看数值。先看增量，再看大文件，然后确认句柄和写入源头。删文件之前先想清楚空间能不能回来，修代码之前先止住写入量。根因往往不在磁盘本身，而在被忽视的日志和重试逻辑里。