小服务器磁盘报警别慌：三步定位是谁在吃空间

系统盘只有 20G 的小服务器，最常见的半夜告警不是 CPU，也不是内存，而是磁盘使用率悄悄爬过了 85%。这时候最忌讳的是凭感觉乱删——删错一个日志目录问题不大，删错数据文件就真出事了。我的处理顺序固定三步：先定位、再分类、最后才动手。

第一步：看总量，找大头在哪一层

先看各挂载点的使用率：

df -h

确认是哪块盘满了（一般是系统盘 /）。然后逐层往下钻，找占用最大的目录：

du -h --max-depth=1 / | sort -hr | head
du -h --max-depth=1 /var | sort -hr | head

这一步的目标不是删东西，而是回答一个问题：空间到底被哪一类文件吃掉了。常见的大头就四类：日志、软件包缓存、容器镜像、业务数据。定位到目录级别就停手，先分类再处理。

第二步：按类别处理，别一刀切

日志类：/var/log 下的日志先看有没有轮转，journal 可以查占用并压缩保留量：

journalctl --disk-usage
journalctl --vacuum-size=200M

注意 vacuum 是按总量回收旧日志，正规做法；直接 rm 正在写入的日志文件，反而会让进程继续往已删除的文件里写，空间不释放还查不到原因。

缓存类：包管理器的缓存可以清，收益立竿见影且无副作用：

apt clean

容器类：如果跑了 Docker，docker system df 先看构成，无用的旧镜像和停止的容器用 prune 清理，但卷（volume）不要随手 prune，里面可能有业务数据。

业务数据类：这一类只搬不删——加挂数据盘迁移、或开启对象存储归档。系统盘里的大文件如果是数据库，先做备份再谈迁移顺序。

第三步：治本，加两个日常动作

一是日志轮转确认开启：logrotate 默认对系统日志生效，自己应用的日志要在配置里写明保留天数和单文件大小，别让一个调试日志无限长。

二是把磁盘告警阈值设在 75% 而不是 90%：小盘总量小，涨起来快，75% 报警能留出几天缓冲处理，不用半夜爬起来救火。监控侧配一条「磁盘使用率持续 10 分钟高于 75%」的规则就够了。

总结：小服务器磁盘报警，慌的是不知道满在哪。df 看总量、du 逐层定位、按日志/缓存/容器/数据四类分别处理，最后用轮转和提前量告警治本——流程固定下来，这类告警就是十分钟的日常活。