Hostease 专区实测讨论：云服务器 journald 日志膨胀治理：持久化配置与容量限额需要验证哪些指标

云服务器（Cloud Server，通过控制台开通的虚拟化主机）磁盘被日志撑满的求助帖，运维群里每个月都有。不少新手拿到小盘 VPS（Virtual Private Server，虚拟专用服务器），跑了几个月突然 SSH 登录报错 “No space left on device”，排查半天发现是 /var/log/journal 下几个 GB 的日志文件。本文解决这个问题：如何用 journald（systemd 的日志服务）的持久化配置和容量限额控制占用，以及配置后要验证哪些指标。

为什么 journald 会把磁盘吃满

先看根源。默认配置下，很多发行版的 journald 只把日志写进内存文件系统 /run/log/journal，重启即清空；但系统里一旦存在 /var/log/journal 目录，journald 就自动切换为持久化模式，日志开始落盘。这个切换多发生在装软件包或手动建目录之后，很多人根本没察觉。

开启持久化后，journald 默认配额是”最多占文件系统 10%、不超过 4GB”。听着有上限，但两类场景依然会出事：一是小盘机器，20GB 盘的 10% 就是 2GB，叠加应用日志后余量很快见底；二是转发堆积，journal 转发给 rsyslog（常见系统日志服务）却没配轮转时两边各存一份，占用翻倍。

我的测试环境里，一台 20GB 盘机器未配限额连跑 45 天，/var/log/journal 占了 2.1GB，加上 /var/log/syslog 的 1.3GB，日志合计吃掉磁盘 17%，足以触发告警并影响服务写入。

持久化配置：先决定日志要不要落盘

治理的第一步不是急着限容量，而是想清楚这台机器需不需要持久化日志。判断依据很简单：出了问题需要回溯历史日志吗？跑生产业务的机器答案是肯定的——重启之后没有持久化就等于丢失全部排查线索。

确认需要持久化后三步走：ls /var/log/journal 不存在就 mkdir -p 并 systemctl restart systemd-journald；在 /etc/systemd/journald.conf 设置 Storage=persistent（或保持默认 auto）；确认 Compress=yes 未被关闭，journal 靠压缩省空间，关掉它磁盘占用会成倍增长。

有个坑：改完 journald.conf 必须重启服务才生效。部分精简镜像里 journald 由 socket 激活，直接 restart 会提示服务未运行，用 systemctl try-restart systemd-journald 更稳妥。

容量限额：SystemMaxUse 怎么设才合理

持久化解决”日志在不在”，容量限额解决”日志占多少”。核心参数 SystemMaxUse 限制 journal 在磁盘上的最大占用。举例：一台跑 WordPress 的 40GB 盘机器，系统加应用占 12GB，我给日志预算 1GB，三个参数即可——SystemMaxUse=1G 划硬顶，SystemKeepFree=2G 保底 2GB 空闲，MaxRetentionSec=30day 清理超 30 天日志。三者按”先到者为准”回收，占用不会同时逼近三个上限。

预算怎么定？按”磁盘总量的 2% 到 5%，且不超过 2GB”估算：20GB 小盘给 500MB 到 1GB，100GB 大盘给 2GB 足够。需要回溯一个月前的安全事件，就把保留时长拉长并同步上调占用上限。

注意 SystemMaxUse 只约束持久化存储；若 journald 还在写内存态目录，对应参数是 RuntimeMaxUse，默认取文件系统 10% 与物理内存的较小值。纯内存态日志只占内存、不会撑爆磁盘，动手前先分清。

配置后需要验证哪些指标

配置写完不等于治理完成。真正确认生效，需要验证四组指标，每一组都有对应的验证命令和判断标准。

指标一是当前 journal 实际占用。journalctl --disk-usage 的输出必须小于等于你设置的占用上限。如果配了 1G 实际还是 2GB，先查配置位置——/etc/systemd/journald.conf.d/ 优先级高于主文件——再确认服务是否重启。

指标二是真空回收是否触发。journalctl --vacuum-size=1G 手动触发一次回收即可立即降占用，但那是一次性动作；真正的治理靠自动回收，观察 du -sh /var/log/journal 随后几天是否稳定在限额内即可。

指标三是重启后日志是否保留。重启机器后执行 journalctl -b -1 查看上一次启动的日志，能正常输出说明持久化生效；报 “No journal files were found” 则配置没落地，排查线索会全部丢失。

指标四是磁盘余量趋势。连续几天执行 df -h /var/log，使用率趋于平稳、不再线性上涨才算治理成功。若还在涨，大概率有第二个日志生产者没纳入治理，可结合 影响美国VPS服务器速度的核心因素与优化指南 的排查思路定位。

常见误区与排查思路

实际帮群友排查时，我遇到过三个高频误区，这里集中说一下。

误区一：只删文件不配限额。journald 仍持有已删文件的句柄，空间不会立刻释放，必须用 journalctl --vacuum-* 命令或重启服务才能真正回收。删文件是应急，配限额才是治本。

误区二：配置写错位置。直接改发行版默认配置文件，下次系统包升级就被覆盖。正确做法是在 /etc/systemd/journald.conf.d/ 放自定义 conf（如 99-size-limit.conf），单位后缀写 K、M、G 即可。

误区三：忽略 syslog 转发的双份占用。Debian 系默认把 journal 转发给 rsyslog，/var/log/syslog 会再存一份，需靠 logrotate（日志轮转工具）管理；默认按周轮转留 4 份，流量大的机器要主动调小。

另外可用 systemd-analyze cat-config systemd/journald.conf 查看合并后的最终生效配置，一次确认主文件与 drop-in 的叠加结果。选型阶段可参考 中小企业如何选择合适的云服务器？实用选型指南 的容量规划讨论。

总结与行动建议

整个治理链路是：确认持久化、定容量预算、配置 SystemMaxUse 等限额、再用磁盘占用、真空回收、重启保留、余量趋势四组指标闭环验证。整套动作单机不超过 15 分钟，就能把日志从”随时撑爆磁盘的隐患”变成”有预算、可回溯的基础设施”。

快速上手的建议：先执行 journalctl --disk-usage 摸清现状，按”磁盘 2% 到 5% 且不超过 2GB”写入 drop-in 配置，重启后用四组指标逐一验证。多机管理可把配置做成初始化脚本一次下发。选购时参考 2025年最值得推荐的美国VPS服务器提供商排行榜 对比磁盘配额与工单支持；Hostease 提供中文工单协助排查系统层问题，详见 Hostease 专区。