房产经纪人页面错误信息采集方案

背景

痛点及问题梳理

总结分析与设计

有了问题，就要考虑解决方案了。调研了业内比较出名的监控方案，有Sentry、ARMS、Fundebug等。一是了解一下大致的实现思路，二是评估一下直接接入的可能性。如果要直接接入，那肯定挑一个免费开源的，Sentry当属首选。但深入调研后，发现要接入并部署Sentry，后端侧要做的事情工作量其实更大。当下面临的情况是业务上等着用，资源投入又不可能太多，于是打算先找一个中间过渡方案，依托现有错误采集服务端的资源，在前端侧快速调整一下，来支持线上业务。同时也要为后续接入Sentry、或是中台的监控方案预留可扩展性。
基于这种考虑，这次调整的重点放在数据采集上，主要解决采集错误信息不够充分的问题，来缓解问题定位上的痛点。至于数据采集上来后的可视化平台，数据分析报表等比较重的工作，还是考虑后续通过接入第三方监控系统或中台的服务来解决。
接下来看一下具体的调整措施：
1、对原有监控探针做一些调整，通过在window上添加监听和对事件劫持来补全之前漏抓的场景；
2、强化静态代码扫描，lint规则中加入针对script标签crossdomain的检查。对于被允许CORS域名下的script标签，如果没有crossdomain属性直接lint报错。暂不对document.createElement("script")做劫持来添加crossdomain属性，因为第三方js中可能会用到，且有些域名不允许跨域，可能产生加载报错，所以只在lint环节打印出来，人工确认一下；
3、针对偶发类错误设计一套场景还原方案，通过采集更多维度的信息来辅助还原异常现场，后面会具体讲到具体方案；
4、增加采集器自检能力。在URL中预留一个自检查开关，默认处于关闭状态，需要自检时可手动打开。例如/user/brokerhomeV2?xxx_trace=true。开关打开后会异步执行document.createElement("script")来加载固定地址下的一段脚本，该脚本里是故意设计好的一些报错用例，方便在线验证。这个脚本独立发布，可以任意修改。同时，开关打开后，日志上报方法会在控制台打印上报内容，便于开发人员及时确认。
5、在1的基础上对监听和事件劫持做wrap，预留对接入第三方监控的兼容性。
改造前后方案对比：

至于vue或react里的异常，用window.onerror是捕获不到的。需要借助vue的errorHandler，react的ErrorBoundary来处理。以vue为例，实现思路大致如下：

function wrapErrorHandler(ErrorDetector, Vue) {  
  Vue = Vue || window.Vue;  
  
  if (!Vue || !Vue.config) return;  
  
  var _oldOnError = Vue.config.errorHandler;  
  Vue.config.errorHandler = function VueErrorHandler(error, vm, info) {  
    var metaData = {};  
  
    // vm and lifecycleHook are not always available  
    if (Object.prototype.toString.call(vm) === '[object Object]') {  
      metaData.componentName = formatComponentName(vm);  
      metaData.propsData = vm.$options.propsData;  
    }  
  
    if (typeof info !== 'undefined') {  
      metaData.lifecycleHook = info;  
    }  
    
    ErrorDetector.captureError(error, {  
      extra: metaData  
    });  
    
    if (typeof _oldOnError === 'function') {  
      _oldOnError.call(this, error, vm, info);  
    }  
  };  
} 

总结

对于页面错误信息，我们把它大致归为两类。一类是页面加载过程中就会报出来的错误，一类是页面加载完成后，需要用户在特定操作下，才会报出的错误。第一类错误理论上在浏览器（UA）确定的情况下，用户会话ID和URL确定的情况下，该类错误绝大多数可以说是必现的。这类错误通过现有的UA、用户会话ID和URL可以直接还原场景。不需要再采集用户行为信息和截屏。第二类就是由用户交互产生的，这类正是场景比较复杂，文章开头例子中难以复现的那种，需要借助采集用户行为信息和截屏来还原现场。
这两类信息在采集时需要区分对待，第一类信息只采集终端信息、访问信息、错误信息，第二类信息才需要加上行为信息和截屏信息作为补充。对于这块的处理是通过在window.onload配置一个开关来实现，开关实现如下：

$(window).load(function(){  
    ErrorDetector.pageLoadComplete = true;  
})  

window.setTimeout
window.setInterval
window.requestAnimationFrame
EventTarget.addEventListener
EventTarget.removeEventListener
XMLHTTPRequest.open
XMLHTTPRequest.send
window.fetch
History.pushState
History.replaceState
接下来看一下数据分片
页面加载完成后，开始录制用户行为，行为数据以队列形式存放在监控探针js的全局变量上。这个变量上的内容会在异常发生时，被上报给后台服务。但这个录制什么时候停，什么时候重新开始录制，却需要制定一个策略。我们的方案采取以URL变化和交互error发生两个时刻来做切割。理由如下：
1、URL变化意味着场景切换，场景切换前上下文的交互细节不需要过多关注。URL、用户会话ID、浏览器(UA)能够共同确定交互类错误发生前的最近上下文环境；
2、同一页上发生多次异常，没有必要每个上报内容都包含页面一进来到报错时点的全量交互信息，以报错点切割开就行。每段报错切片会按时间顺序上报给后台，将它们合在一起可以形成上下文链，这个从时间上可以确定。
3、采集数据不是越多越好，对网络传输，数据存储都会是挑战，甚至会淹没有效数据。所以应避免上报过多冗余数据。
基于以上理由，每次上报的用户行为采集切片方案设计如下：

至于SPA类的web，需要监控探针暴露一个方法给到router切换时来调用，以处理清空队列等动作。
聊完了用户行为抓取，再来看屏幕截取。
理论上拿回用户行为日志后，可以在本地浏览器环境中注入上下文后，逐一执行来进行回放，从而还原现场。但是，现实情况下要搭建这样一套交互回放系统，其成本投入却是现阶段不能承受的，所以放弃，还是老老实实截图去。虽说截图对于问题定位不是必须的，但有总比没有好，一图胜万言，查问题效率上是有很大提升的。实践下来，截屏+stack trace绝对是问题定位大杀器。
接下来看看截屏数据采集的具体方式：
截屏是借助html2canvas插件来实现的。通过将当前页转成canvas后再序列化为base64，base64的内容会和行为数据队列序列化后的结果一起上报给服务端。
截屏转base64代码如下：

function captureScreen() {  
    var targetDom = document.querySelector("body");  
    html2canvas(targetDom, {  
        useCORS: true,  
        allowTaint: false  
        height: targetDom.scrollHeight,  
        width: targetDom.scrollWidth,  
    }).then(function(canvas) {  
        var context = canvas.getContext('2d');  
        context.mozImageSmoothingEnabled = false;  
        context.webkitImageSmoothingEnabled = false;  
        context.msImageSmoothingEnabled = false;  
        context.imageSmoothingEnabled = false;  
        var quality = 0.92;  
        var base64Image = canvas.toDataURL('image/png', quality).substring(22);  
        ErrorDetector.accidentScene.img = base64Image;  
    })  
} 

代码中imageSmoothEnabled = false是为了提高图片清晰度，抗锯齿用的。由于html2canvas中用到了Promise，对于低版本浏览器需要加入promise垫片，这里用的是promise-polyfill。至于base64是否再要做压缩，默认图片质量下实际生成的大小在220~450K之间，在保证清晰度情况下，这个大小范围是可接受的。

异常上报

于是上报方案设计如下：
1、交互场景error只搜集js运行时这类错误，在window.onerror中采集。错误唯一性通过message，source，lineno，colno加分隔符后拼接成的字符串作为唯一标识（unique key）。
2、window.onerror中区分对待页面加载过程中的错误和页面加载后由用户行为操作产生的错误。通过在window.onload中设置加载完毕标志，加载中错误走原来通道上报，加载后走场景还原上报通道。这样可以有效降低图片上报数量。
3、同一错误只在客户端上报一次。利用客户端存储将上报过错误的唯一标识存下来，下次上报前比对是否已上报过，已上报过则忽略，否则继续上报。
4、同一错误服务端只采集一次。由于用户基数大，仅靠客户端去重是不能有效降低上报总量的。搭建一台node配redis，用来存储上报过错误的唯一标识。客户端上报前会先拿唯一标识去服务器端作比对，如果没有上传过才上传，上传后唯一标识会存入本地客户端存储中，下次直接在本地比较时就会拦截，不会给node服务带来压力。
为了在客户端做一层去重，需要在本地保留上传过错误的摘要。本地存储采用indexedDB，以队列存储，先进先出，大小配30（数字是按线上交互类报错的单个用户平均数放大5倍后的预估值）。

实际去做的时候，发现最初的方案有些问题

1、首先，用message+source+lineno+colno来唯一标识特定错误是不精确的。一些错误是由基础方法里抛出来的，报错位置相同，但产生原因不相同。要唯一标识出特定原因的错误还是得用stack trace。
2、存储用indexeddb的话，有低版本浏览器兼容问题。为了兼容低版本浏览器还得单独实现一套基于localstorage的队列存储，做是可以做，但就当下而言不经济。
针对上面的问题，采取如下调整：
对于第一个问题，把唯一标识换成stack trace。但limit放大后的stack trace太长了，还有格式问题，直接拿来做unique key不太合适。所以对其md5一下后作为key使用。
至于第二个问题，放弃indexeddb直接用localstorage。但这样一来，如果还是走每次上报就更新localstorage的模式的话，要做size超限判断、删除等操作就很麻烦。思来想去后，决定采用批量更新模式。
每次发生场景上报后不直接写localstorage，而是放到js内存对象中更新，以map形式存储。在window.beforeunload时，将map对象序列化后一次性存储下来。在页面载入时，监控探针也能一次性从localstorage里取到map后反序列化到内存变量中，这对于后续的判重来说是比较方便的。至于更新策略，是通过保留引用在队列中，通过维护队列的先进先出从而更新map对象里的内容的。

至此，方案调整完毕。

总结

参考文献

作者简介

孙淘熔：HBG二手房技术部资深开发工程师，18年3月加入公司，目前负责中国网络经纪人、网络门店、家装店铺等前端侧工作，对面向B端的前端开发有深入了解。

阅读推荐