systemd-journald 限流日志突发时为什么出现 rate limit 提示为什么结果为空或不符合预期

服务在启动、重试或批处理时突然打出大量日志，随后 journalctl 里出现 rate limit 提示，甚至感觉“中间一段日志不见了”。这通常不是 journalctl 查询错了，而是 systemd-journald 在一个时间窗口内按服务统计消息，超过突发额度后主动丢弃窗口内的后续消息。

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

处理这个问题的关键不是第一时间把限流关闭，而是先确认哪一个服务触发了突发量，再决定提高额度、缩短影响范围，还是保留限制并修复日志风暴。

rate limit 提示表示 journald 保护日志系统时丢弃了超出额度的消息；默认规则按服务分别计算，不代表所有服务共享一个全局计数器。

为什么会出现 rate limit 提示

RateLimitIntervalSec= 定义统计窗口，RateLimitBurst= 定义窗口内允许的消息数量。某个服务在窗口内超过额度后，后续消息会被丢弃，journald 还会记录一条关于丢弃数量的提示。窗口结束后，计数才会重新进入下一轮。

这个计数是按服务拆开的，所以 worker.service 的日志突发不会直接消耗 api.service 的额度。可是，磁盘可用空间还会影响有效的突发倍数；因此不要只拿配置文件中的数字推断现场一定能保留多少条日志。

先把“日志为空”分成两种情况

如果某个服务的日志在突发时段缺了一段，同时能看到 rate limit 相关提示，优先按 journald 丢弃处理。若整个服务都没有日志，则还要排查 unit 的标准输出目标、日志级别、服务是否真正启动，以及查询时使用的时间范围；不能把所有空结果都归因于限流。

可以先读取服务最近的日志和 unit 状态。下面的命令只是排查示例，输出内容取决于你的机器：

# 把服务名替换成实际 unit，先看状态和最近一段日志
sudo systemctl status my-worker.service --no-pager
sudo journalctl -u my-worker.service -n 200 --no-pager

# 用时间范围缩小到突发发生的窗口，避免把旧日志混在一起
sudo journalctl -u my-worker.service --since "10 minutes ago" --no-pager

这一步的判断重点是“哪个 unit 在什么时候出现密集输出”，而不是盯着日志总条数。服务本身的重试循环、错误栈重复打印或过细的调试日志，往往才是突发源头。

全局配置和单元级配置怎么选

需要统一保护整台机器的日志系统时，可以在 journald.conf 的配置片段中调整全局默认值；只有一个系统服务确实需要更高突发额度时，则优先考虑该 unit 的 LogRateLimitIntervalSec= 和 LogRateLimitBurst=。单元级设置能把影响范围限制在目标服务，避免为了一个批处理任务放大所有服务的日志洪峰。

# /etc/systemd/journald.conf.d/30-log-burst.conf
# 只示意一个较宽的窗口与额度，实际数值要按日志容量和保留要求估算
[Journal]
RateLimitIntervalSec=30s
RateLimitBurst=20000

# 这是 systemd 服务单元中的配置示意，不要把它误写到 [Journal]
# 仅让指定服务拥有不同的日志突发上限
[Service]
LogRateLimitIntervalSec=30s
LogRateLimitBurst=20000

如果只是想临时观察问题，宁可先提高某个服务的额度并观察磁盘、日志保留和下游采集压力，也不要直接把两项设为 0。关闭限流意味着日志风暴可以把写入、存储和采集链路一起推高。

改完以后怎样复查是否真的生效

配置修改后要让 journald 重新读取配置；如果改的是 unit 文件或 drop-in，还要让 systemd 重新加载 unit 定义，再重启或重新启动目标服务。下面给出顺序示例：

# 让 journald 重新读取 [Journal] 配置
sudo systemctl restart systemd-journald.service

# 如果修改的是 unit/drop-in，先刷新 unit 定义，再重启目标服务
sudo systemctl daemon-reload
sudo systemctl restart my-worker.service

# 重新观察同一服务的时间窗口，确认是否仍出现限流提示
sudo journalctl -u my-worker.service --since "5 minutes ago" --no-pager

复查时看三件事：目标服务是否仍在重复产生同类消息；限流提示是否只在突发窗口出现；调整后日志量是否给磁盘和采集端带来新的压力。配置生效不等于问题消失，若根因是无限重试或重复打印，仍应修正服务代码和重试策略。

常见误区和适用边界

• 把 rate limit 当成 journal 损坏：它通常是保护机制主动丢弃消息，不等于 journal 文件已经损坏。
• 只改全局值：一个服务的问题可能因此影响整台机器，优先判断是否能用 unit 级设置隔离。
• 看到空结果就关闭限流：先确认 unit、时间范围和输出目标，再处理真正的突发源。
• 忽略容量：提高额度会增加写入与保留压力，必须结合磁盘空间、采集端吞吐和日志价值评估。

相关问题

RateLimitIntervalSec 和 RateLimitBurst 必须一起改吗？

它们共同定义窗口和窗口内额度。只改其中一项会改变整体行为，建议把两项作为一个容量决策一起记录，并在相同时间范围内复查。

为什么只提高 Burst 仍然偶尔丢日志？

可能是窗口仍然太短、日志量再次超过额度，也可能是有效突发倍数受可用磁盘空间影响。还要确认服务是否使用了单元级 LogRateLimit* 覆盖全局设置。

遇到 rate limit 提示时，先定位触发 unit，再区分全局默认与单元覆盖，最后同时复查日志风暴和存储压力。这样既能减少不必要的丢失，也不会把一次突发故障变成整台机器的日志洪峰。