文件这意味着开发者还得额外茬线上项目中设置好  和  这样的工具，并且通过额外实现的服务来能够去对线上运行的项目进行实时的状态导出

加上实际上预备章中除了 CPU/Memory 嘚问题，我们还会遇到一些需要分析错误日志、磁盘和核心转储文件等才能定位问题的状况因此在这些场景下，仅仅靠 Chrome devtools 显然会有一些力鈈从心正是为了解决广大 Node.js 开发者的这些痛点，我们在这里推荐大家在使用 即原来的 AliNode，它已经在阿里云邮箱个人版巴巴集团内部承载了幾乎所有的 Node.js 应用线上运行监控和问题排查因此大家可以放心在生产环境部署使用。

本节将从  的设计架构、核心能力以及最佳实践等角度帮助开发者更好地使用这一工具来解决前面提到的异常指标分析和线上 Node.js 应用故障定位。

本书首发在 Github仓库地址：，云栖社区会同步更新

具体的部署步骤可以查看官方文档：。借助于 Node.js 性能平台的整套解决方案我们可以很方便地实现预备章节中提到的绝大部分异常指标的告警分析的能力。在生产实践过程中实际上在笔者看来，Node.js 性能平台解决方案其实仅仅是提供了三个最核心却也是最有效的能力：

• 异常指標告警即预备节中一些异常指标出现异常时能通过短信/钉钉通知到开发者
• 在线分析结果和更好的 UI 展示，定制化解析应用导出状态和展示更符合国内开发者习惯

换言之，Node.js 性能平台作为一个产品本身功能也在不断迭代新增修改中但是以上的三个核心能力一定是第一优先级保障的，其它边边角角的功能则相对来说响应优先级没有那么高

实际上我们也理解作为使用平台的开发者希望能在一个地方看到 Node.js 线上应鼡从底层到业务层的所有细节，然而我个人感觉不同的工具都有应该有其核心的能力输出很多时候不断做加法容易让产品本身定位模糊囮以及泛而不精，Node.js 性能平台实际上始终在致力于让原本线上黑盒的运行时状态能更加直观地反馈给开发者，让 Node.js 应用的开发者面对一些偏姠底层的线上疑难杂症能够不再无所适从

线上应用的告警实际上是一种自我发现问题的保护机制，如果没有告警能力那每次都会等到問题暴露到用户侧导致其反馈才能发现问题，这显然对用户体验非常的不友好

因此部署完成一个项目后，开发者首先需要去配置合适的告警而在我们的生产实践中，线上问题通过错误日志、Node.js 进程 CPU/Memory 的分析、核心转储（Core dump）的分析以及磁盘分析能够得出结论因此我们需要的基本的告警策略也是源自以上五个部分。幸运的是平台已经给我们预设好了这些告警大家只需要选择一下即可完整这里的告警配置，如丅图所示：

在  的告警页面上有 快速添加规则点开选中后会自动生成告警规则的阈值表达式模板和报警说明模板，我们可以按照项目实际監控需求进行修改比如想要对 Node.js 进程的堆内存进行监控，可以选中 Memory 预警 选项如下图所示：

此时点击 添加报警项 即完整了对进程堆内存的告警，并且将出现告警时需要点击 通知设置->添加到联系人列表 来添加的联系人加入此条规则如下图所示：

那么在例子中的这条默认的规則里，当我们的 Node.js 进程分配的堆内存超过堆上线的 80%（默认 64 位机器上堆上限是 1.4G）时会触发短信通知到配置绑定到此条规则的联系人

实际上快速添加规则列表中给大家提供的是最常见的一些预配置好的告警策略，如果这些尚不能满足你的需求更多定制化的自定义的服务告警策畧配置方法可以看官方文档 。并且除了短信告警也支持钉钉机器人推送告警消息到群，方便群发感知线上 Node.js 应用态势

II. 按照告警类型进行汾析

按照 I 节中配置完成合适的告警规则后，那么当收到告警短信时就可以按照策略类型进行对应的分析了本节将按照预备节中比较常见嘚五大类问题来逐一讲解。

这个是比较好处理的问题在快速添加的规则里实际上我们会在服务器的磁盘使用超过 85% 时进行告警，那么收到磁盘告警后可以连接到服务器，使用如下命令查看那个目录占用比较高：

 

 找到占比比较高的目录和文件后看看是否需要备份后删除来釋放出磁盘空间。

 

 
 

 收到特定的错误日志告警后只需要去对应的项目的  控制台找到问题 实例 去查看其 异常日志 即可，如下图所示：
 
 

 
 
 

 这里会按照错误类型进行规整大家可以结合展示的错误栈信息来进行对应的问题定位。注意这里的错误日志文件需要你在部署 Agenthub 的时候写入配置攵件详细可以参见文档  一节中的 详细配置 内容。

 

 
 

 终于到了前一节中借助  导出 CPU Profile 文件再使用 Chrome devtools 进行分析的异常类型了那么在  的整套解决方案丅，我们并不需要额外的去依赖类似 v8-profiler 这样的第三方库来实现进程状态的导出与此相对的，当我们收到 Node.js 应用进程的 CPU
 
 

 
 
 

 默认会给抓取的进程生荿 3 分钟的 CPU Profile 文件等到结束后生成的文件会显示在 文件 页面：
 
 

 
 
 

 此时点击 转储 即可上传到云端以供在线分析展示了，如下图所示：
 
 

 
 
 

 这里可以看箌有两个 分析 按钮其实第二个下标带有 (devtools) 的分析按钮实际上就是前一节中提到的 Chrome devtools 分析，这里不再重复讲解了如果有遗忘的同学可以再去囙顾下本大章前一节的内容。我们重点看下第一个 AliNode
 定制的分析点击第一个分析按钮后，可以在新页面看到如下所示内容：
 
 

 
 
 

 这里其实也是吙焰图但与 Chrome devtools 提供的火焰图不一样的地方在于，这里是将抓取的 3 分钟内的 JS 函数执行进行了聚合展示出来的火焰图在一些存在多次执行同┅个函数（可能每次执行非常短）的情况下，聚合后的火焰图可以很方便的帮助我们找到代码的执行瓶颈来进行对应的优化
 
 

 值得一提的昰，如果你使用的 AliNode runtime 版本在 v3.11.4 或者 v4.2.1 以上（包含这两个版本）的话当你的应用出现类死循环问题，比如由于异常的用户参数导致的正则回溯（即执行完这个正则要十几年类似于 Node.js
 进程发生了死循环）这类问题时，可以通过抓取 CPU Profile 文件来很方便地定位到问题代码详细信息有兴趣的哃学可以看下 。

 

 
 

 与 CPU 高的问题一样当我们收到 Node.js 应用进程的堆内存占据堆上限的比率超过我们设置的阈值时，我们也不需要类似  这样的第三方模块来导出堆快照进行分析我们还是在控制台对应的 实例 点击 堆快照 按钮即可生成对应 Node.js 进程的堆快照：
 
 

 
 
 

 生成的堆快照文件同样会显示茬 文件 列表页面，点击 转储 将堆快照上传至云端以供接下来的分析：
 
 

 
 
 

 与上面一样下标带有 (devtools) 的分析按钮还是前一节中提到的 Chrome devtools 分析，这里还昰着重解析下 AliNode 定制的第一个分析按钮点击后新页面如下图所示：
 
 

 
 
 

 首先解释下上面的总览栏目的内容信息：
 
 

• 文件大小： 堆快照文件本身的夶小
• Shallow Szie 总大小： 回顾下上一节中的内容，GC 根的 Retained Size 大小其实就是堆大小也等于堆上分配的所有对象的 Shallow Size 总大小，因此这里其实就是已使用的堆空間
• 对象边个数： 这个稍微抽象一些假如 Object A.b 指向另一个 Object B，我们则认为表示指向关系的 b 属性就是一条边
• GC Roots 个数： V8 引擎实现的堆分配其实并不是峩们之前为了帮助大家理解简化的只有一个 GC 根的情况，在实际的运行模型下堆空间内存在许多的 GC 根，这里是真实的 GC 根的个数

 

 这部分的信息旨在给大家一个概览部分信息需要深入解读堆快照才能彻底理解，如果你实在无法理解其中的几个概览指标信息其实也无伤大雅，洇为这并不影响我们定位问题代码
 
 

 简单了解了概览信息的含义后，接着我们来看对于定位 Node.js 应用代码段非常重要的信息第一个是默认展礻的 可疑点 信息，上图中的内容表示 @15249 这个对象占据了堆空间 97.41% 的内存那么它很可能就是一个泄漏对象，这里又存在两种可能：
 
 

• 此对象本身應该被释放但是却没有释放造成堆空间占用如此大
• 此对象的某些属性应该被释放但是却没有释放，造成表象是此对象占据大量的堆空间

 

 偠判断是哪一种情况以及追踪到对应的代码段，我们需要点击图中的 簇视图 链接进行进一步观察：
 
 

 
 
 

 这里继续解释下什么是簇视图簇视圖实际上是支配树的一个别名，也就是这个视图下我们看到的正是前面一节中提到的从可疑泄漏对象出发的支配树视图它的好处是，在這个视图下父节点的 Retained Size 可以直接由其子节点的 Retained Size 累加后再加上父节点自身的 Shallow Size
 得到，换言之在这个视图下我们层层展开即可以看到可疑泄漏對象的内存究竟被哪些子节点占用了。
 
 

 并且结合前一节的支配树描述我们可以知道支配树下的父子节点关系，并不一定是真正的堆上空間内的对象父子关系但是对于那些支配树下父子关系在真正的堆空间内也存在父子节点关系的簇节点，我们将真正的 边 也用浅紫色标识絀来这部分的 边 信息对于我们映射到真正的代码段非常有帮助。在这个简单的例子中我们可以很清晰的看到可疑泄漏对象
 @15249 实际上是下屬的 test-alinode.js 中存在一个 array 变量，其中存储了四个 45.78 兆的数组导致的问题这样就找到了问题代码可以进行后续优化。
 
 

 而在实际生产环境的堆快照分析丅很多情况下簇视图下的父子关系在真实的堆空间中并不存在，那么就不会有这些紫色的边信息展示这时候我们想要知道可疑泄漏对潒如何通过 JavaScript 生成的对象间引用关系引用到后面真正占据掉堆空间的对象（比如上图中的 40 多兆的 Array 对象），我们可以点击 可疑节点自身的地址鏈接 ：
 
 

 
 
 

 这样就进入到以此对象为起点的堆空间内真正的对象引用关系视图 Search 视图：
 
 

 
 
 

 这个视图因为反映的是堆空间内各个 Heap Object 之间真正的引用连接關系因此父对象的 Retained Size 并不能直接由子节点的 Retained Size 累加获取，如上图红框内的内容显然这里的三个子节点 Retained Size 累加已经超过 100%，这也是 Search 视图和簇视图佷大的不同点借助于 Search
 视图，我们可以根据其内反映出来的对象和边之间的关系来定位可疑泄漏对象具体是在我们的 JavaScript 代码中的哪一部分生荿
 
 

 其实看到这边，一些读者应该意识到了这里的 Search 视图实际上对应的就是前一节中提到的 Chrome devtools 的 Containment 视图只不过这里的起始点是我们选中的对象夲身罢了。
 
 

 最后就是需要提一下 Retainers 视图它和前一节中提到的 Chrome devtools 中解析堆快照展示结果里面的 Retainers 含义是一致的，它表示对象的父引用关系链我們可以来看下：
 
 

 
 
 

 
 

 代码中的生成位置，而 簇视图 下我们又可以比较方便的知道堆空间被哪些对象占据掉了那么综合这两部分的信息，我们僦可以实现对线上内存泄漏的问题进行分析和代码定位了

 

 
 

 最后就是收到服务器生成核心转储文件（Core dump 文件）的告警了，这表示我们的进程巳经出现了预期之外的 Crash如果你的 Agenthub 配置正常的话，在 文件 -> Coredump 文件 页面会自动将生成的核心转储文件信息展示出来：
 
 

 
 
 

 和之前的步骤类似我们想要看到服务端分析和结果展示，首先需要将服务器上生成的核心转储文件转储到云端但是与之前的 CPU Profile 和堆快照的转储不一样的地方在于，核心转储文件的分析需要我们提供对应 Node.js 进程的启动执行文件即 AliNode runtime 文件，这里简化处理为只需要设置 Runtime 版本即可：
 
 

 
 
 

 版本版本填写完成后，峩们就可以点击 转储 按钮进行文件转储到云端的操作了：
 
 

 
 
 

 显然对于核心转储文件来说Chrome devtools 是没有提供解析功能的，所以这里只有一个 AliNode 定制的汾析按钮点击这个 分析 按钮，即可以看到结果：
 
 

 
 
 

 这里第一栏的概览信息看文字描述就能理解其含义所以这里就不再多做解释了，我们來看下比较重要的默认视图 BackTrace 信息视图此视图下展示的实际上是 Node.js 应用在 Crash 时刻的线程信息，许多开发者认为 Node.js 是单线程的运行模型其实这句話也不是完全错误，更准确的说法是 单主
 JavaScript 工作线程因为实际上 Node.js 还会开启一些后台线程来处理诸如 GC 里的部分任务。
 
 

 绝大部分的情况下应鼡的 Crash 都是由 JavaScript 工作线程引发的，因此我们需要关注的也仅仅是这个线程这里显然 BackTrace 信息视图中将 JavaScript 工作线程做了标红和置顶处理，展开后可以看到 Node.js 应用 Crash 那一刻的错误堆栈信息：
 
 

 
 
 

 因为就算在 JavaScript 的工作线程中也会存在 Native C/C++ 代码的穿透，但是在问题排查中我们往往只需要去看同样标红的 JavaScript 栈信息即可像在这个简单的例子中，显然 Crash 是因为视图去启动一个不存在的 JS 文件导致的
 
 

 值得一提的是，核心转储文件的分析功能非常的强夶因为在预备节中我们提到其生成的途径除了 Node.js 应用 Crash 的时候由系统内核控制输出外，还可以由 gcore 这样的命令手动强制输出而本小节我们又看到核心转储文件的分析实际上可以看到此刻的 JavaScript 栈信息以及其入参，结合这两点我们可以在线上出现 CPU
 Profile 一节中提到的类死循环问题时直接采用 gcore 生成核心转储文件，然后上传至平台云端进行分析这样不仅可以看到我们的 Node.js 应用是阻塞在哪一行的 JavaScript 代码，甚至引发阻塞的参数我们吔能完整获取到这对本地复现定位问题的帮助无疑是无比巨大的。
 
 

 

 本节其实给大家介绍了  的整套面向 Node.js 应用开发的监控、告警、分析和定位问题的解决方案的架构和最佳实践希望能让大家对平台的能力和如何更好地结合自身项目进行使用有一个整体的理解。
 
 

 限于篇幅最佳实践中的 CPU Profile、堆快照和核心转储文件的分析例子都非常的简单，这部分的内容也更多的是旨在帮助大家理解平台提供的工具如何使用以及其分析结果展示的指标含义那么本书的第三节中，我们会通过一些实际的生产遇到的案例问题借助于  提供的上述工具分析过程来帮助夶家更好的理解这部分信息，也希望大家在读完这些内容后能有所收获能对 Node.js 应用在生产中的使用更有信心。
 
 

 本文为云栖社区原创内容未经允许不得转载。
 

  钉钉是阿里云邮箱个人版巴巴集團专为企业打造的一个专业通讯、协同办公平台钉钉4.0全新界面，带来全新体验应用全面升级，搭配全新智能办公硬件让数千万企业提前进入到云和移动办公时代。

1.一键发起商务电话让团队内部沟通变得简单便捷，简易高效的电话会议体验支持2~9人同时加入。  

3.新颖的電话面板控制方式实时显示参会者在线状态和通话质量；  

4.快速发起会议，实时增加、删除成员控制静音，面板皆可实现  

5.高清电话会議语音，底层采用业界顶尖语音编解码引擎和运营商级语音线路  

1.钉钉发出的DING消息将会以免费电话OR免费短信OR应用内消息的方式通知到对方。  

2.无论接收手机有无安装钉钉APP是否开启网络流量，均可收到DING消息实现无障碍的信息必达。  

3.当接受人收到DING消息提醒电话时号码显示为發送方的电话号码，接收方接听电话听到发送方的语音信息后如果是文字信息，系统会将文字播报给收听方接收方即可直接进行语音囙复，发送方便可及时收到回复  

1.无论是一对一聊天，还是一对多的群消息钉钉让用户都能知道发出的消息对方是否阅读，哪些人已阅哪些人未读。  

2.用户发送信息后消息旁显示“n人未读”，尤其是在群里发布信息（钉钉支持1500人大群）点击“n人未读”可查看未读人和巳读人的详细列表，并能够对未读人发送DING消息 

钉钉推出了所有用户新建团队OR企业功能，任意一个企业、组织或者个人无论你是企业内嘚部门、企业内的兴趣团体、企业内的虚拟项目组等待，甚至是社团、班级及其他社会组织···你都可以快速创建你的团队并且享受大量免费权益。  

1.澡堂模式是基于消息分层理念的升级在普通聊天窗点击聊页面点击右上角的墨镜图标开启澡堂对话。  

2.在此模式下信息不能被复制，用户不用担心被录音姓名、头像都会被打马赛克。  

3.聊天内容在已读后30秒内消失不留痕迹。如同在澡堂一般只能“看在眼裏、烂在心里”，保证重要信息沟通隐私安全  

4.针对安全诉求更高的用户，钉钉可以在设置中开启隐藏澡堂对话功能让信息真正安全！  

1.仩传企业内部全体成员、同事的职务title、负责业务、联系方式等到钉钉后用户即可不存号码，就能找到同事、团队成员  

2.钉钉通讯录还与个囚通讯录打通，可同时添加公司同事和个人通讯录朋友方便发起各种聊天、群、多人电话。

企业群员是经过员工表格确定的保障安全。  

2.“认证用户”才能进入到“企业群”中该群只包含企业内通讯人，一旦出现人事变动离职员工会即时从整个通讯录和所有群组中退絀。  

3.企业群支持群公告发布发布后支持实时查看已读未读。  

1.多种方式考勤支持无网络信号打卡。  

2.日志智能报表实时掌握团队业务数據。  

3.审批支持自定义自建模版表单，满足个性需求  

1.与通讯结合的企业办公，高效快速完成审批通知，日志等办公必备应用  

2.结合钉釘的基础通信能力，将各种办公审批快速短信电话通知对方，消息必达  

钉钉中审批有着自己独到的功能，融合通讯移动办公随时随哋申请秒批，零等待和更强大的执行力  

2.公告内容只有企业群内部人员才可以看到，独有的“水印”功能保障信息安全  

3.和线下公告不同嘚是，除了文本内容以外线上公告还可以提供附件功能，文件可添加 

1.钉钉日志支持，不同的企业日志有不同的统一格式，方便员工填写  

2.日志支持，横屏手机即可自动汇总报表  

1.钉钉推出了管理模式，管理者“方寸之间尽在掌握”。  

2.进入管理日历之后企业人员的簽到、请假外出、日报提交等状态，将会一览无遗  

外勤签到，管理者可快速查看团队外出员工分布掌握员工外勤工作情况。  

1.钉钉认证企业可以在PC端管理后台设置自己的主页企业可上传自己企业的LOGO，简介业务，电话网址等信息；  

2.支持把企业对外的联系人显示出来，非本企业员工可以通过企业主页联系到企业相应人员  

与即时通讯高度融合的商务办公邮箱，把Email进化为C-Mail已读未读一目了然，沟通进度可縋踪可推动重要邮件不再错过。  

不仅仅能够投递到对方的邮箱中同时还会在对方的聊天窗口里有所提示。  

2.写邮件时候变得轻松支持選择聊天群组发送给全员，无需一一选人同时，添加附件也极其方便与C-Space无缝衔接，快捷选择、快捷查看企业文件、群文件、个人文件  

3.拥有邮件的已读未读功能，第一时间知道邮件是否送达  

4.邮件DING功能则可以将信息通过信息甚至电话直接送达到对方手中。  

自动在邮箱里置顶重要的邮件不会错过。  

2.钉钉拥有一键唤起电话会议功能当邮件已经不能解决问题时，只要点击电话按钮钉钉将会自动联系所有嘚邮件收件人，唤起电话会议  

1.与统一通讯打通的企业云盘体验，基于专业的阿里云邮箱个人版云服务  

2.除了满足可靠、稳定、安全等企業基础诉求之外，还针对工作中的文件场景进行了专门的设计  

4.C-Space打通了多端跨平台存储共享，不管是电脑上存储了手机取出，还是手机存储了电脑取出，再无限制  

5.针对离职员工甚至调职员工可能产生的信息泄露，钉钉提供了权限保护功能员工一旦离开了相应的权限，则会自动失去了文件的访问能力  

6.企业聊天文件自动存储到钉盘，在网页版还可以进行批量下载  

钉钉坚持为企业服务需要有一个开放嘚心态！  

用户采购的现成OA系统，还是自主开发的OA解决方案钉钉提供了解决方案：大型企业自有OA，可以与钉钉通讯打通

1、点击左下角创建，选择“发起聊天”选择好友进行聊天即可；  

2、点击左侧“联系人—关系—我的好友”，找到对应的联系人进行发消息；  

3、点击左側的“架构—关系—选择对应企业—选择对应的部门—点击对应人员“进行发消息；  

4、电脑客户端上通过搜索（左上角）联系人进行发消息。  

1、聊天窗口点击附件按钮，选择本地文件进行发送目前支持最大发送文件700M；  

2、聊天窗口，点击钉盘按钮选择钉盘内文件进行发送；  

3、可以通过拖拽本地文件到聊天窗口进行发送；  

电脑客户端可以与哪些人进行聊天?  

支持企业通讯录人员、钉钉好友；  

如何查看发送的消息接收方是否已读/未读？  

打开聊天窗口发送的信息会显示已读或未读的字样