摘要

携程小程序自动化错误预警方案是一套完整且通用的小程序前端错误监控方案。此方案提供小程序错误自动采集SDK，并对错误所在的页面路径进行偏移矫正，能够准确通知相应的开发负责人；将错误信息分为生产、测试、开发3种阶段，根据错误发生的阶段提供相应的错误预警及处理方案；开发负责人只需在小程序管理平台配置告警所需信息，即可快速接入、实时监控生产报错、生成告警通知；源码映射能力可以帮助开发者快速定位错误原因，提升修复效率。接入此方案可实时捕获开发环境错误，确保在小程序发布上线前发现并解决业务报错，可极大地减少线上小程序的错误量。

一、为什么要做错误监控

携程小程序产品是to C的，用户访问量大，使用的机型和场景复杂多样；当用户遇到问题时，我们无法保证所有用户都及时反馈，且提供明确、详细的信息。因此，为了保证系统稳定运行、提高用户体验，我们需要主动收集错误信息、实时监控错误变化趋势、及时解决。

为了提升小程序代码质量、守护线上页面质量，Web前端团队提出了携程小程序的小程序错误预警方案，可分为4个阶段，如图1所示：

携程小程序自动化错误预警方案在自动化部署阶段将buildId 注入代码，并通过固定robotId的方式获取对应的 sourcemap 文件；客户端运行时自动采集错误信息，同时进行埋点上报；服务端处理存储的错误数据，并按照页面路径、错误类型等维度进行分类；告警平台将实时监控报错情况，根据自定义的告警规则给开发负责人发送告警通知，详细的方案设计参见图2：

二、sourcemap 存储及映射

携程小程序发布是通过ci工具上传小程序代码实现的。在发布前，我们会将无线持续交付平台（Mobile Continuous Delivery，下文统称为MCD发布平台）创建的buildId注入到小程序代码中，以供运行时获取。由于微信不支持通过版本信息或其他的唯一信息获取对应的 sourcemap 文件，我们设计了一套获取相应 sourcemap 的方案：

• 我们通过固定robotId的方式上传源码，从而获取对应的 sourcemap 文件；在成功上传小程序代码后，将延迟5秒后使用ci工具拉取最近一次上传版本的 sourcemap 文件；此外，将会比对 sourcemap 的解压源文件中buildId与当前上传代码中的buildId是否一致，如果不一致将再次获取，从而确保上传的源码和获取的 sourcemap 文件是匹配的，保证源码映射的准确性。
• 随后，将 sourcemap 文件存储到携程的文件服务器，并将服务端返回的文件链接地址、当前的buildId、时间点以及自定义备注等信息以对象的形式保存到数据库中，即可实现buildId与 sourcemap 文件的信息存储及映射。

三、错误采集及日志上报

在小程序客户端运行时，我们会在 wx.onError 和 wx.onUnhandledRejection 的回调函数中捕获到所有的错误信息，随后进行错误信息的筛选、处理和提取。其中，错误的关键信息有：pagePath, message, stack等。此时，我们会对捕获到错误时所在页面的pagePath进行偏移纠正，避免页面偏移导致误报的情况。那么如何实现错误偏移纠正和错误采集呢？

首先，在上传小程序代码包前，我们会通过读取app.json的内容，获取所有注册的页面路径，并将其注入到小程序代码中。接着，在捕获到错误信息时，我们会对error stack进行解析，从上往下进行页面路径贪婪匹配，匹配到的第一个页面就是发生报错的页面。随后，将错误信息、当前的appId以及发布时注入的buildId一同通过用户行为数据采集系统（User Behavior Tracking，下文统称为UBT）的错误接口上报，上传到UBT的服务端。至此，便完成了一次错误采集与上报的流程。

四、数据聚合

采集到上报的错误数据后，服务端会对数据进行清洗、过滤、聚合等操作，随后将预处理后的数据存入APM的MySQL数据库中。通过内部的APM监控平台主动读取数据库中的数据，实现各种自定义维度的数据聚合，比如分别根据部门、客户端平台（Platform）、报错页面路径（PagePath）、小程序版本（version）、Top50错误类型等维度进行排序并展示数据列表（如图3）。

这些处理后的信息为下文的错误告警提供了数据支撑，告警主要依据的是报错页面路径（PagePath）及Top50错误类型这两个维度。

五、错误实时监控告警

除了业务主动去APM上实时查看报错情况，我们还提供了错误告警机制，会在不同阶段对采集到的错误进行消息推送提醒，详细流程如图所示：

从上图可看出，错误告警贯穿整个小程序的开发流程，共分为三个版本，包括开发版、体验版以及生产版。错误告警服务每隔一段时间轮询不同环境的报错信息（调用APM提供的数据聚合接口），若报错量超过我们设置的告警阈值（详情可见表1），则会根据错误页面找到对应的Bundle(最小的业务线单位)，然后再找到对应的开发人员或管理员（对应关系已在小程序管理平台中注册），通过携程内部沟通工具（下文统称为TripPal）将错误提醒推送给相关人员，在收到信息后可以通过点击信息直接跳转到具体的APM错误页面中，在APM中可以进行错误的反查与定位。下表展示了各阶段告警配置的详细情况：

（1）开发版

在开发阶段，及时捕获错误有助于开发人员第一时间进行修改，因此每隔1分钟，服务端会获取每个页面路径的报错量，只要页面有报错，将推送消息至该Bundle的相关人员。

（2）体验版

体验版是一个完整稳定的版本，是可以作为发布候选的版本，因此对该环境的报错进行监控是十分必要的。体验版除了能接收到与开发版一致的错误信息外，还会发送反馈消息，由Bundle管理员进行审批，审批的意义在于告知管理员当前要发布到生产的代码中存在错误，需要管理员知晓并判断是否修改，若10分钟内未处理，将再次发消息进行提醒。

在MCD发布平台生成体验码时，若仍有Bundle未处理体验版报错，将在发布群中再次提醒：

以上两个阶段都属于开发测试阶段，目的在于将所有的业务报错信息都在开发阶段暴露出来，然后让各个业务及时修改，保证发到生产的代码没有业务报错。

（3）生产版

总有意外的情况会导致生产运行出现错误，为了更快更全面的感知生产报错，我们会对生产错误进行两个维度的监控：

• 每隔5分钟，服务端获取某类错误的报错量超过 100 的页面路径，随即发出通知消息至相应的开发和管理人员，管理人员此时需要重视下频繁报错是否会对生产业务造成影响并给PMO反馈修复的时间以及是否需要紧急发布。

• 每隔1小时，服务端会获取每个页面路径的报错量，然后聚合到每个具体的Bundle，如果发现Bundle一小时报错量超过了300，也将发送告警信息。

由于通知消息本身不具备强制性、约束力，因此我们接入了公司的告警治理系统（下文统称为BigEyes）。生产版报错将通过BigEyes进行统一通知，如果告警事件未在预设的响应时间内被响应，则进行通知升级，即通知原对象的上级，以此提高业务方的重视程度及故障恢复效率。

为了便于独立小程序的接入，在现有方案的基础上，我们设计并实现了一套通用的可定制化的错误告警配置服务。独立小程序在引用错误采集SDK的前提下，通过在小程序管理平台配置告警所需信息，包括用于告警的专属Trippal服务号、开发负责人、不同环境（正式、体验、开发）的告警阈值等，即可在触发告警条件时，收到服务号发来的错误通知。

六、源码映射

从APM平台查看错误信息时，可以通过错误的详情页面进入小程序错误源码解析系统。由于我们在错误采集时会将buildId和错误相关信息一起上报至服务端，因此错误详细信息内包含报错代码包对应的buildId（如图14）；在点击错误堆栈上的链接跳转至错误源码解析系统时，系统将根据buildId获取到相应的 sourcemap 文件；随后，根据错误信息找到对应的 sourcemap 内容、依据错误位置进行反解析；最后，使用 Monaco Editor 将源码展示在页面中，开发者可以据此查看错误所在的源码位置，从而助力开发者快速、准确定位错误原因。

七、总结

自动化错误预警方案可以帮助各业务方在开发和测试阶段捕获运行时可能出现的业务报错，避免此类错误发布到生产环境，从而降低线上的错误量。在生产环境可以通过告警机制实时监控错误趋势，当出现告警时可通过源码映射系统快速定位错误原因、提高开发者的修复效率。

该方案极大地提升了小程序的运行稳定性，可以有效提升用户体验。自主板小程序接入携程小程序自动化错误预警方案以来，其日均线上报错量降低了95%左右，受到各业务部门的好评，印证了本方案的可行性和有效性。

作者简介

携程前端框架团队，为携程集团各业务线在PC、H5、小程序等各阶段提供优秀的Web解决方案。产品涉及各类前端/Node端应用框架、研发工作台、前端中台化、静态资源发布系统等。当前主要专注方向包括：新一代研发模式探索，Rust构建工具链路升级、Serverless应用框架开发、在线文档系统开发、低代码平台搭建、适老化与无障碍探索等。