本文主要介绍了微信小程前端错误异常监控系统，用于捕获收集线上小程序项目代码在使用生命周期中出现的异常情况。

背景

每一个前端项目上线后都会在出现线上问题，不论是PC项目还是移动端项目，在后端服务中，可以通过错误或业务日志来记录错误的情况，这些数据可以帮助开发者快速定位系统的状态，追查bug，了解错误异常的基本情况。但是在前端开发的领域内，成型的日志监控系统比较少见，尤其是在小程序端。

关于前端异常监控，网上有很多开源的项目，比如腾讯的badjs，淘宝的JSTracker，阿里巴巴的fdSafe系统，支付宝的sai.js，国外的sentry异常捕获平台，到目前为止，已经有很多的解决方案在很多年前被提出并且实现了，但是他们的方案并不是完全适用于每一个项目的开发者，比如国内的fundebug，关注了所有的Error收集场景，但是他们解决的问题其实都是接下来要讲到的一些通用问题，如果针对到具体项目，还是看业务方如何选择。

每当小程序出现卡顿的情况，用户都会下意识的考虑是自身手机的问题，但是在使用别的小程序却不存在这种问题，就会导致用户退出不再使用。因为小程序的特点，获取用户的成本很低，同样用户放弃使用的成本也很低，那么既然用户体验很差，所以用户很大概率会直接退出，并且从此不再使用。

如上图所示，微信在小程序后台也有做错误监控，但是监控手段没法将错误原因细分。比如以下几点：
?  网络请求错误统计，但无法快速定位到服务端；

?  有JS错误统 计，但无法快速定位错误堆栈；

?  无页面维度监控，无法知道用户打开页面的体验；

?  无地域运营商监控，无法知道不同地域运营商下的小程序性能；

?  页面退出率高，无法知道是否是性能导致的；

?  关于promise或async/await异步方法中报错信息的没有监控。

设计方案

1. 架构设计

在参考了市面上诸多的监控系统，并结合原始前端监控的结构，总结一下：

1）SDK编写，主要是暴力埋点，错误拦截，代理监控，上报策略，API设计，日志接口以及数据存储；

2）上报的日志实现实时查询；

3）监控日志可视化管理后台的开发。

以上3点是基本，后期可以再加入场景重现，多平台管理，邮件报警等成熟的功能

2. 流程设计

用户在使用小程序的整体生命周期内，sdk扮演一个类似行车记录仪的角色，用户在点击使用产品时触发到项目内部的错误，SDK接收到这个信息，然后将这个错误触发的时间点以及作为开发正想要收集的错误信息在本地先做一个简单的整理， 作为主体上报至后台服务端，服务端接收数据并根据预先定好的规则保存进入数据库当我们打开后台管理系统的时候会将这些数据以项目分组的形式，再做错误分组，做一个可视化的展示。当某些错误到达上限阈值的时候会向项目的参与人发送报警邮件。

3. SDK设计

如何定位小程序前端线上问题，是一个比较复杂的问题，因为它可能在用户使用过程中的一系列操作之后发生，错误的原因有很多，可能源于不同机型，不同环境版本，网络接口，请求环境或者复杂的操作等。

尤其是这样四个W的问题：谁在什么环境下做了什么导致什么错误？

接下来，我先从这个角度开始设计小程序监控系统。

WHO did WHAT and make WHICHerror in WHICH environment？

（1）第一个W——WHO

基础用户信息，当监听到用户在引入sdk时有配置开关，那就可以在小程序项目启动的到时候执行微信原生方法，获取用户信息。其中网络状态中的IP是需要在上报错误的时候服务端获取，此外openid和unionid因为不同的小程序在获取到之后一般保存在全局globalData或本地storage缓存中。

（2）第二个W——DO WHAT

小程序在整个使用的生命周期里面出现的 各种直观的错误情况，我从用户可视角度分为五种，对于开发者和运营者来说，错误等级和优先级都是一致的。

正常情况下，一般用户使用时出现这些问题的时候都会首先想到的是自身手机出现问题，可是如果其他小程序可以正常使用，或者使用流程没有问题的话，用户的流失率就会增加。所以，当页面出现这些问题的时候都可以认定他发生了错误。

（3）第三个W——WHICH ERROR

这里要获取的是错误的分类，三种类型的错误：

1）http请求错误

a、请求返回的statusCode不是200时

b、request的fail回调函数被触发时

当发生以上事件时，存储两部分日志，一个是请求的堆栈信息，一个是事件请求的全部信息，包括请求头部，请求方式，请求参数，请求地址等。

2）js请求错误

JavaScript异常监控的方法采用暴力埋点的方式，但是由于它会造成污染代码的后果，所以在api使用的时候会提供开关的形式来谨慎选择。默认采用劫持函数的形式。

在默认app.js中监听onLaunch、onShow、onHide、onError生命周期函数，其中在onLaunch中执行获取用户基础信息，当监控到有执行onError是就记录一次报错信息。

js的错误类型主要分为以下几种：

3）资源上传下载错误

小程序不能直接分享到朋友圈，我们一般采用的方法是将小程序码绘制成canvas图片，然后保存到手机相册，再以图片的形式来分享朋友圈。上传图片或canvas上的元素时，采用wx.uploadFile方法来上传，然后绘制对应文件的tempFilePaths缓存，这时我们可以监控wx.uploadFile的fail回调函数。当我们要把绘制好的图片保存到相册时，使用wx.downloadFile方法，这里也是监控这个方法的fail回调函数。

（4）第四个W——WHICH ENVIRONMENT

此外，为了更好地复现用户的操作流程，当用户再点击页面按钮或者打开页面的时候，sdk还会收集保存页面的堆栈信息和执行方法的堆栈信息，这样在可视化后台就可以直接观察出用户的使用流程。

每一条错误信息在上报的时候都会存储这些类型的数据，当收集到信息的时候就会在sdk中对错误进行分类，根据捕获的错误关键字来区分错误的类型和等级。在上报的同时增加每条错误信息的标识和分组。

4. 上报方式

异常错误上报方式采用接口请求的方式，将具体数据收集到后向服务端发送，无需关注是否发送成功，但是，考虑到在大型应用中，日志量比较大，我采取抽样，合并，过滤三个方法减少日志的输出。

再使用api的时候可以配置当前日志达到多少条的时候进行上报，默认值为3条，同时可以配置上报接口是异步还是同步，init的时候配置reportType的方式是sync（同步）/async（异步），默认为sync。

在初始化sdk的时候可以新增错误类型，当发现监控到的错误是属于配置好的信息，那就选择不上报。

上报错误消息，但是这里需要再做一个操作，那就是监控的是非上报接口的https请求。如果监控系统的服务出现什么问题导致这个上报接口失败，那就说明这个借口已经出错。如果同步监听的话，就会导致陷入死循环，不停地监控不停的上报。所以需要将这个接口或者域名排除出去。

5. 后台可视化系统

当服务端得到前端上报的信息之后，经过数据分析和处理，需要前端可视化的展示数据分析后的结果。

这个后台其实是一般的工具系统，包括用户管理、权限管理、错误聚合以及展示错误详情。具体展示整个应用的日志和单个用户的单个错误。

1）整个应用：

· 固定时间段内的发生的错误总数，错误占比，可视化曲线走势图

· 相同错误的分组集合信息

· 每一项分组的错误优先级，开发人员的分配，可操作功能

· 根据sdk版本，错误分类筛选

2）单个用户

· 用户基本访问页面堆栈信息，执行方法堆栈信息，接口请求堆栈信息

· 每条错误的基本信息，错误位置，详情，错误时间点

· 用户基础信息，手机版本，使用基本场景

总结

前端的错误监控是一个任重而道远的任务，它的存在对任何前端开发都起一个相当重要的作用。我们监控系统是针对微信小程序的原生前端代码做异常监控，会逐步针对百度，支付宝，头条小程序做兼容，做到一套SDK监控全平台。

因为小程序的特殊性，它不同于传统的web前端监控，对于部分能有效的体现错误详情的方式还不够友好，我们将通过soursemap等方式来变相模拟。同时也会对promise或async/await等做兼容监控，对上报方式作出更优化的处理。

作者简介：

赵炳琦  58同城ABG高级前端开发工程师 负责二手车小程序相关开发