线上 Node.js 应用故障往往也伴随着进程的 Crash，借助于一些守护进程的自检重启拉起，我们的服务依旧在运行，但是我们不应该去忽略这些意外的 Crash —— 当流量增大或者造成服务器的问题用户访问被别有用心之人抓住时，我们集群就变得岌岌可危了。
绝大部分情况下，会造成 Node.js 应用 Crash 掉的错误日志往往并不会记录到我们的错误日志文件中，幸运的是，服务器内核提供了一项机制帮助我们在应用 Crash 时自动地生成核心转储（Core dump）文件，让开发者可以在事后进行分析还原案发现场。
核心转储（Core dump）实际上是我们的应用意外崩溃终止时，计算机自动记录下进程 Crash 掉那一刻的内存分配信息、Program counter 以及堆栈指针等关键信息来生成核心转储文件，因此获取到核心转储文件后，我们可以通过 MDB、GDB、LLDB 等工具即可实现解析诊断实际进程的 Crash 原因。
使用 ulimit -c unlimited 打开内核限制，并且考虑到默认运行模式下，Node.js 对 JS 造成的 Crash 是不会触发核心转储动作的，因此我们可以在 Node 应用启动时加上参数 --abort-on-uncaught-exception 来对出现未捕获的异常时也能让内核触发自动的核心转储动作。
手动调用 gcore <pid> （可能需要 sudo 权限）的方式来手动生成，因为此时 Node.js 应用依旧在运行中，所以实际上这种方式一般用于 「活体检验」，用于 Node.js 进程假死状态 下的问题定位。
这里需要注意的是，以上的生成核心转储的操作都 并没有那么安全务必记得对服务器磁盘进行监控和告警**。
获取到 Node.js 应用生成的核心转储文件后，我们可以借助于 Node.js 性能平台 提供的在线 Core dump 文件分析功能进行分析定位进程 Crash 的原因了，具体用法会在本书第二部分进行说明。
核心转储的深入分析能够帮助我们解决 Node.js 应用的绝大部分底层故障，因为其可以还原出问题 JavaScript 代码和引发问题的参数，功能非常地强大。