journalctl 怎样按 PRIORITY 筛选错误级别日志

服务规模一上来，直接执行 journalctl 往往会被 info 和 notice 日志淹没。真正需要先缩小的是日志优先级：journalctl -p err 会取出 err 以及更严重的 crit、alert、emerg；如果只想看某一段等级，则使用 FROM..TO 范围。

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

记住一个关键点：单个优先级不是“只匹配这一档”，而是匹配该级别和更严重的级别；要精确限制上下边界，写成范围。

先把 PRIORITY 的顺序看成严重程度刻度

journalctl 使用常见的 syslog 等级，从 0 到 7 依次是 emerg、alert、crit、err、warning、notice、info、debug。数字越小，严重程度越高。这个顺序决定了单值查询的默认含义，也解释了为什么 -p 3 不只是数字 3。

在排障中可以把它看成两层边界：一层是日志条目上的 PRIORITY 字段，另一层是 journalctl 的查询条件。前者描述事件等级，后者负责把整本日志缩小到可读范围。

单个等级适合快速捞出错误及更严重事件

-p 是 --priority 的短选项。下面的命令只负责查询当前 journal，不修改日志内容；--no-pager 让结果直接输出，便于保存到工单或继续管道处理。

# 取出 err 及更严重的日志，避免分页器打断排障记录
journalctl --priority=err --no-pager

# 用数字 3 表示 err，含义与文本写法相同
journalctl -p 3 -n 100 --no-pager

# 只看某个服务最近的错误，先缩小服务边界再缩小优先级
journalctl -u nginx.service -p err -n 100 --no-pager

这里的 err 相当于上边界：emerg 到 err 都会被保留，而 warning、notice、info 和 debug 会被排除。若把它误解成“只看 err 一档”，排查结果就会漏掉更严重的崩溃或不可用事件。

需要可控范围时使用 FROM..TO

当告警噪声本身也值得观察，或者你想区分 warning 与 error，使用两个等级和两个点号连接的范围。例如 warning..err 包含 warning、err 以及中间的等级，范围两端都包含。

# 只保留 err 到 warning，观察错误和紧邻的告警
journalctl -p err..warning --since "today" --no-pager

# 数字写法表达同一个闭区间：3 到 4
journalctl --priority=3..4 -u nginx.service --no-pager

# 只取严重级别 0 到 2，不把普通 err 混进来
journalctl -p emerg..crit -b 0 --no-pager

范围两端不要求按从小到大的顺序书写，文本名通常更容易复核。实际值仍以等级表为准：err..warning 是常见的“错误到告警”窗口，而不是字符串字典序比较。

把优先级过滤放进实际排障入口

定位线上服务时，优先级只是第一层筛选。服务名、启动批次和时间范围负责缩小来源与时间，-o 负责让输出适合后续处理。组合条件越具体，越容易判断“没有结果”究竟是没有该等级，还是查询边界写错。

# 查看本次启动中某服务的错误，带完整消息并禁用分页
journalctl -b -u nginx.service -p err -o short-precise --no-pager

# 将 warning 到 err 的窗口按 JSON 输出给脚本继续处理
journalctl -u nginx.service -p warning..err -o json --no-pager

建议先用文本等级确认结果，再在脚本化场景中改成数字或固定范围。若命令没有输出，不要立刻判定服务没有问题：还要检查当前用户是否有读取对应 journal 的权限、服务名是否准确，以及时间或启动批次条件是否过窄。

常见问题

为什么 journalctl -p err 会出现 crit？ 因为单值优先级包含该级别及所有更严重级别；这是手册规定的筛选语义。

怎样只看 warning？ 使用精确闭区间 journalctl -p warning..warning，或者在脚本中明确使用对应数字 4。

数字和文本哪种更适合脚本？ 两者都支持。文本更直观，数字更紧凑；团队脚本应统一一种写法，并在注释中写明等级含义。