凌晨两点的磁盘告警：一次 98% 空间的排查实录

凌晨两点，手机震了。监控告警：某台应用服务器根分区使用率 98%，登录都变慢了——日志快写不进去了。

这时最忌两件事：慌着 rm -rf 整个目录，或拖着等盘真满。真满之后应用写日志失败，故障就从"磁盘告警"升级成"业务不可用"。

下面是我固定的动作序列，基本 10 分钟能定位到元凶。真正费时间的从来不是定位，而是临场想不起来该敲哪条命令，所以顺序比技巧重要。

一、先定位是哪块盘

df -h

Filesystem      Size  Used Avail Use% Mounted on
/dev/vda1        40G   39G  1.1G  98% /
tmpfs           7.8G     0  7.8G   0% /dev/shm

Use% 98% 说明根分区满了；tmpfs 是内存盘，不用管。-h 让容量以 G/M 显示。

二、找出谁在吃盘

du 逐层往下钻：

du -h --max-depth=1 / 2>/dev/null | sort -h

38G	/var
2.1G	/usr
1.4G	/home

2>/dev/null 屏蔽权限报错，sort -h 按大小排序，最大值永远在最后一行。接着钻最大的那个：

du -h --max-depth=1 /var | sort -h | tail -5

文件太多时这步很慢，装 ncdu 更直观：

sudo apt install ncdu
sudo ncdu -x /

-x 不跨文件系统；ncdu 是交互式的，方向键进目录，按 n 直接看到当前目录最大的文件。

三、常见元凶

• 应用日志：/var/log/ 下某个服务的日志涨到几十 G
• Docker：镜像、容器层、构建缓存堆在 /var/lib/docker/
• /tmp、/var/tmp：临时文件没人回收
• 包管理缓存：/var/cache/apt/archives/ 里的 deb 包
• 已删除但被进程占用：文件 ls 不见了，df 却没降

四、清理

journalctl 裁剪系统日志：

sudo journalctl --vacuum-size=500M

单个大日志先确认是纯文本，再截空：

sudo truncate -s 0 /var/log/app/huge.log

truncate -s 0 把文件截成 0 字节，inode 和 fd 还在，正在写日志的进程不会报错；rm 只是删了目录项，进程仍往被删的 inode 写，空间不会释放。

Docker 清理先看再动：

docker system df
docker system prune -a --volumes

-a 删所有未使用镜像，--volumes 删未挂载的数据卷——新环境常藏在这里，没备份别加 --volumes。只清构建缓存用 docker builder prune。

包管理缓存直接清：sudo apt clean。

"删了没释放"要先找占用进程：

sudo lsof +L1 | grep deleted

确认是自己家的进程后重启它，空间立刻回来；不能重启就 truncate -s 0 那个文件。

logrotate 不配，清完还会涨。给应用加一份：

/var/log/app/*.log {
    daily
    rotate 14
    size 100M
    compress
    delaycompress
    missingok
    notifempty
    copytruncate
}

存到 /etc/logrotate.d/app，sudo logrotate -d /etc/logrotate.d/app 干跑一遍查语法。

五、预防

• 监控给根分区设 80%、90% 两档告警，别等 98%
• 容器环境给 /var/lib/docker 单独挂卷，满了不拖垮根分区
• 定期 docker system df 看存储趋势
• 服务默认别开 debug 日志级别
• 定时跑 du -h --max-depth=1 / | sort -h 做趋势快照
• 定期演练一次告警链路，确认阈值生效、通知能到人

总结：磁盘告警不可怕，可怕的是没有固定顺序——先 df -h 定位盘，再用 du/ncdu 找元凶，确认后再清，最后把日志轮转和告警阈值补上。