systemd journald 日志膨胀治理：从磁盘打满到保留策略

journald 默认会持久化日志，但如果某个服务开始疯狂打日志，/var/log/journal 可以在一夜之间打满分区，导致服务无法启动、系统行为异常。治理的关键是先止损，再找到源头，最后配置保留策略。

先看占用情况

journalctl --disk-usage
du -sh /var/log/journal/*
journalctl -p err -b          # 只看本次启动的错误日志，找高频来源

--disk-usage 会直接显示已用空间与可回收空间。若磁盘告急，先执行真空清理释放空间：

journalctl --vacuum-size=500M    # 保留最近 500M
journalctl --vacuum-time=7d      # 保留最近 7 天
journalctl --vacuum-files=5      # 只保留最近 5 个文件

不要直接 rm journal 文件：systemd 的索引与文件状态可能不一致，用官方 vacuum 命令更安全。

编辑 /etc/systemd/journald.conf：

[Journal]
SystemMaxUse=1G
SystemKeepFree=2G
SystemMaxFileSize=100M
MaxRetentionSec=1week
RateLimitIntervalSec=30s
RateLimitBurst=10000

SystemMaxUse 是 journal 目录的总上限，SystemKeepFree 为其他文件保留磁盘余量；RateLimitIntervalSec/RateLimitBurst 限制每服务每 30 秒最多写入 1 万条，可挡掉大部分日志风暴。修改后重启生效：

systemctl restart systemd-journald

应用把日志打到 stdout 且 StandardOutput=journal 时，所有输出都会进 journal，检查 systemd unit 的日志重定向配置
错误风暴通常是应用在死循环重试，journalctl -u <service> --since=-10m 确认重复模式
内核与防火墙日志（kern.*）在异常网络下也可能刷屏，结合 dmesg 交叉确认

应急顺序：先 vacuum 释放空间保住系统，再定位并修复日志源，最后才谈策略。反过来做，磁盘会在修复前再次打满。

journald 不适合做长期存储。生产环境应把日志转发到集中平台（rsyslog、Vector、Fluent Bit 等），journal 只保留本地缓冲：

[Journal]
ForwardToSyslog=yes
ForwardToConsole=no

转发配置同样需要限流与字段裁剪，避免把风暴原样转发出去。集中平台再按索引、压缩和保留周期统一治理。

把 journal 目录占用、每服务日志速率纳入监控与告警；为新增服务默认开启日志上限；定期演练 vacuum 与转发链路的恢复。日志治理的目标不是删日志，而是让日志在需要时找得到、在不需要时不占空间。