systemd-journald 限流日志突发时为什么出现 rate limit 提示怎样完成一个可复用的最小示例

日志突发时看到 rate limit，通常不是 systemd-journald 进程挂了，而是同一个服务在一个限流时间窗口里写入的消息超过了额度。超过 RateLimitBurst 的消息会被丢弃，窗口结束后才恢复接收；提示本身用于告诉你期间有日志没有进入 journal。

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

下面用一个可复用的 drop-in 配置示例，把全局默认值改成“30 秒最多 2000 条”，再说明服务级覆盖、重启方式以及什么时候不应该关闭限流。文中的图片是静态结构说明图，不是截图，也不是本机运行证据。

先判断 rate limit 提示到底说明了什么

systemd-journald 的限流按服务分别计算：某个服务在 RateLimitIntervalSec 定义的窗口内写入数量超过 RateLimitBurst 后，剩余消息会在窗口结束前被丢弃，同时 journal 会生成一条说明丢弃数量的消息。另一个服务的日志不会因为这个服务超额而共用同一额度。

官方文档给出的默认值是 30 秒和 10000 条，但实际有效额度还会受到 journal 可用磁盘空间因素影响。因此排查时不要只看到一条提示就把它当作磁盘损坏；先确认是哪个 unit 在短时间内重复输出。

用 drop-in 配置完成一个最小示例

把本地调整放在 /etc/systemd/journald.conf.d/，比直接改主配置文件更容易管理和回滚。下面的示例只改变限流窗口与额度，适合先处理日志突发而不完全关闭保护。

# 只为 journald 设置一个可追踪的本地覆盖文件
[Journal]
# 统计窗口为 30 秒，窗口内的计数按服务分别计算
RateLimitIntervalSec=30s
# 单个服务在窗口内最多保留 2000 条日志
RateLimitBurst=2000

保存为 /etc/systemd/journald.conf.d/20-rate-limit.conf。数值不是越大越好：突发任务确实需要更多日志时可以提高额度，但更应该先减少循环中的重复输出，并给关键错误保留独立的告警通道。

让配置进入 journald，并保留复查路径

配置文件被修改后，要让 journald 重新读取配置。下面的命令只展示发布动作和观察入口，实际执行时请按发行版权限策略操作。

# 让 systemd 重新扫描 unit 与 drop-in 文件
sudo systemctl daemon-reload

# 重新启动日志守护进程，使新的 Journal 配置生效
sudo systemctl restart systemd-journald

# 按服务查看最近日志，先替换成实际的 unit 名称
sudo journalctl -u your-service.service -n 100 --no-pager

# 在当前 journal 中查找限流提示，帮助确认丢弃说明来自哪里
sudo journalctl -b --no-pager | grep -i "rate limit"

不要把上面的示例输出描述成已经在本机验证过的结果。真正复查时重点看三件事：提示对应的服务、提示发生的时间窗口，以及调整后的日志是否仍然持续超额。只要服务继续以高频率打印相同内容，单纯提高额度只是把问题推迟。

服务级配置可能覆盖全局设置

如果 unit 自己配置了 LogRateLimitIntervalSec 或 LogRateLimitBurst，它们会覆盖 journald.conf 中的全局值。也就是说，全局配置改大后，某个服务仍然出现 rate limit，并不一定代表 drop-in 没生效，还要查看该服务的 unit 配置和 drop-in。

# 这是服务级设置的示意，只有确实需要时才放进 unit 的 drop-in
[Service]
# 让该服务单独使用 10 秒窗口
LogRateLimitIntervalSec=10s
# 该服务每个窗口允许 500 条消息
LogRateLimitBurst=500

systemd 文档还说明，把任一限流值设为 0 可以关闭对应的限流。生产环境不建议为了消除提示就全局关闭：日志风暴可能占满存储、拖慢检索，并掩盖真正的故障。只有在明确知道日志量、存储上限和替代采集链路时，才考虑对单个服务做定向调整。

常见误区与结论

最小可复用做法是：用 drop-in 管理 RateLimitIntervalSec 与 RateLimitBurst，重启 journald 后按服务复查；若仍有提示，再查服务级覆盖。这样既能解释 rate limit 的来源，也不会把“没有提示”误认为“日志完整”。

相关问题

RateLimitBurst 是按整台机器计算吗？

不是。journald 的通用限流按服务分别应用，两个服务的消息不会共用同一个计数。

为什么提高全局 Burst 后仍然丢日志？

常见原因是 unit 级的 LogRateLimitBurst 覆盖了全局值，也可能是服务持续产生日志，新的额度仍然在窗口内被耗尽。

什么时候可以关闭 journald 限流？

只有在日志量、磁盘空间和采集链路都可控，并且你确实需要完整保留突发消息时，才考虑对明确的服务关闭；不建议用全局关闭来掩盖重复输出。