systemd-journald 日志限速丢弃怎么调整

systemd-journald 出现“日志过多，部分消息被丢弃”时，优先调整 RateLimitIntervalSec= 和 RateLimitBurst=，而不是直接关闭日志。全局配置影响每个服务各自的限速窗口；如果只有一个高噪声服务，应改它的 LogRateLimitIntervalSec= 与 LogRateLimitBurst=，这样不会放大全机的日志写入量。

官方资料：https://www.freedesktop.org/software/systemd/man/latest/journald.conf.html

最稳妥的处理顺序是：先确认确实触发 journald 限速，再用 drop-in 文件增大窗口或突发值，最后重启 journald 并观察新的日志窗口。只有在明确接受日志洪峰和磁盘成本时，才考虑关闭限速。

先确认丢弃提示与当前生效配置

journald 的限速按服务分别计算，默认时间窗是 30 秒、突发上限是 10000 条。一个服务刷屏不会直接消耗另一个服务的同一计数器，但这不代表磁盘和 I/O 没有压力。先查本次启动中的提示，再看合并后的配置，避免只看配置文件里的注释值。

# 先找出 journald 报告的丢弃提示，确认症状不是磁盘或权限错误
journalctl -u systemd-journald -b --no-pager | grep -E 'dropped|suppressed|rate limit'

# 查看主配置、conf.d 和发行版默认值合并后的结果
systemd-analyze cat-config systemd/journald.conf

# 记录当前 journal 占用，调整突发上限时要同时考虑磁盘预算
journalctl --disk-usage

如果没有匹配到提示，不要仅凭“日志少了”就调大限速；还要检查服务是否改成了别的输出目标、是否在内存盘上运行，以及是否有独立的单元级限速。

用 journald.conf.d 调整全局限速

全局调整建议使用 /etc/systemd/journald.conf.d/ 下的独立文件，方便审计和回滚。下面的数值只是示例：把窗口改为 60 秒、每个服务允许 20000 条，适合需要短时保留更多启动日志的场景，不是所有主机的通用上限。

# 只为全局默认值增加容忍度，仍保留每个服务的独立计数
[Journal]
RateLimitIntervalSec=60s
RateLimitBurst=20000

# 创建 drop-in 目录，避免直接覆盖发行版主配置
sudo install -d -m 0755 /etc/systemd/journald.conf.d
sudoedit /etc/systemd/journald.conf.d/20-rate-limit.conf

# 让 journald 重新读取配置；该动作不会清空已经保存的日志
sudo systemctl restart systemd-journald

# 重新查看生效配置，确认 drop-in 没有拼写或优先级问题
systemd-analyze cat-config systemd/journald.conf

不要只改一个参数。官方规则是 RateLimitIntervalSec= 和 RateLimitBurst= 必须成对理解；任一值设为 0，都会把两者调整为 0，从而关闭限速。关闭后要配合 SystemMaxUse=、RuntimeMaxUse= 等存储预算，否则“没有丢日志”可能换来磁盘被写满。

只给高噪声服务设置独立上限

如果只有某个采集器、调试服务或批处理任务在短时间内产生日志，优先把限制放到服务单元。单元级设置会覆盖该服务继承到的全局默认值，其他服务仍按 journald 的全局配置运行。

# 这是目标服务的 drop-in，例如 /etc/systemd/system/example.service.d/log-rate.conf
[Service]
# 只提高 example.service 的窗口，不改变其他服务
LogRateLimitIntervalSec=60s
LogRateLimitBurst=50000

# 让 systemd 重新读取单元 drop-in，并重启目标服务加载新配置
sudo systemctl daemon-reload
sudo systemctl restart example.service

# 查看目标服务的合并配置，确认单元级参数已出现
systemd-analyze cat-config systemd/system/example.service

# 用服务名观察后续日志，避免把别的服务的结果混在一起
journalctl -u example.service -b -f

实际路径可能是模板单元或用户服务，先用 systemctl status 确认单元名。若服务自身设置了 LogRateLimitIntervalSec= 或 LogRateLimitBurst=，只修改 journald 全局文件可能看不到效果。

重启 journald 后按证据复查

调大参数不是“修复完成”的证明。保留调整前后的值，在下一次业务高峰观察同一时间窗内的丢弃提示和磁盘变化。若日志洪峰来自异常循环，应该修服务本身；限速只是保护 journald 的最后一道边界。

可以把下面的检查项写进变更记录：

• 是否确认了被丢弃的是哪个服务、哪个启动周期？
• 是否记录了旧值、新值和回滚文件？
• 是否同时检查持久化日志与运行时日志的磁盘预算？
• 是否在新的限速窗口结束后再次检查 journalctl 输出？

常见问题

把 RateLimitBurst 设得很大就一定不会丢吗？

不一定。有效限额还会受到时间窗、服务单元覆盖项和可用磁盘空间因素影响；更大的值也会增加 I/O 与存储压力。

能不能直接把两个参数设为 0？

可以关闭 journald 的这类限速，但这只是取消保护，不会修复制造洪峰的服务。生产环境通常先做单服务覆盖和短时观测，再决定是否需要关闭。