这类故障通常不是单点问题，先确认最外层的报错，再往里一层层看。 df 显示 /var 已经用到百分之百，du 一看 /var/log/journal 占了三十八 G，手工删掉文件第二天又满回来，业务日志反而写不进去。
先把影响面控制住，再谈彻底修复，顺序反了容易在高峰期出二次故障。
先分清是哪一类原因
- journald 默认按磁盘容量的百分之十保留，日志量大时很快就把上限顶满
- 改完配置没有执行 vacuum，旧日志仍然占着 inode 不释放
- rsyslog 又把 journal 的内容抄了一份进 messages，同一批日志落了两遍盘
按顺序处理
1. 看 journal 当前的占用
journalctl --disk-usage2. 立刻回收旧日志到五百 M
journalctl --vacuum-size=500M3. 改上限之后重启服务生效
systemctl restart systemd-journald4. 关掉 rsyslog 的重复落盘
systemctl disable --now rsyslog怎么确认已经恢复
journalctl –disk-usage 显示五百 M 左右，df -h /var 的使用率降到六成以下，并且第二天不再反弹。
容易忽略的地方
只删 /var/log/journal 下的文件而不重启服务，journald 仍然握着已删除的 inode，空间不会马上回来，这也是很多人以为清理无效的原因。 线上环境和本地环境的差异往往就在版本和默认参数上，比对一下两边的实际取值能省很多时间。