必须先确认kdump是否启用且vmcore已生成，再用crash工具配合匹配的vmlinux符号文件解析；/var/crash/常为空，dmesg和/var/log/kern.log才是崩溃第一手材料。
Linux 故障转储日志不是“查看”出来的，而是要先确认有没有生成、存哪、用什么工具读 —— 大部分情况下，/var/crash/ 是空的，dmesg 和 /var/log/kern.log 才是真正记录崩溃现场的第一手材料。
怎么判断系统是否生成了真正的故障转储（vmcore）
Linux 的“故障转储”分两类：内核崩溃时的 vmcore（需提前配 kdump），和进程级的 core 文件（由 ulimit -c 控制）。两者都**不会自动写进 /var/log/**，也不被 journalctl 管理。
- 检查 kdump 是否启用：
systemctl is-active kdump—— 若返回inactive，说明没配，不可能有vmcore - 查
/var/crash/目录是否存在有效文件：ls -l /var/crash/—— 多数系统该目录为空或只含apport报告（Ubuntu），非内核转储 - 确认进程 core 文件是否被禁用：
ulimit -c—— 若输出0，表示应用崩溃也不会生成core - 真正能反映崩溃原因的，其实是
dmesg -T输出里最后几条 —— 特别是带Kernel panic、Oops、BUG:或Hardware error的行
为什么 journalctl 查不到内核崩溃细节
journalctl 记录的是 systemd 启动后才接管的日志，而内核崩溃发生在早期阶段，journald 进程早已终止。所以：
linux-performance-analyzer
下载
Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。
-
journalctl -b -1（上一次启动）可能包含重启前的部分残留日志，但不完整 -
journalctl -k只是dmesg的包装，等价于dmesg -P，内容受限于内核环缓冲区大小（默认通常 16MB） - 真正可靠的崩溃上下文在
/var/log/kern.log（Debian/Ubuntu）或/var/log/dmesg（RHEL/CentOS）里 —— 它们是dmesg启动时快照的持久化副本 - 如果
/var/log/kern.log没内容，说明 rsyslog/syslog-ng 没配置抓取 kernel facility，得检查/etc/rsyslog.conf是否有kern.*规则
怎么读 vmcore（如果你真有）
只有启用 kdump 并成功触发内核崩溃后，才会在 /var/crash/ 下生成 vmcore（通常是 /var/crash/vmcore 或 /var/crash/<timestamp>/vmcore</timestamp>）。读它不能靠文本命令：
- 必须用
crash工具：crash /var/crash/vmcore /usr/lib/debug/boot/vmlinux-$(uname -r) -
vmlinux-$(uname -r)是调试符号文件，CentOS/RHEL 需装kernel-debuginfo包，Ubuntu 需装linux-image-$(uname -r)-dbgsym - WinDbg 虽支持 Linux
vmcore，但仅限 ZLIB 压缩格式，LZO/Snappy 均不识别 —— 很多生产环境 kdump 默认用 LZO，直接打不开 -
crash里最常用命令：bt（看崩溃时调用栈）、log（输出内核 log buffer）、ps（查崩溃前进程状态）
日常排查别绕远路：优先看这三处
95% 的“疑似崩溃”问题，根本不需要碰 vmcore。直接盯住以下三个地方，效率最高：
-
dmesg -T | tail -30—— 时间戳可读，看最后 30 行硬件/驱动/OOM 异常 -
grep -i "panic\|oops\|kill process" /var/log/kern.log—— Debian/Ubuntu；RHEL/CentOS 改用/var/log/dmesg -
journalctl --since "2 hours ago" -p err | grep -E "(kernel|systemd|OOM)"—— 补充 systemd 层面的服务异常联动
真正难的不是“怎么读 vmcore”，而是判断“要不要读”——大多数时候，dmesg 和 kern.log 已经告诉你答案了，只是你跳过去翻 /var/log/messages 了。
