崩溃后第一眼应看dmesg -T，因其输出带时间戳的内核环缓冲区内容，完整记录崩溃前几秒的硬件报错、驱动异常、OOM killer日志等关键线索，且避免Unix时间戳干扰判断。
系统崩溃后，dmesg 和 /var/log/kern.log 是最直接、最常更新的线索来源；但若内核已 panic 重启，这些日志可能被覆盖——必须优先查 /var/crash 下的完整转储，否则只能看到“重启后残留”的碎片信息。
崩溃后第一眼该看哪个文件
别急着翻 /var/log/messages 或 journalctl，它们记录的是服务级日志，对内核级崩溃往往滞后或缺失关键帧。真正反映“最后一刻”的是：
-
dmesg -T：输出带时间戳的内核环缓冲区内容，崩溃前几秒的硬件报错、驱动异常、OOM killer 日志全在这里。注意加-T避免 Unix 时间戳干扰判断 -
/var/log/kern.log：比dmesg更持久，尤其在 systemd 环境下会持续追加，适合查重启前未刷入内存的日志 -
journalctl -b -1：查上一次启动（即崩溃发生那次）的全部日志，比-b（当前 boot）更准。配合--since "2 hours ago"可框定时间窗
为什么 journalctl -p 3 -b 常常找不到 panic
这个命令只过滤优先级 ≥3（error）的日志，但 Kernel panic 的关键行如 Kernel panic - not syncing 实际是以 emerg（priority 0）发出的，-p 3 会漏掉它。正确做法是：
linux-performance-analyzer
下载
Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。
- 用
journalctl -b -1 | grep -i "panic\|oops\|die\|fatal"直接关键词扫 - 或用
journalctl -b -1 -o short-iso --no-pager | tail -n 100查最后百行原始输出，避免分页截断 - 某些发行版（如 RHEL 8+）默认不把 kernel log 写进 journal，此时
dmesg是唯一可靠入口
查不到日志？先确认 kdump 是否真在工作
很多管理员以为开了 kdump 就万事大吉，结果发现 /var/crash 是空的——说明崩溃根本没被捕获。三步快速验证：
- 运行
grep crashkernel /proc/cmdline，必须有类似crashkernel=256M@16M输出，否则内核没预留内存，dump 必失败 - 运行
systemctl is-active kdump，返回active才算服务真正 running；failed或inactive都不行 - 检查
/var/crash目录权限和磁盘空间：ls -ld /var/crash应为drwxr-xr-x，且df -h /var/crash剩余空间 ≥2GB（小内存机器可低至 1GB，但低于 512MB 极易 dump 截断）
有了 vmcore 却解析失败？重点盯 vmlinux 路径
crash 工具报错 cannot find vmlinux 或 version mismatch 是高频问题。不是版本装错，而是路径没对：
- 不要硬写
/usr/lib/debug/boot/vmlinux-$(uname -r)—— Ubuntu/Debian 的 debuginfo 包安装后，vmlinux 实际在/usr/lib/debug/lib/modules/$(uname -r)/vmlinux - RHEL/CentOS 8+ 使用
debuginfo-install kernel-core-$(uname -r)，vmlinux 在/usr/lib/debug/lib/modules/$(uname -r)/vmlinux，但需确认该路径存在且非空 - 用
find /usr/lib/debug -name vmlinux -type f 2>/dev/null | head -n1获取真实路径，再传给crash，比猜路径可靠十倍
真正卡住的地方往往不是工具不会用，而是崩溃发生时 kdump 没生效，或者 vmlinux 被装在了意想不到的子目录里——这两个点不人工确认，后面所有分析都是空中楼阁。
