绍兴网站建设费用,怎么wordpress,php mysql网站开发实例,wordpress如和安装楔子
前一节中我们借助于 Chrome devtools 实现了对线上 Node.js 应用的 CPU/Memory 问题的排查定位#xff0c;但是在实际生产实践中#xff0c;大家会发现 Chrome devtools 更加偏向本地开发模式#xff0c;因为显然 Chrome devtools 不会负责去生成分析问题所需要的 Dum…楔子
前一节中我们借助于 Chrome devtools 实现了对线上 Node.js 应用的 CPU/Memory 问题的排查定位但是在实际生产实践中大家会发现 Chrome devtools 更加偏向本地开发模式因为显然 Chrome devtools 不会负责去生成分析问题所需要的 Dump 文件这意味着开发者还得额外在线上项目中设置好 v8-profiler 和 heapdump 这样的工具并且通过额外实现的服务来能够去对线上运行的项目进行实时的状态导出。
加上实际上预备章中除了 CPU/Memory 的问题我们还会遇到一些需要分析错误日志、磁盘和核心转储文件等才能定位问题的状况因此在这些场景下仅仅靠 Chrome devtools 显然会有一些力不从心。正是为了解决广大 Node.js 开发者的这些痛点我们在这里推荐大家在使用 Node.js 性能平台即原来的 AliNode它已经在阿里巴巴集团内部承载了几乎所有的 Node.js 应用线上运行监控和问题排查因此大家可以放心在生产环境部署使用。 本节将从 Node.js 性能平台 的设计架构、核心能力以及最佳实践等角度帮助开发者更好地使用这一工具来解决前面提到的异常指标分析和线上 Node.js 应用故障定位。
本书首发在 Github仓库地址https://github.com/aliyun-node/Node.js-Troubleshooting-Guide云栖社区会同步更新。 架构
Node.js 性能平台其实简单的说由三部分组成云控制台 AliNode runtime Agenthub如下图所示 具体的部署步骤可以查看官方文档自助式部署 Runtime。借助于 Node.js 性能平台的整套解决方案我们可以很方便地实现预备章节中提到的绝大部分异常指标的告警分析的能力。在生产实践过程中实际上在笔者看来Node.js 性能平台解决方案其实仅仅是提供了三个最核心却也是最有效的能力
异常指标告警即预备节中一些异常指标出现异常时能通过短信/钉钉通知到开发者导出线上 Node.js 应用状态包括但不限于即前面 Chrome devtools 一节中提到的 CPU/Memory 状态导出在线分析结果和更好的 UI 展示定制化解析应用导出状态和展示更符合国内开发者习惯
换言之Node.js 性能平台作为一个产品本身功能也在不断迭代新增修改中但是以上的三个核心能力一定是第一优先级保障的其它边边角角的功能则相对来说响应优先级没有那么高。
实际上我们也理解作为使用平台的开发者希望能在一个地方看到 Node.js 线上应用从底层到业务层的所有细节然而我个人感觉不同的工具都有应该有其核心的能力输出很多时候不断做加法容易让产品本身定位模糊化以及泛而不精Node.js 性能平台实际上始终在致力于让原本线上黑盒的运行时状态能更加直观地反馈给开发者让 Node.js 应用的开发者面对一些偏向底层的线上疑难杂症能够不再无所适从。 最佳实践 I. 配置合适的告警
线上应用的告警实际上是一种自我发现问题的保护机制如果没有告警能力那每次都会等到问题暴露到用户侧导致其反馈才能发现问题这显然对用户体验非常的不友好。
因此部署完成一个项目后开发者首先需要去配置合适的告警而在我们的生产实践中线上问题通过错误日志、Node.js 进程 CPU/Memory 的分析、核心转储Core dump的分析以及磁盘分析能够得出结论因此我们需要的基本的告警策略也是源自以上五个部分。幸运的是平台已经给我们预设好了这些告警大家只需要选择一下即可完整这里的告警配置如下图所示 在 Node.js 性能平台 的告警页面上有 快速添加规则点开选中后会自动生成告警规则的阈值表达式模板和报警说明模板我们可以按照项目实际监控需求进行修改比如想要对 Node.js 进程的堆内存进行监控可以选中 Memory 预警 选项如下图所示 此时点击 添加报警项 即完整了对进程堆内存的告警并且将出现告警时需要点击 通知设置-添加到联系人列表 来添加的联系人加入此条规则如下图所示 那么在例子中的这条默认的规则里当我们的 Node.js 进程分配的堆内存超过堆上线的 80%默认 64 位机器上堆上限是 1.4G时会触发短信通知到配置绑定到此条规则的联系人。
实际上快速添加规则列表中给大家提供的是最常见的一些预配置好的告警策略如果这些尚不能满足你的需求更多定制化的自定义的服务告警策略配置方法可以看官方文档 报警设置。并且除了短信告警也支持钉钉机器人推送告警消息到群方便群发感知线上 Node.js 应用态势。 II. 按照告警类型进行分析
按照 I 节中配置完成合适的告警规则后那么当收到告警短信时就可以按照策略类型进行对应的分析了。本节将按照预备节中比较常见的五大类问题来逐一讲解。 a. 磁盘监控
这个是比较好处理的问题在快速添加的规则里实际上我们会在服务器的磁盘使用超过 85% 时进行告警那么收到磁盘告警后可以连接到服务器使用如下命令查看那个目录占用比较高
sudo du -h --max-depth1 /
找到占比比较高的目录和文件后看看是否需要备份后删除来释放出磁盘空间。 b. 错误日志
收到特定的错误日志告警后只需要去对应的项目的 Node.js 性能平台 控制台找到问题 实例 去查看其 异常日志 即可如下图所示 这里会按照错误类型进行规整大家可以结合展示的错误栈信息来进行对应的问题定位。注意这里的错误日志文件需要你在部署 Agenthub 的时候写入配置文件详细可以参见文档 配置和启动 Agenthub 一节中的 详细配置 内容。 c. 进程 CPU 高
终于到了前一节中借助 v8-profiler 导出 CPU Profile 文件再使用 Chrome devtools 进行分析的异常类型了。那么在 Node.js 性能平台 的整套解决方案下我们并不需要额外的去依赖类似 v8-profiler 这样的第三方库来实现进程状态的导出与此相对的当我们收到 Node.js 应用进程的 CPU 超过我们设置的阈值告警时我们只需要在控制台对应的 实例 点击 CPU Profile 按钮即可 默认会给抓取的进程生成 3 分钟的 CPU Profile 文件等到结束后生成的文件会显示在 文件 页面 此时点击 转储 即可上传到云端以供在线分析展示了如下图所示 这里可以看到有两个 分析 按钮其实第二个下标带有 (devtools) 的分析按钮实际上就是前一节中提到的 Chrome devtools 分析这里不再重复讲解了如果有遗忘的同学可以再去回顾下本大章前一节的内容。我们重点看下第一个 AliNode 定制的分析点击第一个分析按钮后可以在新页面看到如下所示内容 这里其实也是火焰图但与 Chrome devtools 提供的火焰图不一样的地方在于这里是将抓取的 3 分钟内的 JS 函数执行进行了聚合展示出来的火焰图在一些存在多次执行同一个函数可能每次执行非常短的情况下聚合后的火焰图可以很方便的帮助我们找到代码的执行瓶颈来进行对应的优化。
值得一提的是如果你使用的 AliNode runtime 版本在 v3.11.4 或者 v4.2.1 以上包含这两个版本的话当你的应用出现类死循环问题比如由于异常的用户参数导致的正则回溯即执行完这个正则要十几年类似于 Node.js 进程发生了死循环这类问题时可以通过抓取 CPU Profile 文件来很方便地定位到问题代码详细信息有兴趣的同学可以看下 Node.js 性能平台支持死循环和正则攻击定位。 d. 内存泄漏
与 CPU 高的问题一样当我们收到 Node.js 应用进程的堆内存占据堆上限的比率超过我们设置的阈值时我们也不需要类似 heapdump 这样的第三方模块来导出堆快照进行分析我们还是在控制台对应的 实例 点击 堆快照 按钮即可生成对应 Node.js 进程的堆快照 生成的堆快照文件同样会显示在 文件 列表页面点击 转储 将堆快照上传至云端以供接下来的分析 与上面一样下标带有 (devtools) 的分析按钮还是前一节中提到的 Chrome devtools 分析这里还是着重解析下 AliNode 定制的第一个分析按钮点击后新页面如下图所示 首先解释下上面的总览栏目的内容信息
文件大小 堆快照文件本身的大小Shallow Szie 总大小 回顾下上一节中的内容GC 根的 Retained Size 大小其实就是堆大小也等于堆上分配的所有对象的 Shallow Size 总大小因此这里其实就是已使用的堆空间对象个数 当前堆上分配的 Heap Object 总个数对象边个数 这个稍微抽象一些假如 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 含义是一致的它表示对象的父引用关系链我们可以来看下 这里 globa1279 对象的 clearImmediate 属性指向 timers.js()15325而 timers.js()15325 的 context 属性指向了可疑的泄漏对象 system / Context15249。
在绝大部分的情况下通过结合 Search 视图 和 Retainers 视图 我们可以定位到指定对象在 JavaScript 代码中的生成位置而 簇视图 下我们又可以比较方便的知道堆空间被哪些对象占据掉了那么综合这两部分的信息我们就可以实现对线上内存泄漏的问题进行分析和代码定位了。 e. 出现核心转储
最后就是收到服务器生成核心转储文件Core dump 文件的告警了这表示我们的进程已经出现了预期之外的 Crash如果你的 Agenthub 配置正常的话在 文件 - Coredump 文件 页面会自动将生成的核心转储文件信息展示出来 和之前的步骤类似我们想要看到服务端分析和结果展示首先需要将服务器上生成的核心转储文件转储到云端但是与之前的 CPU Profile 和堆快照的转储不一样的地方在于核心转储文件的分析需要我们提供对应 Node.js 进程的启动执行文件即 AliNode runtime 文件这里简化处理为只需要设置 Runtime 版本即可 点击 设置 runtime 版本 即可进行设置格式为 alinode-v{x}.{y}.{z} 的形式比如 alinode-v3.11.5版本会进行校验请务必填写你的应用真实在使用的 AliNode 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 性能平台 的整套面向 Node.js 应用开发的监控、告警、分析和定位问题的解决方案的架构和最佳实践希望能让大家对平台的能力和如何更好地结合自身项目进行使用有一个整体的理解。
限于篇幅最佳实践中的 CPU Profile、堆快照和核心转储文件的分析例子都非常的简单这部分的内容也更多的是旨在帮助大家理解平台提供的工具如何使用以及其分析结果展示的指标含义那么本书的第三节中我们会通过一些实际的生产遇到的案例问题借助于 Node.js 性能平台 提供的上述工具分析过程来帮助大家更好的理解这部分信息也希望大家在读完这些内容后能有所收获能对 Node.js 应用在生产中的使用更有信心。
原文链接 本文为云栖社区原创内容未经允许不得转载。
