在CentOS系统上配置kdump内核崩溃转储，核心就是做三件事：安装kdump相关软件包、修改GRUB引导参数为崩溃内核预留内存、编辑kdump配置文件指定转储路径和触发方式，最后重启生效并用命令验证。整个过程不复杂，但每个环节都有坑，比如内存预留不够导致捕获失败、转储目标路径没挂载导致写入报错、或者crashkernel参数设置不当导致系统启动异常。下面我把每一步拆开讲透，包括原理、操作、验证和常见故障排查。
一、kdump到底是什么、为什么要配
kdump是Linux内核自带的一个崩溃转储机制，基于kexec技术实现。当系统内核发生panic（内核崩溃）时，kdump会自动加载一个预先准备好的"捕获内核"（capture kernel），这个捕获内核在内存中独立运行，把崩溃时的内存镜像（vmcore）和寄存器状态写到磁盘或网络目标上。运维人员拿到这个vmcore文件后，可以用crash工具或gdb分析崩溃原因，定位是哪个驱动、哪个模块、哪行代码出了问题。
在生产环境中，服务器蓝屏、内核oops、硬件故障导致的随机崩溃并不罕见。没有kdump，你只能看到一条"kernel panic"的日志，根本无法深入分析。配好kdump，相当于给系统装了一个"黑匣子"，出事之后有据可查。CentOS 7和CentOS 8/Stream都原生支持kdump，配置方式略有差异但核心逻辑一致。
二、安装kdump相关软件包
首先确认系统是否已经安装了kdump相关组件。CentOS 7和CentOS 8的包名不完全一样，需要分别处理。
CentOS 7执行：
yum install kexec-tools kdump -y
CentOS 8 / Stream执行：
dnf install kexec-tools kdump -y
安装完成后，可以用以下命令确认服务状态：
systemctl status kdump
如果显示"inactive (dead)"是正常的，因为kdump服务只在系统启动时由systemd自动触发，不需要手动启动。重点是确认kexec-tools和kdump包都装上了，缺一个都不行。
三、配置GRUB引导参数预留崩溃内核内存
这是最关键的一步。kdump工作时需要在内存中额外保留一块区域给捕获内核使用，这块内存不能被正常内核占用。通过GRUB的crashkernel参数来指定。
编辑GRUB配置文件：
vi /etc/default/grub
找到GRUB_CMDLINE_LINUX这一行，在引号内添加crashkernel参数。根据你服务器的物理内存大小，推荐值如下：
内存4GB以下：crashkernel=128M
内存4GB到8GB：crashkernel=256M
内存8GB到16GB：crashkernel=512M
内存16GB以上：crashkernel=1G 或 crashkernel=auto
修改后的示例（假设8GB内存）：
GRUB_CMDLINE_LINUX="crashkernel=512M rhgb quiet"
注意：如果你的系统用的是UEFI引导，GRUB配置文件路径可能是/boot/efi/EFI/centos/grub.cfg，但通常修改/etc/default/grub后重新生成即可。CentOS 7执行：
grub2-mkconfig -o /boot/grub2/grub.cfg
CentOS 8 / Stream执行：
grub2-mkconfig -o /boot/grub2/grub.cfg
或者更简单的方式，CentOS 8可以直接用：
grubby --update-kernel=ALL --args="crashkernel=512M"
修改完成后重启系统，用以下命令确认crashkernel参数是否生效：
cat /proc/cmdline
如果输出中包含crashkernel=xxxM，说明配置成功。同时可以用：
kdump-config show
查看kdump自动检测到的内存信息。
四、编辑kdump配置文件指定转储目标
kdump的主配置文件是/etc/kdump.conf，这个文件决定了崩溃时vmcore往哪里写、怎么写、是否压缩、是否过滤等。
打开配置文件：
vi /etc/kdump.conf
以下是一个生产环境推荐的配置模板：
path /var/crash core_collector makedumpfile -l --message-level 1 -d 31 # 如果需要通过网络发送到远程服务器，取消下面注释并配置 # net 192.168.1.100 # net user root # net password yourpassword # 是否使用ssh传输（更安全） # net ssh root@192.168.1.100 # net sshkey /root/.ssh/id_rsa default shell
逐项解释：
path /var/crash —— 指定转储文件的存放目录，这个目录必须在系统启动时就存在并且有足够空间。建议单独挂载一个分区或者确保/var分区足够大。
core_collector makedumpfile -l --message-level 1 -d 31 —— 使用makedumpfile工具收集内存镜像。-l表示使用压缩（lzo压缩），-d 31表示排除用户空间页面和空闲页面，只保留内核相关的有价值数据，大幅减小文件体积。如果你需要完整的内存镜像做深度分析，把-d 31去掉即可。
net相关参数 —— 如果你希望把vmcore自动发送到远程NFS服务器或通过SSH推送到另一台机器，就配置net参数。生产环境强烈建议配置远程转储，防止本地磁盘故障导致转储文件丢失。
default shell —— 崩溃后自动进入shell模式，方便手动排查。如果设成reboot则崩溃后自动重启。
另外还有几个常用选项：
kdump_command /usr/bin/kdump —— 指定kdump命令路径，一般不用改。
kdump_post /usr/bin/kdump-post —— 崩溃转储完成后执行的脚本，可以用来发告警通知。
keep_old_dumps 5 —— 保留最近5次转储文件，避免磁盘被撑满。
五、确保转储目录存在且空间充足
这一步很多人忽略，结果kdump触发后报错"No space left on device"。需要提前创建目录并确保空间：
mkdir -p /var/crash chmod 755 /var/crash df -h /var/crash
建议/var/crash所在分区至少有物理内存大小1.5倍的可用空间。比如16GB内存的机器，/var/crash至少要有24GB可用空间。如果空间不够，可以挂载一个单独的大容量磁盘到这个路径。
六、启用kdump服务并验证
配置全部完成后，启用kdump服务：
systemctl enable kdump systemctl start kdump
然后用kdump自带的检测工具验证：
kdump-config show
这个命令会输出当前kdump的完整配置信息，包括crashkernel大小、转储路径、是否启用等。如果输出正常没有报错，说明配置基本没问题。
更严格的验证方式是手动触发一次测试（注意：这会导致系统重启！务必在维护窗口操作）：
echo c > /proc/sysrq-trigger
或者使用：
systemctl kdump-trigger
执行后系统会触发内核panic，kdump捕获内核启动，将vmcore写到指定路径。重启后检查：
ls -lh /var/crash/
如果看到类似vmcore-xxx.xxx的文件，说明kdump工作正常。文件大小通常是几百MB到几GB不等，取决于内存大小和压缩选项。
七、用crash工具分析vmcore文件
拿到vmcore文件后，需要安装crash工具来分析：
yum install crash kernel-debuginfo -y
然后执行：
crash /usr/lib/debug/lib/modules/$(uname -r)/vmlinux /var/crash/vmcore-xxx
进入crash交互界面后，常用命令有：
bt —— 查看崩溃时的调用栈 log —— 查看内核日志 ps —— 查看崩溃时的进程列表 mod -S —— 列出已加载的内核模块
通过bt命令看到的调用栈，你就能定位到具体是哪个函数、哪个驱动出了问题。这才是配kdump的最终目的。
八、常见故障排查
故障1：kdump服务启动失败，报"No memory reserved for crashkernel"。原因是crashkernel参数设置太大或者内存不足。解决：减小crashkernel值，或者检查/proc/iomem确认预留是否成功。
故障2：触发kdump后没有生成vmcore文件。检查/var/crash目录权限和空间，检查kdump.conf中path是否正确，检查makedumpfile是否安装。
故障3：系统启动时kdump占用内存导致正常内核可用内存减少。这是正常现象，crashkernel预留的内存不会被正常内核使用。如果你觉得影响业务，可以适当减小预留值，但不能低于128M。
故障4：CentOS 8上kdump配置后不生效。CentOS 8默认用的是dracut而不是传统initramfs，需要确保dracut模块包含kdump支持，执行：
dracut -f /boot/initramfs-$(uname -r).img $(uname -r)
故障5：远程转储失败。检查网络连通性、防火墙规则、NFS挂载权限或SSH密钥配置。建议先手动测试网络连通性再配kdump。
九、生产环境最佳实践建议
第一，一定要配远程转储。本地磁盘坏了你什么都拿不到，NFS或SSH远程推送是必须的。
第二，定期测试kdump是否正常。每个季度至少手动触发一次，验证整个链路是通的。很多人配完就不管了，真出事才发现kdump根本没工作。
第三，保留策略要合理。keep_old_dumps不要设太大，否则/var分区会被撑满影响系统运行。同时定期清理旧的vmcore文件。
第四，配合监控告警。写一个简单的kdump-post脚本，在转储完成后发送邮件或企业微信通知，让运维第一时间知道有机器崩了。
第五，如果你的服务器用的是大内存（64GB以上），crashkernel建议设auto让系统自动计算，或者参考Red Hat官方文档的推荐值，避免手动设置不合理。
总结一下，CentOS上配kdump并不难，难的是把每个细节都做到位。从GRUB参数到kdump.conf到目录空间到远程转储到定期验证，每一步都不能马虎。这套机制配好之后，你的服务器就有了一个可靠的"黑匣子"，内核崩溃不再是无头苍蝇式的排查，而是有据可依的精准定位。
