VPS journald日志占满磁盘怎么办？先分清保留策略、持久化与安全清理

VPS 的 /var/log 变大，不一定是网站访问日志。启用持久化日志后，systemd-journald 会把系统、服务和内核消息写入 journal 文件；当服务反复报错或没有设置容量上限时，磁盘可能先被日志吃满。处理这类问题的顺序应是“确认占用位置—保留一份现场—临时释放空间—设置上限—验证是否复发”，不要直接删除整个日志目录。

先确认：到底是 journald 占满了磁盘吗

先看文件系统和 inode，再看 journal 自己的统计：

df -hT
df -ih
journalctl --disk-usage
journalctl --verify

journalctl --disk-usage 只统计 journal 文件；如果它显示的容量很小，而 df 仍接近 100%，应继续检查 Nginx、Docker 日志、应用目录和“已删除但仍被进程打开”的文件。可以用下面的命令限定在同一文件系统内盘点：

sudo du -xhd1 /var/log /run/log 2>/dev/null | sort -h
sudo lsof +L1

journal 可能位于 /run/log/journal（易失、重启后清空）或 /var/log/journal（持久化）。先确定路径，才能判断该改运行时上限还是持久化上限。

磁盘告急时，先轮转再按大小清理

如果已经影响到数据库、SSH 或网站写入，先保存最近一段日志和当前时间，然后让 journald 封存当前文件，再清理旧文件：

sudo journalctl --rotate
sudo journalctl --vacuum-size=500M
sudo journalctl --disk-usage

--vacuum-size 只删除归档文件，不会按指定大小截断正在写入的当前文件。也可以按时间清理，例如：

sudo journalctl --rotate
sudo journalctl --vacuum-time=7d

保留 7 天或 500 MB 只是示例，生产环境要结合故障追溯周期、磁盘容量和合规要求决定。若磁盘已经没有空间，清理前不要运行会产生大量临时文件的打包或全文检索命令。

用 journald.conf 设置长期上限

临时 vacuum 不能阻止下一次日志刷屏。编辑 /etc/systemd/journald.conf，按需设置持久化、容量和保留时间：

[Journal]
Storage=persistent
SystemMaxUse=1G
SystemKeepFree=2G
MaxRetentionSec=14day
RuntimeMaxUse=200M
RateLimitIntervalSec=30s
RateLimitBurst=10000

SystemMaxUse 限制持久化 journal 总量，SystemKeepFree 为文件系统保留空间，RuntimeMaxUse 针对 /run 下的运行时日志，MaxRetentionSec 是时间上限。容量值不能脱离 VPS 磁盘大小照抄；例如 10 GB 系统盘不适合同时设置过大的日志和缓存预算。

保存后重启 journald 读取配置：

sudo systemctl restart systemd-journald
systemctl is-active systemd-journald
journalctl --disk-usage
systemctl show systemd-journald -p FragmentPath -p DropInPaths

如果发行版提供了 /etc/systemd/journald.conf.d/，也可以将站点策略放进独立的 limits.conf，便于审计和回滚；修改前先记录原文件内容。

日志突然暴涨，别只调大上限

容量上限解决的是“占多少”，不解决“为什么一直写”。查看最近错误最多的服务：

sudo journalctl -p warning..alert --since "1 hour ago" --no-pager
sudo journalctl --since "1 hour ago" -o short-iso --no-pager | tail -n 200
sudo journalctl -u nginx --since "1 hour ago" --no-pager

若同一错误每秒重复，优先修复服务配置、DNS、证书、依赖或重启循环；不要为了安静而关闭所有日志。systemd 服务依赖导致的重复失败可参考VPS systemd服务依赖启动失败的排查方法，应用文件日志轮转问题则可对照VPS Logrotate不生效的排查清单。

发布前后的验收清单

• 再次执行 df -hT、df -ih，确认释放的是目标文件系统而不是临时挂载。
• 用 journalctl --disk-usage 记录当前容量，等待一个轮转周期后复查。
• 用 journalctl -u 目标服务 --since ... 确认关键服务仍能写入和查询日志。
• 检查 SystemMaxUse、SystemKeepFree 与磁盘实际大小是否匹配，并把配置纳入备份。

如果清理后容量很快再次上升，问题通常在异常日志源、重启风暴或磁盘上其他目录；回到占用盘点，不要反复执行 vacuum 代替根因修复。

常见问题

journalctl –vacuum-size 没有明显释放空间，为什么？
它只删除归档文件；先执行 journalctl --rotate，并确认真正占用磁盘的是 journal，而不是应用日志或已删除未释放文件。

把 Storage 改成 volatile 能解决吗？
它会把日志放到运行时目录，重启后不保留，不能替代容量治理。需要审计或故障追溯时，不应为了省磁盘而永久关闭持久化。

能直接删除 /var/log/journal 下的文件吗？
不建议。优先使用 journalctl 的 rotate/vacuum，让 journald 自己维护索引；直接删除可能造成查询缺口，极端情况下还会与正在写入的文件竞争。

RateLimitIntervalSec 和 RateLimitBurst 应该设多大？
没有通用值。先定位刷屏服务，再按业务允许的日志粒度设置；限制过低会丢失故障线索，限制过高则无法抑制异常循环。