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 日志，未必是没发生，可能是配置未启用或服务本身未打点。
