Coredump 分析能力

概述

当我们的应用意外崩溃终止时，计算机会自动记录下进程 crash 掉那一刻的内存分配信息、program counter 以及堆栈指针等关键信息来生成 Coredump 文件，因此获取到 Coredump 文件后，我们通过 mdb、gdb、lldb 等工具即可实现解析诊断实际进程的 crash 原因。

换言之，依赖 Coredump 文件，我们可以更好地去还原应用故障现场来定位问题。因此 Node.js 性能平台提供了针对服务器上 Node.js 应用生成的 Coredump 文件的 文件生成告警、自动保存、一键转储 (commandx >= v1.5.2) 和 智能化分析 的功能；与此同时，也支持开发者手动上传 Coredump 文件来进行分析。

文件生成告警

由于用户开启 ulimit -c unlimited 限制后，Node.js 进程 crash 时会自动生成一份 Coredump 文件，此时用户是无感知的，因此我们增加了对异常生成 Coredump 文件的告警支持。

进入您的应用 报警 页，进行如下设置后即可添加 Coredump 文件告警：

需要注意的是，类型必须选择 coredump，阈值表达式则填写 @coredumps > 0，其余选项根据您的需要进行选择即可，最后点击 添加报警项 即可。

自动保存

服务器 Node.js 应用生成的 Coredump 文件路径会被 agenthub 自动上报并保存记录，我们默认会扫描 Node.js 应用的 pwd 目录（应用工作目录），您也可以通过给 agenthub 的启动配置文件加上 coredir 的配置项来自定义需要扫描 Coredump 文件的目录，如下面的例子：

{
 "appid": "xxx",
 "secret": "xxxxxx",
 "coredir": ["/home/alinode/test"]
}

coredir 对应的值是一个数组，因此您可以配置多个目录。上面例子中配置完成后启动 agenthub，则它除了会扫描 Node.js 应用的 pwd 目录外还会去扫描 /home/alinode/test 目录下的 core 文件。

想要查看自动上报的记录，您可以进入 Node.js 性能平台应用页，然后将鼠标悬浮于应用页面左侧边栏的 文件 按钮上，如下图所示：

接着选择 Coredump 文件，即可看到 Coredump 文件记录：

注意：自动上报只会上报新生成的 Coredump 文件，历史文件不会上报；并且所有未转储的记录只会保留一周。

一键转储

如果您想对上述的 Coredump 文件进行分析，首先需要将服务器上的文件转出至云端，因为分析需要传入 node 可执行文件，所以这里首先需要填写下生成这份 Coredump 文件的 Node.js 应用被启动时 runtime 的版本。

注意：转储功能需要您的 agenthub/egg-alinode 依赖的 commandx 版本 >= v1.5.2，否则会转储失败

设置 runtime 版本

点击 设置 runtime 版本 进行设置，如下图所示：

runtime 的版本设置格式为 alinode-vA.B.C 或者 node-vA.B.C，比如：alinode-v3.11.5，如下图所示：

点击保存即可，请务必确保设置的 runtime 版本和真实启动应用的版本是一致的。

转储 Coredump 文件

设置完 runtime 版本后，点击 转储 按钮即可将服务器上对应的 Coredump 文件转储至云端，如下图所示：

智能分析

Coredump 文件转储成功后，点击 分析 按钮即可进行智能化分析，更多详细内容可以参考：Node 案发现场揭秘 —— Coredump 还原线上异常

手动上传

除了服务器上生成的 Coredump 文件外，我们也可以选择手动上传 Coredump 文件进行分析，点击 上传文件 按钮：

然后在弹出框中按照提示从本地目录下选中对应的 Coredump 文件和 node 可执行文件，点击 提交 按钮即可传上云端：

需要注意的是，请将 Coredump 文件以 .core 结尾重命名，Node 可执行文件以 .node 结尾重命名，推荐的命名方式为 <os info>-<alinode/node>-<version>.node，方便以后回顾，比如 centos7-alinode-v4.2.2.node 这种。最后 Coredump 文件和 node 可执行文件之间必须是 一一对应 的关系。这里一一对应指的是：这份 Coredump 文件必须是由这个 Node 可执行文件启动的进程生成的，如果这两者没有一一对应，分析结果往往是无效信息。