Linux journalctl 怎样按优先级筛出启动错误日志

排查 Linux 启动故障时，最容易混淆的是“哪一次启动”和“哪一种严重程度”。journalctl --boot 负责选择启动批次，--priority（短选项是 -p）负责过滤消息级别。两者叠加后，就能把范围收敛到“指定启动中的 error 及更严重日志”。

官方文档：https://www.freedesktop.org/software/systemd/man/255/journalctl.html

最常用的起点是 journalctl -b 0 -p 0..3 --no-pager：-b 0 选当前启动，0..3 覆盖 emerg 到 err。若只想看当前启动的错误及更严重级别，也可以写成 -p err。

journalctl 的两个筛选轴：启动批次与消息优先级

-b 或 --boot 会增加 _BOOT_ID 匹配条件。-b 0 是当前启动，-b -1 是上一次启动；--list-boots 可以先列出相对启动编号、ID 和时间范围。

-p 或 --priority 针对日志的 PRIORITY 字段。级别从 0 到 7 依次是 emerg、alert、crit、err、warning、notice、info、debug。给单个级别时，会包含该级别以及更严重的消息；给范围时，范围两端都包含。

图1：journalctl 的启动范围与消息优先级边界说明图。

先用一条命令筛出启动错误

如果目标是判断这次启动有没有高严重度日志，可以先查看当前启动的 0 到 3 级消息。这里使用数字范围，是为了避免读者把文字级别顺序写反。

# 查看当前启动中的 emerg 到 err，关闭分页便于保存输出
journalctl -b 0 -p 0..3 --no-pager

# 查看上一次启动中的 error 及更严重消息
journalctl -b -1 -p err --no-pager

# 先列出启动编号、启动 ID 和首尾时间，再决定要查哪一批
journalctl --list-boots --no-pager

若还要包含 warning，可以把范围扩大为 0..4；如果只需要 error 及更严重级别，-p err 更直观。--no-pager 只改变输出方式，不改变筛选集合。

把优先级过滤收敛到具体服务

启动错误通常还要回答“是谁产生的”。把 --unit、内核选项或时间边界与优先级一起使用，可以继续缩小同一份 journal 集合。不同字段的匹配条件会同时生效，所以这类组合相当于交集。

# 只看 nginx 服务在当前启动中的 error 及更严重日志
journalctl -b 0 --unit=nginx.service -p 0..3 --no-pager

# 只看当前启动的内核错误，-k 会加入内核传输条件
journalctl -b 0 -k -p 0..3 --no-pager

# 只看时间窗口内的高严重度日志，时间字符串按本机环境解析
journalctl --since "today 08:00:00" --until "today 09:00:00" -p 0..3 --no-pager

如果服务名不确定，可以先去掉 --unit 看全局结果，再用日志中的 unit 名称收窄。不要把 -k 当成“启动日志”开关：它表示只看内核消息，并且会隐含当前启动条件。

图2：优先级、服务、内核和时间窗口的组合条件说明图。

空结果、权限和输出格式怎么判断

命令没有输出不一定表示系统没有错误。先拆成三种情况：第一，筛选条件太窄，例如指定了错误的启动编号或只查 0..3；第二，日志只保留在内存中，重启后无法从持久目录回看；第三，当前用户没有读取系统 journal 的权限。可以先用较宽条件确认可见范围，再决定是否用具备权限的账号读取。

需要把结果交给脚本处理时，关闭分页并固定格式；需要人工比较时间时可以使用带微秒的短格式：

# 保留微秒时间，适合比较启动阶段相邻事件的先后
journalctl -b 0 -p 0..3 -o short-precise --no-pager

# 输出结构化 JSON，便于后续提取 PRIORITY、_BOOT_ID 和 MESSAGE
journalctl -b 0 -p 0..3 -o json --no-pager

结构化输出不是新的过滤条件；它只改变展示形态。若要查看完整字段，可以再考虑 -o verbose，但要注意输出会明显变长。

常见问题

-p err 会不会漏掉 warning？

会。单个 err 表示 err 以及更严重级别，不包含 warning；需要 warning 时使用 0..4 或文字范围。

为什么 -b -1 查不到旧日志？

可能是旧启动日志已经被清理，也可能当前用户只能看到自己的 journal。先运行 journalctl --list-boots 看可见启动集合，再检查持久化和读取权限。

怎样同时限定服务和错误级别？

把 --unit=服务名 与 -p err 放在同一条命令即可；不同字段条件会同时匹配，结果会比全局查询更窄。

总结

记住职责分工即可：--boot 解决“哪一次启动”，--priority 解决“多严重的消息”，--unit、-k 和时间选项再解决“谁产生、属于哪个时间段”。先用宽范围确认日志可见性，再逐步叠加条件，通常比一开始就写很长的过滤命令更容易定位启动故障。