Linux journalctl按 unit 与时间窗口筛选日志的实现方法

排查 Linux 服务异常时，先别把整本 journal 倒出来。更稳妥的做法是把 systemd unit 和时间窗口同时写进 journalctl：先限定“哪一个服务”，再限定“哪一段时间”。这样得到的结果更容易和发布、重启或告警时间对照。

官方手册：https://www.freedesktop.org/software/systemd/man/latest/journalctl.html

先把 unit 与时间窗口写成一个最小查询

假设要查看 api.service 在上午 9 点到 10 点之间的记录，可以先使用下面的查询。示例只表达查询条件，不把输出假定成某台机器上的真实结果。

# 同时限定服务和时间，--no-pager 便于复制结果
journalctl --no-pager -u api.service \
  --since "2026-09-15 09:00:00" \
  --until "2026-09-15 10:00:00"

-u 是 --unit 的缩写。--since 表示不早于指定时刻，--until 表示不晚于指定时刻。不同类型的条件会一起收窄结果，因此这条命令不是先查完整服务日志再由 shell 截取，而是把筛选条件交给 journal 查询层。

unit 匹配的是 systemd 身份，不只是进程名称

--unit=api.service 对应 journal 条目里的 _SYSTEMD_UNIT=api.service 等结构化信息。它比按进程名猜测更适合排查服务，因为 systemd 还可能记录服务管理器本身发出的消息、退出状态和与该 unit 相关的事件。

如果要同时看两个服务，可以重复写 -u。同一个字段有多个匹配值时，它们是候选关系；而 unit 条件和时间条件属于不同字段，会共同限制结果：

# 两个 -u 表示两个 unit 候选，时间窗口仍对整体结果生效
journalctl --no-pager -u api.service -u worker.service \
  --since "today" --until "now"

# 固定当前启动周期，避免把上一次启动的同名服务混进来
journalctl --no-pager -b 0 -u api.service \
  --since "-30 min" --output=short-full

如果服务使用模板 unit，例如 worker@1.service，不要只凭进程名判断。可以先确认实际 unit 名，再把完整实例名传给 -u；需要匹配一组实例时，再使用文档支持的 unit pattern。

时间边界要和故障证据保持同一口径

固定日期适合复盘发布窗口；today、now 和带正负号的相对时间适合值班排查。省略时间部分时，systemd 会按时间规范补齐，生产命令最好显式写到秒，避免读者或脚本对边界产生不同理解。

如果故障跨过重启，单靠时间窗口可能仍会混入多个启动周期。此时加上 -b 0 看当前启动，或用 --list-boots 先确认可用的启动记录，再决定是否查询 -b -1 等上一轮启动。

结果为空时按四个边界逐层收窄

空结果不等于服务没有产生日志。先执行 journalctl -u api.service -n 20 去掉时间限制：若仍为空，优先检查 unit 名是否写错，或者当前用户是否只能读取自己的 journal。若能看到记录，再把时间窗口逐步加回去，检查时间格式、时区和启动编号。

还要区分 system journal 与 user journal。系统服务通常使用系统日志，用户级服务则可能需要 --user；如果只保留运行时日志，机器重启后旧记录也可能不可见。下面这张图把这些查询边界放在同一张结构图里，便于定位“条件没匹配”与“数据本身不可见”的差别。

# 先只确认服务最近是否有记录，再恢复时间范围
journalctl --no-pager -u api.service -n 20

# 用户级 unit 使用 user journal 语义；不要与系统服务混用判断
journalctl --user --no-pager -u sync.service \
  --since "-1 hour" --output=short-full

最后固定输出格式再保存证据，例如使用 --output=short-full 保留完整时间信息。本文范围只覆盖查询条件；日志保留、轮转和磁盘清理属于 journald 存储策略，应单独核对配置。

常见问题

为什么加了 --since 后结果突然为空？

最常见原因是事件实际发生在窗口之外，或主机时区与告警系统不一致。先去掉时间条件确认 unit 有记录，再用固定到秒的时间范围复查。

多个 -u 是并集还是交集？

同一字段的多个 unit 匹配是候选关系；不同字段的 unit、时间和启动条件会共同收窄结果。

普通用户为什么看不到系统服务日志？

journal 的可见范围受用户权限和系统配置影响。先确认是否能读取系统 journal；不要把权限不足误判为服务没有产生日志。

实际排障可以固定成一条短路径：先用完整 unit 查最近 20 条，再加启动周期，最后补上明确的时间窗口和输出格式。这样每一步都能说明是筛选条件变了，还是日志可见范围变了。