云服务器（一种通过虚拟化技术按需分配 CPU、内存与存储资源的联网计算服务）用久之后，很多站长都遇到过同一件怪事：明明没有上传大文件，磁盘空间却一天天减少。排查到最后，”元凶”经常落在 /var/log/journal 目录上——systemd-journald（systemd 套件中的系统日志服务）积累的二进制日志，悄悄吃掉了几个 GB 甚至几十 GB 的空间。本文将教你如何判断 journald 日志是否膨胀、如何通过持久化配置与容量限额从根源上治理，并给出日常监控与清理的完整命令，帮助你把这块磁盘开销牢牢控制在预算之内。
一、先搞清楚：journald 日志为什么会膨胀
journald 采用二进制格式集中记录系统日志，按设计它会配合轮转（日志按大小或时间自动分割、删除旧文件的机制）自我约束。但云服务器上有三类常见情况会让约束失效。
第一类是默认配置偏宽松。在不少发行版上，journald 的存储上限默认取磁盘空间的 10%，一台 200 GB 数据盘的机器，理论上日志可以膨胀到 20 GB；如果 /var/log/journal 落在一块 500 GB 的数据盘上，默认上限就是 50 GB。
第二类是日志产生速率异常。某个服务每秒抛出上千行错误、内核反复刷屏、调试日志忘了关闭，这些都会让日志增速远超正常水平。此时即便配额没变，日志也会更快触顶。
第三类是日志目录落在不受控的挂载点。例如把 /var/log 软链或挂载到了一块很大的数据盘，journald 按该盘总容量计算 10% 上限，日志的”天花板”随之被抬高。
判断是否膨胀，只需要两条命令：journalctl --disk-usage 查看当前日志归档的总占用；du -sh /var/log/journal 查看目录实际体积。如果前者已经以 GB 为单位，且磁盘使用率同步攀升，就可以确认日志膨胀是空间压力的来源之一。
在动手治理前，建议先确认 /var/log/journal 与系统盘的挂载关系：df -h /var/log/journal。如果它确实落在一块超大数据盘上，后面讲到的容量限额配置就尤为必要。
二、持久化配置：让日志行为可预期
journald 的存储行为由 /etc/systemd/journald.conf 中的 Storage 参数决定，它有三个可选值，行为差异很大：
auto：默认值。/var/log/journal目录存在时写持久化日志，目录不存在则退回易失性的内存日志persistent：无条件把日志写到磁盘，目录不存在时自动创建；重启后日志保留volatile：日志只写在内存中的/run/log/journal，重启即消失，不占磁盘
这里有一个很容易被忽视的坑：如果机器处于 auto 且 /var/log/journal 目录缺失，日志会全部写进内存，表现为”磁盘很干净、重启日志全丢”。这在排查故障时非常致命——等你想起查日志，机器可能已经重启过了。因此对于生产环境的云服务器，我们建议的做法是显式声明 persistent，把日志行为固定下来：
sudo mkdir -p /etc/systemd/journald.conf.d
sudo tee /etc/systemd/journald.conf.d/99-size-limit.conf > /dev/null <<'EOF'
[Journal]
Storage=persistent
EOF
sudo systemctl restart systemd-journald
使用 drop-in 目录（journald.conf.d 下新增覆盖片段，而非直接改主配置文件）的好处是升级系统包时不会覆盖你的修改，也让后续审计一目了然。
持久化之后，日志会按归档文件的形式存放在 /var/log/journal/<machine-id>/ 下，配合下一节的容量限额，就能实现”既保留重启前的历史日志，又不会无限增长”的目标。
三、容量限额：把日志总量锁进笼子
持久化解决了”日志去哪儿”的问题，容量限额解决”日志占多大”的问题。SystemMaxUse 是这里的核心参数，它定义日志归档可占用的磁盘上限，超过后 journald 自动删除最旧的归档。与之配套的还有三个参数，建议一起理解：
SystemKeepFree：日志写入时至少为磁盘保留的空闲空间，例如SystemKeepFree=2G表示日志最多增长到”总空间减 2 GB”为止SystemMaxFileSize：单个归档文件的大小上限，超过后切分新文件，取值需小于等于SystemMaxUseMaxRetentionSec：日志最长保留时长，例如14day表示超过两周的归档无条件删除
一个兼顾排障需求与空间安全的推荐配置如下：
sudo tee /etc/systemd/journald.conf.d/99-size-limit.conf > /dev/null <<'EOF'
[Journal]
Storage=persistent
SystemMaxUse=500M
SystemKeepFree=2G
SystemMaxFileSize=50M
MaxRetentionSec=14day
EOF
sudo systemctl restart systemd-journald
参数取值没有万能答案，可以按机器角色估算：Web 服务器日志增速通常在每天几十 MB 以内，500 MB 上限加两周保留已经足够回溯绝大多数故障；高频交易或审计类系统则需要按实际日志速率反推上限。修改后用 journalctl --disk-usage 复查，确认归档总量已被压到新上限之内。
若想立即释放空间而不等轮转自然生效，可以手动执行真空清理：sudo journalctl --vacuum-size=200M 把日志压到 200 MB，或 sudo journalctl --vacuum-time=7d 只保留最近 7 天。这两条命令即时生效，适合磁盘已经告急的应急处置。
四、实战案例：一次 12 GB 日志的治理过程
为了让上述配置落地，我们复盘一个真实案例：某台 4 GB 内存、40 GB 系统盘的 VPS（虚拟专用服务器，在单台物理机上虚拟出的独享资源环境），四个步骤总共用时不到十分钟。
第一步，确认现状：journalctl --disk-usage 显示 Archived and active journals take up 12.1G，df -h / 显示系统盘使用率 91%——膨胀程度足以解释磁盘压力。
第二步，定位增速来源：journalctl -p 3 -S -1d --no-pager | awk '{print $5}' | sort | uniq -c | sort -rn | head -5 统计最近一天的错误级日志来源，发现是某个 PHP 进程每秒输出数十行失败重试信息，日积月累撑大了日志。修复该服务后，日志增速回落到每天约 30 MB。
第三步，写入上一节的 99-size-limit.conf（SystemMaxUse=500M、MaxRetentionSec=14day）并重启 journald。
第四步，应急清理与验证：先执行 sudo journalctl --vacuum-size=500M 立即回收约 11.6 GB 空间，系统盘使用率降到 62%；一周后复查 journalctl --disk-usage 稳定在 500 MB 附近，说明限额已持续生效。
这个案例的关键在于”先堵增速、再设限额、最后清理”的顺序：如果只做清理不修服务，日志几天内就会卷土重来；如果只设限额不清理，空间要等轮转慢慢释放，救不了急。
五、常见坑与注意事项
配置过程中有几个高频翻车点，值得单独列出。
坑一：改完配置不重启服务。journald.conf 的修改必须 sudo systemctl restart systemd-journald 才生效，只保存文件不会有任何变化。极少数系统上重启 journald 会短暂影响个别服务的日志输出，建议在低峰期操作。
坑二：SystemMaxUse 设得比当前日志占用还小却没生效。journald 缩容是渐进式的，必要时手动执行一次 journalctl --vacuum-size= 强制对齐。另外检查单位书写：500M 与 500G 一字之差，后果天壤之别。
坑三：把 journald 日志与 /var/log/syslog、/var/log/messages 混为一谈。后者多由 rsyslog 从 journald 转发而来，属于传统文本日志，有自己的 logrotate 轮转体系；两者可能同时占空间，治理时需要分别用 du -sh /var/log 分解确认，别清了一半漏了一半。
坑四：限额设得过小导致排障信息丢失。如果把 SystemMaxUse 压到 50 MB 以下，一次稍微复杂的故障排查就可能超出保留窗口。除非磁盘极度紧张，建议给日志留出”两周保留或 500 MB”中较大的那个余量。
六、总结与后续建议
治理 journald 日志膨胀的核心动作可以归纳为一句话：持久化让行为可预期，限额让增长有边界，监控让问题早发现。如果你正在为云服务器的磁盘增长烦恼，建议按本文顺序执行：journalctl --disk-usage 摸底、Storage=persistent 固化行为、SystemMaxUse 加 MaxRetentionSec 双保险、必要时 vacuum 应急，最后把 --disk-usage 的输出纳入周期性巡检。
如果你需要更省心的系统日志与磁盘管理体验，也可以考虑 Hostease 的云服务器方案。更多运维实践，推荐延伸阅读我们的服务器配置与优化专栏和WordPress 网站性能优化指南；如果你在挑选或升级主机方案，VPS 主机与虚拟主机页面提供了规格与场景对照，方便按需选择。