先搞清楚 journald 是什么
很多 Linux 服务器跑久以后，都会遇到一个很典型的问题：业务程序没有明显增长，磁盘却一天比一天少。用 du 一层层查下去，最后发现 /var/log/journal 或 /run/log/journal 占了不少空间。这时候不少人第一反应是直接删除日志文件，但这并不是最稳妥的处理方式。
systemd-journald 是 systemd 体系里的日志服务，它会收集内核、系统服务、启动过程和应用输出的日志。你用 journalctl -u nginx、journalctl -xe、journalctl -b 看到的内容，大多都来自这里。它的价值很高：服务启动失败、内核报错、OOM、权限错误、端口占用、定时任务异常，很多线索都能在 journal 里找到。
问题在于，日志既是排障依据，也是磁盘消耗源。如果服务器没有设置合理的保留策略，长时间运行后 journal 文件可能越积越多。尤其是小配置云服务器、系统盘较小的 VPS、日志输出很频繁的容器或反向代理节点，更容易被日志慢慢吃掉空间。
所以处理 journald 日志，重点不是“看到大文件就删”，而是先确认占用、再按 systemd 推荐方式清理，最后设置上限，避免下次继续复发。
先看日志到底占了多少
排查前先用 journalctl 自带命令看占用：
journalctl --disk-usage它会直接输出 archived 和 active journal 文件的总占用，比盲目进入目录统计更直观。然后再结合磁盘整体情况判断是否紧急：
df -h
sudo du -sh /var/log/journal 2>/dev/null
sudo du -sh /run/log/journal 2>/dev/null/var/log/journal 通常代表持久化日志，重启后仍然保留；/run/log/journal 通常在内存运行目录下，重启后可能消失。不同发行版默认策略不完全一样，所以不要只凭某个目录是否存在就下结论。
如果 journalctl --disk-usage 显示只占几百 MB，而系统盘还有大量空间，就没有必要急着清理；如果它已经占到数 GB，甚至磁盘使用率超过 85%，就应该尽快处理。网站服务器磁盘被占满后，MySQL 写入、PHP session、缓存生成、日志追加、SSL 续期都可能一起出问题。
不要直接 rm journal 文件
虽然 journal 文件看起来就在目录里，理论上可以用 rm 删除，但线上服务器不建议这样做。原因很简单：journald 正在管理这些文件，直接删除可能导致当前打开的文件描述符仍然占用空间，df 看起来并不会马上释放；也可能破坏日志索引，让后续查询变得不完整。
更稳妥的做法是使用 journalctl 提供的 vacuum 清理命令。它会按 journald 的格式和状态处理旧日志，风险比手工删文件低得多。常用方式有三种：按保留时间、按保留空间、按文件数量。
按时间清理，例如只保留最近 7 天：
sudo journalctl --vacuum-time=7d按空间清理，例如把 journal 总量压到 500MB 左右：
sudo journalctl --vacuum-size=500M按文件数量清理，例如最多保留 10 个 journal 文件：
sudo journalctl --vacuum-files=10实际运维里，更推荐先按空间清理到一个安全范围，再设置长期上限。比如小型网站服务器系统盘只有 40GB，journal 保留 300MB 到 1GB 通常已经够排查近期问题；如果是生产业务、有审计要求或排障周期更长，就要结合日志平台和备份策略单独设计。
用配置限制后续增长
只清理一次不够。真正要避免复发，需要修改 journald 配置。主配置文件一般是：
/etc/systemd/journald.conf也可以在部分系统中使用 drop-in 配置目录。为了可维护性，很多团队会新建单独配置文件，例如：
sudo mkdir -p /etc/systemd/journald.conf.d
sudo nano /etc/systemd/journald.conf.d/limits.conf写入类似配置：
[Journal]
SystemMaxUse=1G
SystemKeepFree=2G
MaxRetentionSec=14daySystemMaxUse 表示持久化 journal 最多占用多少空间；SystemKeepFree 表示尽量给文件系统保留多少可用空间；MaxRetentionSec 表示最长保留多久。三者不是越小越好，要根据业务排障需求设置。太小会导致刚发生的问题还没来得及分析，日志已经被滚掉。
改完配置后重启 journald：
sudo systemctl restart systemd-journald随后再查看状态和占用：
systemctl status systemd-journald --no-pager
journalctl --disk-usage如果你管理的是网站服务器，建议把日志保留策略和备份、监控一起考虑。比如 速维云服务器 这类云服务器场景里，系统盘、数据盘、备份盘要分工明确，日志不要无限制挤占业务数据空间。配置再高的机器，如果日志策略失控，也会因为磁盘满而出现数据库写入失败或网站缓存异常。
清理后还要确认服务没有异常
清理 journal 之后，不要只看磁盘空间变大就结束。至少还应该检查三个点：journald 服务是否正常、最近日志是否还能写入、业务服务有没有新的错误。
可以先看 journald：
systemctl status systemd-journald --no-pager
journalctl -n 20 --no-pager再看关键业务服务，例如 Nginx、PHP-FPM、MySQL：
journalctl -u nginx -n 50 --no-pager
journalctl -u php-fpm -n 50 --no-pager
journalctl -u mysql -n 50 --no-pager不同系统服务名可能不同，PHP-FPM 也可能叫 php8.2-fpm、php8.3-fpm 或其他版本名。这里的重点不是照抄命令，而是确认清理动作没有掩盖正在发生的故障。
如果磁盘本来已经 100% 满，清理日志后还要检查数据库、缓存、上传目录、临时目录是否恢复正常。有些服务在磁盘满时会写入失败，需要手动重启或修复临时文件。尤其是 WordPress、论坛、商城、面板类网站，磁盘满可能导致缓存文件损坏或插件状态异常。
什么时候该接入集中日志
单机服务器用 journald 保留最近一段时间日志没有问题，但它不适合承担所有长期审计和复杂分析任务。如果你需要保存几个月日志、跨多台机器检索、分析异常 IP、统计接口错误率，就应该考虑集中日志方案，而不是把所有日志堆在系统盘。
常见思路包括：应用日志按天轮转，Nginx 访问日志用 logrotate 管理，重要系统日志发送到远程日志服务器，业务指标接入监控系统。journald 负责保留近期排障线索，集中日志负责长期分析和审计，这样职责更清楚。
中小网站最容易犯的错误，是把“能写日志”当成“日志系统已经做好”。真正可用的日志策略至少要回答几个问题：保留多久、最多占多少空间、谁负责清理、发生磁盘告警时先删什么、哪些日志必须长期保存。没有这些规则，日志迟早会从排障工具变成故障来源。
一套安全处理顺序
如果线上遇到 journald 占用过大，可以按下面顺序处理：
journalctl --disk-usage
df -h
sudo journalctl --vacuum-size=500M
sudo mkdir -p /etc/systemd/journald.conf.d
sudo nano /etc/systemd/journald.conf.d/limits.conf
sudo systemctl restart systemd-journald
journalctl --disk-usage
journalctl -n 20 --no-pager这套流程的核心是“先确认、再清理、再限制、最后验证”。不要上来就删除目录，不要把日志保留时间压得过短，也不要清完以后忘记检查服务状态。
对多数普通网站来说，journald 不是越多越安全，而是要保留足够排查近期问题的线索，同时不影响系统盘稳定运行。把日志占用控制在合理范围内，才是服务器长期稳定维护的一部分。
