journalctl日志优先级为0–7，数值越小越紧急：0 emerg（系统不可用）、1 alert（须立即干预）、2 crit（临界状态）、3 err（错误）、4 warning（潜在风险）、5 notice（正常但重要）、6 info（常规信息）、7 debug（调试输出）；常用过滤如-p3仅显示错误及以上，-p4包含警告及以上，结合-u和-b可精准定位问题。

journalctl 的日志优先级是排查问题的关键线索，不是所有日志都同等重要。优先级本质是严重程度标记，数值越小代表问题越紧急，越值得第一时间关注。

日志优先级对应关系与含义

journalctl 使用 0 到 7 的整数表示 8 个标准优先级，数字越小越严重：

• 0 emerg：系统已不可用，比如内核崩溃、电源彻底中断
• 1 alert：必须立即人工干预，如磁盘即将满、关键服务完全宕机
• 2 crit：临界状态，可能很快升级为 alert，例如 RAID 阵列降级
• 3 err：明确的错误，服务启动失败、配置加载出错等常见故障源头
• 4 warning：潜在风险提示，如证书即将过期、内存使用率持续偏高
• 5 notice：普通但值得注意的事件，如服务正常重启、用户登录成功
• 6 info：常规运行信息，多数为后台例行动作，调试时参考
• 7 debug：详细调试输出，仅开发或深度排障时启用，量大且非默认记录

按优先级快速筛选实用命令

日常运维中，直接过滤高危日志能大幅缩短定位时间：

• 只看错误及以上：sudo journalctl -p3 或 sudo journalctl -perr
• 包含警告和更严重项：sudo journalctl -p4 或 sudo journalctl -pwarning
• 结合服务名缩小范围：sudo journalctl -u nginx.service -p3
• 限制在本次启动内：sudo journalctl -b -p3

为什么优先级比时间更值得先看

大量日志里，info 和 debug 级别占绝大多数，但真正导致异常的往往藏在少数 err 或 warning 中。比如某次 SSH 登录失败，-p3 能立刻定位到认证拒绝记录；而翻几十页默认日志可能漏掉关键行。优先级过滤不是跳过细节，而是把注意力锚定在信号最强的位置。

注意持久化与实际可见性的关系

debug 级别日志默认不保存，除非手动开启 journald 的 Storage=persistent 并设置 SystemMaxLevelDebug=yes；同样，很多服务默认只输出到 notice 或 info 级别。所以看不到 debug 日志，未必是没发生，可能是配置未启用或服务本身未打点。