几周前，我在香港数据中心部署的一台关键业务节点（物理裸金属）突然在凌晨重启。Zabbix 监控记录了一个瞬时的“Agent lost”告警，几分钟后节点恢复上线，却没有留下任何日志。系统日志（/var/log/messages）无异常，应用日志也没有 crash 信息，这意味着服务器可能经历了一次内核崩溃或硬件异常，但我毫无证据。为了避免将来再陷入这种“盲盒式排查”，我决定在生产环境中部署 kdump + crash 栈，实现内核级崩溃后的自动 dump 与分析。本文完整记录了我在香港服务器上实践部署 kdumptool 采集 crash dump，以及后续用 crash 工具进行故障分析的过程。
一、部署目标与环境说明
目标
- 内核发生 panic、oops、NMI 等硬崩溃时自动触发 kdump 并生成 vmcore。
- 将 vmcore 保存至独立分区，确保重启后不丢失。
- 结合 crash 工具分析 dump，定位崩溃函数、调用栈、CPU 状态等。
环境参数
- 物理机系统版本：CentOS 7.9 / Kernel 3.10.0-1160
- 系统盘：NVMe 固态盘，单独划分 /var/crash 分区用于保存 dump
- 服务器位置：香港沙田自建数据房，带外支持 IPMI 控制台
二、kdump 安装与配置过程
1. 安装必要组件
yum install -y kexec-tools crash
kexec-tools 提供 kdump 功能，crash 是 dump 分析工具。
2. 检查 CPU 支持 kdump（x86_64 一般支持）
grep crashkernel /proc/cmdline
如果当前未启用 crashkernel，需修改 grub 配置。
3. 设置 crashkernel 内存保留
编辑 /etc/default/grub：
GRUB_CMDLINE_LINUX="crashkernel=512M rhgb quiet"
crashkernel 一般设为 256M～512M，物理内存越大越需要多分。
更新 grub 配置：
grub2-mkconfig -o /boot/grub2/grub.cfg
然后重启系统生效：
reboot
重启后验证 crashkernel 是否生效：
dmesg | grep -i crash
应输出如：
Reserving 512MB of memory at 0x88000000 for crashkernel
三、配置 kdump 保存策略
1. 编辑 /etc/kdump.conf：
核心配置如下：
path /var/crash
core_collector makedumpfile -c --message-level 1 -d 31
default shell
makedumpfile 会压缩 vmcore，减小空间占用。
若目标服务器无多余磁盘，可改为 ssh 或 nfs 存储 vmcore 到异地。
2. 确保 /var/crash 独立挂载，预留足够空间：
mkdir -p /var/crash
mount /dev/nvme0n1p3 /var/crash # 示例挂载
最少保留 5G 空间，建议定期清理旧的 vmcore。
3. 启用并测试 kdump 服务
systemctl enable kdump
systemctl start kdump
systemctl status kdump
四、模拟 crash 测试验证
非生产环境可用以下命令模拟触发 panic：
echo c > /proc/sysrq-trigger
触发后系统会重启，并在 /var/crash/ 生成以时间戳命名的目录，内含 vmcore 与 system log。
五、使用 crash 工具分析 vmcore
1. 安装匹配版本的调试内核符号
yum --enablerepo=debuginfo install -y kernel-debuginfo
注意：必须与生成 vmcore 时的内核完全一致。
2. 启动 crash 分析：
crash /usr/lib/debug/lib/modules/$(uname -r)/vmlinux /var/crash/2025-07-08-10\:00/vmcore
启动后进入交互界面，如：
crash>
常用命令包括：
查看内核 panic 原因：
crash> crash
查看内核日志：
crash> log
分析崩溃时的进程堆栈：
crash> bt
查看当前 CPU、任务状态：
crash> ps
查看指定进程内存映射：
crash> vm PID
分析 slab 泄露/内存碎片：
crash> kmem -s
六、生产中的实战策略
1. 多节点分布部署
在香港核心服务器群（包括 API 网关节点、Redis 缓存节点、PXC 数据库节点）中，我将上述方案标准化为 Ansible role，批量部署：
- hosts: hk_production
roles:
- kdump_enable
每个节点都独立保留 /var/crash 分区，重启时自动归档到本地，随后由 Prometheus 触发告警收集日志。
2. 搭配 IPMI Console 自动拉取 vmcore
为避免 crash 后手动登录，我配合 IPMI 控制台将重启时间点截图归档，并联动自动拉取 vmcore 到日志服务器：
scp root@crashed-node:/var/crash/* /mnt/log/crashdump/
3. 安全策略
关闭非 root 用户读取 /var/crash 权限
启用 SELinux 审计 kdump 写入行为
通过在香港生产节点部署 kdump 和 crash，我终于可以在系统突发宕机后第一时间获取 vmcore，并快速定位内核级别的错误根因——不论是驱动 bug、软 RAID 异常、还是硬件指令异常。相比传统依赖 /var/log/messages 排查的“盲猜”，kdump 带来了极大的可观测性提升。
这种方案特别适用于高价值节点的保障运维，包括数据库、转码、容器宿主机等关键系统，一旦 panic，就能在几分钟内复盘其“死因”，避免事故扩大。后续我也计划将其与 Zabbix 自动联动报警、并集成 crash 分析结果到邮件系统，形成更完整的运维闭环。
如需进一步集成到 CI/CD 或支持 RHEL9、Ubuntu 22 等系统，可基于此方案延伸定制。对于使用香港裸金属服务器的企业来说，这是一套强有力的“自愈”式问题诊断机制。
