journalctl不是日志“阅读器”，而是故障“定位器”，关键在于用时间、服务、级别三个维度交叉切片，几秒内从海量记录中揪出问题源头：通过-b绑定启动会话精准锁定故障周期，-u聚焦服务单元避免混杂，-p按优先级快速收窄线索，并可联动coredumpctl回溯崩溃根因。
journalctl 不是日志“阅读器”，而是故障“定位器”——关键在用时间、服务、级别三个维度交叉切片，几秒内从海量记录中揪出问题源头。
按启动会话精准锁定故障周期
系统重启后问题重现？别翻全量日志。用 -b 参数绑定具体启动上下文：
- 当前启动日志：journalctl -b（最常用，排除历史干扰）
- 上一次启动日志：journalctl -b -1（对比差异，查“重启后消失”的报错）
- 指定某次启动：journalctl --list-boots 先看编号，再 journalctl -b -2 查更早会话
- 验证日志是否持久化：运行 journalctl --disk-usage，非零值才说明 /var/log/journal/ 已启用，-b 结果才可信
聚焦服务单元，避免日志混杂
一个服务器跑十几个服务，混看等于盲人摸象。-u 必须带 .service 后缀，且支持多服务并查：
- 只看 nginx 启动全过程：journalctl -u nginx.service
- 实时盯住 Web 层与数据库层：journalctl -f -u nginx.service -u mysql.service
- 确认服务是否曾失败：journalctl -u docker.service --since "2 hours ago" | grep -i "failed\|start.*error"
- 注意：systemd 日志中内核消息需用 -k 或 -u systemd-kernel.service，不是普通 -u
用优先级 + 时间窗口快速收窄线索
错误常被 info 日志淹没。-p 参数直接过滤语义层级，再叠加时间范围，效率倍增：
- 只显示 error 及以上（err/crit/alert/emerg）：journalctl -p 3
- 连 warning 一起纳入（如配置弃用、连接超时）：journalctl -p 4
- 组合实战：查 php-fpm 近半小时的错误：journalctl -u php-fpm.service -p 3 --since "30 min ago"
- 高亮关键词分页看：journalctl -u apache2.service --no-pager | grep --color -E '500|timeout|refused' | less -R
结合 coredump 定位程序崩溃根因
看到 “Core dumped” 不是终点，而是起点。journalctl 和 coredumpctl 需联动使用：
- 先筛崩溃线索：journalctl | grep -E "(core.*dump|segfault|signal.*11)" | tail -20，记下日志里的 _PID=xxxx
- 查对应 core 是否存档：coredumpctl list myapp（或用 PID：coredumpctl info --pid 5678）
- 自动调试崩溃现场：coredumpctl debug myapp，进 gdb 后第一件事执行 bt 看调用栈顶
- 回溯日志上下文：用 coredumpctl info 中的时间戳，向前查 5 分钟日志：journalctl --since "2026-07-06 19:20:00" --until "2026-07-06 19:25:00" -o short-precise
