凌晨的时候监控面板上 /var 分区出现了92%的红色条，应用接口开始偶尔出现500错误。先执行 df -h 查看挂载点，然后执行 du -sh /var/log/* | sort -hr 向下查询，前十行中 nginx/access.log、journal 以及系统审计日志占据了大部分。
处理顺序比下手速度快慢更重要。正在被进程持有的日志不能直接 rm，而是用 > /var/log/nginx/access.log 截断，句柄不丢、空间立刻回吐；systemd 日志用 journalctl --vacuum-size=500M 收紧上限，顺便把 journald.conf 里的 SystemMaxUse 改成 1G，堵住下次膨胀。
旧备份就是隐藏的雷区。备份目录里堆积着每天全量打包的 app-$(date).tar.gz，保留策略早就失效了。挑出最近三天加一次周备留作兜底，其余超过七天的压缩包先 mv 到 /tmp/oldbackup 观察半天，确认恢复流程能拉到新位置的数据，再统一清掉。单台40G的系统盘通过这一步可以腾出12G的空间。
收尾不是关掉告警就结束的。在/etc/logrotate.d/目录下添加一条按大小触发的规则：单文件超过200M时进行轮转、保留14份、gzip延迟压缩，在postrotate中发送USR1信号使服务重新打开文件。备份脚本加上sha256校验和远程同步，本地只留热数据，冷数据扔对象存储。
清完后用 df -h 来检查，使用率又回到了 61%。磁盘告警消失了，第二天同一时间也没有再出现。