journald 如何按服务和启动批次筛选日志

排查服务“刚才为什么失败”时，单独执行 journalctl -u nginx.service 往往会把多次启动、多个时间段的记录混在一起。更稳妥的做法是先用 journalctl --list-boots 找到目标启动批次，再把 unit、boot 和时间窗口放在同一条命令中。三个条件会同时生效，结果更容易和一次故障对应起来。

常用组合是 journalctl --unit=nginx.service -b -1 --since "2026-09-12 09:00:00" --until "2026-09-12 09:15:00" -o short-full。其中 -b -1 表示上一次启动；如果要查当前启动，把它换成 -b 0 或直接写 -b。

先确认启动批次，再组合筛选条件

启动批次是这类查询里最容易漏掉的边界。服务在重启前后可能使用相同的 unit 名称，如果只按服务过滤，就很难判断一条记录属于哪次启动。先执行下面的命令，观察偏移量和起止时间：

# 列出本机 journal 中可识别的启动批次，先确认 -1 对应哪次启动
journalctl --list-boots

# 查看上一次启动中 nginx.service 的最后 80 条记录
journalctl --unit=nginx.service --boot=-1 -n 80 --no-pager

输出中的 0 通常代表当前启动，-1 代表前一次启动。不要只凭偏移量猜时间；如果机器导入了其他目录的 journal，应该结合 BOOT ID 和时间范围一起判断。

用 unit 把服务范围收窄

--unit=UNIT（短写法是 -u UNIT）用于匹配 systemd unit。服务名一定要写成系统实际登记的名字，例如 nginx.service，不要把进程名、配置文件名当成 unit。可以先用状态命令确认名称：

# 只确认服务的 systemd 名称和当前状态，不把状态输出当作 journal 结果
systemctl status nginx.service --no-pager

# 只读取这个 unit 的日志，避免把同一时间的其他服务混进来
journalctl -u nginx.service -n 40 --no-pager

如果 unit 是模板实例，例如 worker@2.service，就写完整实例名；写成模糊的进程名可能得到空结果，也可能把不相关的日志带进来。对 slice 或模式匹配要更谨慎，先验证匹配范围再扩大查询。

叠加 boot 与时间窗口定位故障段

确认 unit 后，把启动批次和时间边界放进同一条查询。下面的时间只是示例，生产排障时替换成故障发生前后的真实时间：

# 同时限定服务、上一次启动和 09:00 到 09:15 的时间窗口
# --no-pager 避免分页器截断自动化排障输出，-o short-full 保留完整时间
journalctl --unit=nginx.service --boot=-1 \
  --since "2026-09-12 09:00:00" \
  --until "2026-09-12 09:15:00" \
  --no-pager -o short-full

这些条件是逻辑 AND：同一条记录必须属于目标 unit、目标 boot，并且落在时间区间内。若故障恰好发生在启动切换附近，时间范围可以略微向前后扩展，但不要先删掉 --boot；否则相邻启动的同名服务会混在一起。

用输出格式核对筛选结果

默认输出适合快速浏览，但定位跨重启问题时，完整时间更重要。-o short-full 会把星期、年份和时区信息展示出来；需要进一步交给脚本处理时，再考虑 -o json-pretty。图中的字段是结果核对示意，不代表某台机器的真实执行输出。

# 用结构化 JSON 观察字段时保留少量结果，便于人工核对后再交给脚本
journalctl -u nginx.service -b -1 \
  --since "2026-09-12 09:00:00" --until "2026-09-12 09:15:00" \
  -o json-pretty -n 20 --no-pager

人工核对时至少看三件事：时间是否落在目标窗口、记录是否带有目标 unit、消息内容是否属于这次故障。若用 JSON 处理，还可以关注 _SYSTEMD_UNIT、_BOOT_ID、__REALTIME_TIMESTAMP 和 MESSAGE；不要只按文本关键字 grep 后就下结论。

空结果时按边界逐项排查

组合条件带来的好处是精确，代价是任意一项写错都会得到空结果。建议按下面顺序收敛：

1. 先去掉时间条件，只保留 journalctl -u nginx.service -b -1，确认该 unit 在该启动批次确实有记录。
2. 再执行 journalctl --list-boots，核对 -1 的时间范围是否覆盖故障。
3. 确认当前用户能读取系统 journal；必要时使用具备相应权限的运维账号，但不要把权限错误误判成没有日志。
4. 如果历史启动完全查不到，检查发行版的 journald 持久化配置和日志目录，而不是无限扩大 --since。

还要区分“没有匹配记录”和“日志根本不可见”：前者是筛选条件问题，后者可能是权限、日志轮转或持久化策略问题。排障记录中最好同时保存完整命令、目标 BOOT ID 和时间窗口，下一位值班同事才能复现同一范围。

常见问题

只写 -b -1 不写 unit 可以吗？

可以，但会得到整个上一次启动的日志，数据量和噪声都更大。定位单个服务时优先加上 -u。

--since 和 --until 能单独使用吗？

可以。只写 --since 表示从某个时间开始，只写 --until 表示查询到某个时间结束；故障窗口明确时两者一起写更不容易误读。

为什么 unit 名称正确仍然没有日志？

可能是目标启动批次没有该 unit 的记录、历史 journal 未持久化，或当前用户没有读取权限。先分别去掉时间条件和 boot 条件定位是哪一层造成空结果。

journalctl 的输出能直接当作真实运行证据吗？

文章中的代码块是可复现命令，配图是解释性示意。真实事故记录应保留目标主机、BOOT ID、执行时间和原始输出，并遵守日志脱敏要求。

把服务、启动批次和时间窗口同时写进命令，核心价值不是让命令更长，而是让“这条日志为什么属于这次故障”有明确边界。先列批次、再确认 unit、最后收窄时间，是比较稳的 journalctl 排障顺序。