概述

當我們的應用意外崩潰終止時，計算機會自動記錄下進程 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 可執行文件啟動的進程生成的，如果這兩者沒有一一對應，分析結果往往是無效信息。