精确还原事故现场需用journalctl以ISO时间戳锚定时间范围，结合boot ID、服务名、日志级别和关键词多维过滤，并导出JSON或带毫秒精度的文本用于交叉分析。
要根据时间精确还原事故现场，关键不是“翻日志”，而是用 journalctl 把时间锚点钉死，再叠加服务、级别、关键词等维度交叉锁定。时间不准，整个复盘就偏了。
用可靠时间戳替代模糊表达
别依赖 today 或 1 hour ago 这类相对表达——它们依赖系统时钟精度和 NTP 同步状态，一旦延迟或漂移，前几分钟的关键日志可能直接被漏掉。
- 部署或操作前，先记录精确起始时间：
start_ts=$(date -Iseconds) - 事故后，用完整 ISO 时间范围查询：
journalctl --since="2026-06-11 03:45:22" --until="2026-06-11 03:47:18" - 若需快速换算，
date -d "2026-06-11 03:45:22" +%s.%N转为纳秒级时间戳，便于和监控指标对齐
按启动会话（boot）隔离事故上下文
系统重启会清空部分内存日志，但 journalctl 保留各次 boot 的独立日志流。事故若发生在某次重启后，直接按 boot ID 查，比全量时间筛选更干净。
- 列出所有启动记录：
journalctl --list-boots，当前 boot 是0，上一次是-1 - 查上一次启动中所有 error 级日志：
journalctl -b -1 -p err - 结合服务与 boot：比如查上次启动中 sshd 的失败记录：
journalctl -b -1 -u sshd.service | grep -i "failed\|timeout"
组合过滤，避免信息过载
单靠时间范围仍可能返回成千上万行日志。必须叠加至少一个业务维度，才能聚焦根因。
- 指定服务 + 时间 + 错误级别：
journalctl -u nginx.service --since="2026-06-11 03:46:00" -p err - 加关键词快速定位崩溃线索：
journalctl -u myapp.service -p 3 --grep="segfault\|OOM\|timeout" --since="2026-06-11 03:45:00" - 必要时关联内核事件：
journalctl -k --since="2026-06-11 03:45:00" | grep -i "out of memory\|page allocation failure"
导出结构化日志用于后续分析
现场排查只是第一步，留证和交叉验证才是复盘核心。导出时优先选可解析格式，别只用默认文本。
- 导出带毫秒精度、易读时间的文本：
journalctl -u app.service --since="2026-06-11 03:45:00" -o short-iso > incident.log - 导出 JSON 格式，方便用 jq 提取字段：
journalctl -u app.service -o json --since="2026-06-11 03:45:00" | jq '.MESSAGE, .CODE, .SIGNAL' > debug.json - 强制不翻页、直接输出：
journalctl --no-pager，避免分页器截断内容
