Linux 服务器磁盘空间告急：从定位到治理的完整排查手册

凌晨三点，监控短信把你吵醒：生产服务器磁盘使用率 97%。删日志怕删错、扩容要走流程，十分钟内必须稳住。本文是一套我在生产环境里反复验证过的磁盘告急排查手册：先定位、再止血、最后治理，保证你下次不再手忙脚乱。

一、定位：三层递进，别一上来就 du -sh /*

磁盘问题分三层，先确认是哪一层：

第一层：看总体。 df -h 看哪个挂载点满了。注意 df -i 也看一眼——inode 耗尽时磁盘明明有空间，写文件依然报 “No space left on device”，这种坑最常见于大量小文件的场景（比如失控的 session 文件、邮件队列）。

第二层：找目录。 du -x -d 1 / | sort -rn | head（-x 限制在同一文件系统，避免把 /proc、/sys 这种伪文件系统算进来）。逐层下钻，直到找到最大的那几个目录。

第三层：找文件。 定位到目录后 find /var/log -type f -size +500M -exec ls -lh {} \; 揪出大文件。想找"正在疯狂增长"的文件，用 lsof | grep -i deleted 看有没有被删除但仍被进程占用的文件——这是最经典的"删了日志空间没释放"的原因。

二、止血：十分钟内把使用率打下来

1. 被删除但未释放的日志：找到占用进程后，> /proc/<pid>/fd/<fd号> 或 : > 文件名 截断，而不是 rm。rm 删的是目录项，进程手里的 fd 还在，空间照样不释放。
2. 疯狂打日志的应用：先 systemctl stop 或 kill 掉最凶的那个进程止血，再回头看为什么打这么多日志。
3. Docker 场景：docker system df 看看，八成是悬空镜像和 stopped 容器的日志。docker logs 默认 json-file 驱动不轮转，单个容器日志能涨到几十 GB——先用 truncate -s 0 截断，事后再配轮转。
4. 实在找不到凶手：du 和 df 对不上（du 算出来远小于 df），基本就是 deleted-but-open 的文件，lsof +L1 直接列出来。

三、治理：让告警不再半夜响

止血只是开始，不治理等于等着下一次：

• logrotate 配好：/etc/logrotate.d/ 里给每个应用配 daily rotate 7 compress size 100M，别用系统默认的 weekly。
• journald 限额：SystemMaxUse=500M 写进 /etc/systemd/journald.conf，不然 journal 能吃掉几个 GB。
• Docker 日志轮转：daemon.json 里配 "log-driver": "json-file", "log-opts": {"max-size": "50m", "max-file": "3"}，一劳永逸。
• 告警阈值分层：75% 预警（白天处理）、90% 紧急（立即处理），别等 97% 才短信轰炸。
• 定期巡检脚本：每周跑一次 df -h + top 10 大目录的报告，趋势比单点数值更重要——连续三周缓慢上涨的目录，就是下一次事故的预告。

小结

磁盘告急的排查就一句话：df 定层、du 定向、lsof 定凶，截断止血、轮转治本。把这套流程写成 runbook 贴在团队 wiki 里，下次值班的人就不用凌晨三点翻博客了。