journalctl -u 可快速定位容器服务崩溃指纹，需结合--since/--until锁定时间窗、-r -n抓最新异常、-p err过滤错误，并联动journalctl -k查oom、多unit对比依赖异常。
直接用 journalctl -u 查容器服务日志，本身不能“自动捕获崩溃上下文”，但配合合理参数组合，能快速定位微服务（如基于 systemd 管理的容器服务）崩溃前后的关键指纹——包括错误堆栈、OOM Killer 记录、依赖服务异常、启动失败原因等。核心不是单靠 -u，而是以它为锚点，叠加时间、级别、内核、反向排序等维度交叉验证。
明确服务单元名是前提
微服务若由 systemd 托管（例如用 systemd-run 启动、或封装为 .service 文件），其 unit 名必须准确。常见形式有：
-
myapp.service（标准命名） -
docker-myapp.service（Docker Compose 生成） -
containerd@myapp.service（containerd + systemd socket 激活） -
podman-myapp.service（Podman generate systemd 输出）
不确定时，先运行：systemctl list-units --type=service | grep -i myapp
避免因 unit 名错误导致查不到日志。
聚焦崩溃前后 5 分钟的关键时间窗口
服务崩溃往往伴随启动失败、被 OOM kill、或 panic 日志，这些通常集中在崩溃点附近。用 --since 和 --until 锁定窗口，比翻全量日志高效得多：
- 查最近一次崩溃：先用
systemctl status myapp.service看最后状态和时间戳，再套用：journalctl -u myapp.service --since "2026-05-19 09:45:00" --until "2026-05-19 09:55:00" -n 100 - 更通用写法（不依赖具体时间）：
journalctl -u myapp.service --since "5 minutes ago" -n 200 - 若已知崩溃大致时段（如运维告警时间），直接填入 ISO 格式时间，精度到秒更稳妥。
联动内核与系统级线索（关键指纹来源）
容器崩溃常非应用层单独导致，需同步检查底层信号：
- 查是否被 OOM Killer 终止：
journalctl -k --since "5 minutes ago" | grep -i "killed process"
注意匹配myapp进程名或 PID（可从systemctl status中获取） - 查同一时间点其他依赖服务是否异常：
journalctl -u nginx.service redis.service --since "5 minutes ago" -p err..crit
用-p err..crit只看错误及以上级别，避免信息过载 - 查 systemd 自身对服务的处置记录：
journalctl -u myapp.service --no-pager | grep -E "(failed|exited|killed|signal|timeout)"
这类关键词往往直指崩溃根因（如Start request repeated too quickly表示反复启动失败触发抑制）
用 -r -n 组合快速抓取最新异常现场
崩溃刚发生时，最新几条日志最有价值。默认 journalctl 从旧到新显示，容易漏掉末尾关键行：
- 立即查看该服务最新的 30 条，倒序排列（最新在最前）：
journalctl -u myapp.service -r -n 30 - 加上错误级别过滤，进一步提纯：
journalctl -u myapp.service -r -n 30 -p err - 若想实时盯住后续日志（比如重启后复现）：
journalctl -u myapp.service -f -p err
按Ctrl+C退出
不复杂但容易忽略：-u 是入口，真正还原崩溃上下文靠的是“时间锚定 + 级别过滤 + 跨单元关联”。只要 unit 名正确、时间窗合理、内外日志对照看，绝大多数容器服务崩溃的指纹（如内存溢出、端口冲突、配置加载失败、父进程被杀）都能在 1 分钟内定位清楚。
