一种实现scripterror监控和上报的方法与流程

本发明涉及web应用监控技术领域，具体的说，是一种实现scripterror监控和上报的方法。

背景技术：

随着web开发的兴起，现在许多应用都是以web应用的形式展示给用户。无论现在流行的h5、小程序，都属于前端开发的范畴。然而一个优秀的web项目不仅要做好正常情况下的用户体验，还要考虑当系统报错时，如何能够快速定位问题并解决问题，只有做好错误情况的监控，才能提高快速定位问题并解决问题的效率，只有快速定位问题并解决问题，才能让用户基本感受不到系统报错了而是非常顺滑的正常体验。但是，一个经过了大量测试及联调的项目仍会有十分隐蔽的缺陷存在，因此对于直面用户的前端而言，异常捕获与上报是至关重要的。现有技术中，尚没有完善的监控机制可以对异常进行捕获以及将捕获的异常进行上报和类型分析。

技术实现要素：

本发明的目的在于提供一种实现scripterror监控和上报的方法，用于解决现有技术中尚没有完善的监控机制可以对异常进行捕获以及将捕获的异常进行上报和类型分析的问题。

本发明通过下述技术方案解决上述问题：

一种实现scripterror监控和上报的方法，包括：

步骤s100：捕获异常信息，所述异常信息包括js运行时的错误、未处理promise错误、资源加载异常错误和接口错误；

步骤s200：将捕获的异常信息上报至收集平台，具体包括：

步骤s210：当捕获到异常信息时，首先是构建错误对象，再将异常信息传递给接口，所述错误对象包含errormessage、scripturi、lineno、columnno和stack属性；

步骤s220：新建一个xmlhttprequest类的对象xhr，然后利用xhr的open函数发送给node中间层，将open函数中需要请求的方式设置为post；

步骤s230：设置请求头，进行跨源通信，捕获具体报错信息，并发送给服务器进行处理；

步骤s240：对象xhr调用send函数，将所述步骤s210中构建的错误对象发送给服务器；

步骤s250：采用source-map插件进行sourcemap解析并定义post接口，获取前端传过来的错误信息且压缩文件路径；

步骤s260：通过前端传过来的异常文件路径获取服务器端map文件地址，然后将压缩后的行列号传递给sourcemap返回的promise对象解析具体报错信息，将异常信息上报至后台服务器。

进一步地，所述步骤s100具体包括：

采用window.onerror监控和函数window.addeventlistener('error')捕获js运行时的错误类型，其中window.onerror含有详细的error信息error.stack；

采用函数window.addeventlistener('unhandledrejection')捕获未处理promise错误；

采用window.addeventlistener('error')捕获资源加载异常错误；

采用封装xmlhttprequest或者fetch函数捕获全局的接口错误。

进一步地，所述步骤s230具体包括：

步骤s231：为页面上script标签添加crossorigin属性，增加crossorigin属性后，浏览器将自动在请求头中添加一个origin字段，发起跨来源资源共享请求，origin向后台服务端表明了请求来源，服务端将根据来源判断是否正常响应；

步骤s232：响应头中增加access-control-allow-origin来支持跨域资源共享；

步骤s233：定义域名的access-control-allow-origin的响应头中需带上vary:origin，所述vary字段用于为缓存服务器提供缓存规则及缓存筛选的依据；

步骤s234：捕获到具体的报错信息。

进一步地，所述步骤s260具体包括：构建一个错误信息对象，所述错误信息对象包含报错信息、报错文件路径、报错文件行号、报错文件列号和报错堆栈属性。

本发明与现有技术相比，具有以下优点及有益效果：

本发明因此为了更好的性能及用户体验，前端项目的错误监控也应该配套起来，scripterror监控作为监控中重要一环，当页面发生报错时，通过上报错误信息，能及时发现存在的问题，修复优化、减少损失。

附图说明

图1为本发明的过程示意图；

图2为本发明的框架示意图；

图3为本发明的流程示意图。

具体实施方式

下面结合实施例对本发明作进一步地详细说明，但本发明的实施方式不限于此。

实施例1：

结合附图1所示，一种实现scripterror监控和上报的方法，包括：

步骤s100：捕获异常信息，所述异常信息包括js运行时的错误、未处理promise错误、资源加载异常错误和接口错误，具体包括：

采用window.onerror监控和函数window.addeventlistener('error')捕获js运行时的错误类型，其中window.onerror含有详细的error信息error.stack；

采用函数window.addeventlistener('unhandledrejection')捕获未处理promise错误；

采用window.addeventlistener('error')捕获资源加载异常错误；

采用封装xmlhttprequest或者fetch函数捕获全局的接口错误。

步骤s200：将捕获的异常信息上报至收集平台，包括：

步骤s210：当捕获到异常信息时，首先是构建错误对象，再将异常信息传递给接口，所述错误对象包含errormessage、scripturi、lineno、columnno和stack属性；

步骤s220：新建一个xmlhttprequest类的对象xhr，然后利用xhr的open函数发送给node中间层，将open函数中需要请求的方式设置为post；

步骤s230：设置请求头，进行跨源通信，捕获具体报错信息，并发送给服务器进行处理；

步骤s240：对象xhr调用send函数，将所述步骤s210中构建的错误对象发送给服务器；

步骤s250：采用source-map插件进行sourcemap解析并定义post接口，获取前端传过来的错误信息且压缩文件路径；

步骤s260：通过前端传过来的异常文件路径获取服务器端map文件地址，然后将压缩后的行列号传递给sourcemap返回的promise对象解析具体报错信息，将异常信息上报至后台服务器。

实施例2：

在实施例1的基础上，所述步骤s230具体包括：

步骤s231：为页面上script标签添加crossorigin属性。增加crossorigin属性后，浏览器将自动在请求头中添加一个origin字段，发起一个跨来源资源共享请求。origin向服务端表明了请求来源，服务端将根据来源判断是否正常响应；

步骤s232：响应头中增加access-control-allow-origin来支持跨域资源共享。access-control-allow-origin:*表示通过该跨域请求，且该资源可以被任意站点跨站访问。而当该资源仅允许来自http://127.0.0.1:8066的跨站请求，其它站点都不能跨站访问时，将可以返回；

步骤s233：定域名的access-control-allow-origin的响应头中需带上vary:origin。vary字段的作用在于为缓存服务器提供缓存规则及缓存筛选的依据。当增加vary:origin响应头后，缓存服务器将会按照origin字段的内容，缓存不同版本，在请求响应时根据请求头中的origin决定是否能够使用缓存响应。

如果不加vary将存在错误命中缓存的问题，如图1所示，第一个请求(origin:127.0.0.1:8066)响应被浏览器缓存了，当第二个请求(origin:127.0.0.1:8888)发起，被错误命中了前一个请求的缓存，收到了access-control-allow-origin:http://127.0.0.1:8066的响应时，将导致资源加载失败。所以当access-control-allow-origin不是返回为*时，需要加上vary返回头来避免引缓存导致的权限问题。

跨域脚本报错产生scripterror。通过以上方式进行处理后将能够捕获到具体的报错信息了。

进一步地，所述步骤s260具体包括：构建一个错误信息对象，所述错误信息对象包含报错信息、报错文件路径、报错文件行号、报错文件列号和报错堆栈属性。下面具体阐述如何对这些前端异常上报至收集平台的步骤，如图2、图3所示：

步骤s301：当捕获到异常时，首先是构建错误对象，该对象主要包含errormessage、scripturi、lineno、columnno、stack属性，然后将异常信息传递给接口；

步骤s302：将异常信息上报给node中间层进行相应的处理。首先是新建一个xmlhttprequest类的对象xhr，然后利用xhr的open函数发送给node中间层。将open函数中需要请求的方式设置为post；

步骤s303：设置请求头并发送相应的参数信息；

步骤s304：发送参数。利用步骤二新建的xhr对象，调用send函数，讲步骤1中构建的错误信息对象发送出去；

步骤s305：进行sourcemap解析并定义post接口。然后获取前端传过来的报错对象并且压缩文件路径；

步骤s306：解析原始报错数据，将异常上报至后台。构建一个错误信息对象，主要包含：报错信息、报错文件路径、报错文件行号、报错文件列号、报错堆栈这些属性。

尽管这里参照本发明的解释性实施例对本发明进行了描述，上述实施例仅为本发明较佳的实施方式，本发明的实施方式并不受上述实施例的限制，应该理解，本领域技术人员可以设计出很多其他的修改和实施方式，这些修改和实施方式将落在本申请公开的原则范围和精神之内。