监控

沉淀呢
136 阅读4分钟

image.png

一、性能监控

window.performance API 去做各种计算。

二、质量监控

捕获错误-->上报错误（OWL）-->可视化错误（raptor）-->监控报警，发现问题后按一定的条件触发报警。

sdk原理：方法、变量挂到winodw，调用。
throw new Error('错误测试') // 模拟一个错误。

2.1 JS错误

（1）普通js运行时错误
【捕获错误原理】：

  1. 使用window.onerror捕获错误
  2. 使用window.addEventListener('error')捕获错误。
    因为window.onerror含有详细的error堆栈信息，存在error.stack中，所以我们选择使用onerror的方式对js运行时错误进行捕获。
window.onerror = function (msg, url, lineNo, columnNo, error) {
    // 处理错误信息
}

window.addEventListener('error', function (event) {
    // 处理错误信息
}，false)

【上报方式】

  1. 采用ajax 上报
  2. 使用image上报

采用image对象的方式上报错误；使用图片发送get请求，上报信息，由于浏览器对图片有缓存，同样的请求，图片只会发送一次，避免重复上报。

通过Image 对象上报的话，将错误信息拼接在 image标签的src中，例如：

(new Image()).src = report_url+需拼接的错误信息;

（2）Promise异常，未捕获的promise
【捕获错误原理】：
当Promise 被 reject 且没有 reject 处理器的时候，会触发 unhandledrejection 事件。

window.addEventListener('unhandledrejection', function (event) {
  ...
})

image.png 【上报方式】
同上

2.2 静态资源错误（script-js,link-css,img等）加载异常

【捕获错误原理】：
当一项资源（如<img>或<script>）加载失败，加载资源的元素会触发一个Event接口的error事件，并执行该元素上的onerror()处理函数。

object.onerror = function () {
}

window.addEventListener('error', function (event) {
    // 处理错误信息
}，false)

【上报方式】
同上

2.3 API错误

分为ajax请求接口异常和fetch接口请求异常。
【捕获错误原理】：
当promise被reject并且错误信息没有被处理的时候，会抛出一个unhandledrejection。
【上报方式】
同上

2.4 Vue组件运行异常

官网：cn.vuejs.org/v2/api/#err…
【原理】：
如果在组件渲染时出现运行错误，错误将会被传递至全局 Vue.config.errorHandler 配置函数 (如果已设置)。利用这个钩子函数来配合错误跟踪服务是个不错的主意。

vue内部发生的错误会被Vue拦截，因此vue提供方法给我们处理vue组件内部发生的错误。

// 只能捕获render 中的错误
Vue.config.errorHandler = function (err, vm, info) {
  // handle error 处理错误信息, 进行错误上报
  // `info` 是 Vue 特定的错误信息，比如错误所在的生命周期钩子
  // 只在 2.2.0+ 可用
}

2.5 script error的解决方式

说明：这是由于浏览器同源策略，非同源 JS 文件抛出的错误详情被浏览器隐藏，OWL 只接收到 Script error 。

"script error.”有时也被称为跨域错误。当网站请求并执行一个托管在第三方域名下的脚本时，就可能遇到该错误。最常见的情形是使用 CDN 托管 JS 资源。

其实这并不是一个 JavaScript Bug。出于安全考虑，浏览器会刻意隐藏其他域的 JS 文件抛出的具体错误信息，这样做可以有效避免敏感信息无意中被不受控制的第三方脚本捕获。

解决方案：（推荐） 添加 crossorigin="anonymous" 属性。

<script src="http://another-domain.com/app.js" crossorigin="anonymous"></script>

然后服务器端要设置header('Access-Control-Allow-Origin: *')，或者指定域名。

三、埋点(LX)

3.1 什么情况下需要埋点

作用：（WHO）在什么时候（WHEN）什么地点（WHERE）对谁（WHOM）做了什么行为（WHAT）。
推动流程的节点可埋，细枝末节不可埋。

3.2 前端or后端埋点

在需要埋点的场景中，需要分清那些需要前端埋点，那些需要后端埋点。

我认为功能简单，无深度分析需求或者分析事件与后端无交互的情况下可采用前端埋点。

而产品功能复杂，需进行深度下钻与多维分析或分析项与后端交互，前后端均可采集的数据的情况下需采用后端埋点。

3.3 前端埋点方式

image.png

（1）代码埋点

【方式】
以嵌入代码的形式

  1. 采用ajax 上报
  2. 使用image上报 *** 缓存\

【说明】
script src一个js文件（数据收集脚本)； 打开页面执行js脚本，收集收据。

【优点】
可以在任意时刻，精确的发送或保存所需要的数据信息。

【缺点】
工作量较大，每一个组件的埋点都需要添加相应的代码\

（2）可视化埋点

【方式】
将业务代码和埋点代码分离，提供一个可视化交互的页面，输入为业务代码，通过这个可视化系统，可以在业务代码中自定义的增加埋点事件等等，最后输出的代码耦合了业务代码和埋点代码。

【说明】
实际上跟代码埋点还是区别不大。也就是用一个系统来实现手动插入代码埋点的过程。

【优点】

【缺点】 可视化埋点可以埋点的控件有限，不能手动定制。

（3）无痕埋点

【方式】
无埋点并不是说不需要埋点，而是全部埋点，前端的任意一个事件都被绑定一个标识，所有的事件都别记录下来。

【说明】
通过定期上传记录文件，配合文件解析，解析出来我们想要的数据，并生成可视化报告供专业人员分析因此实现“无埋点”统计。

【优点】
由于采集的是全量数据，所以产品迭代过程中是不需要关注埋点逻辑的，也不会出现漏埋、误埋等现象

【缺点】

  1. 无埋点采集全量数据，给数据传输和服务器增加压力
  2. 无法灵活的定制各个事件所需要上传的数据

结论：

在实际项目中考虑到上报数据的灵活定制，以及减少数据传输和服务器的压力，在所需埋点处不多的情况下， 常用的方式是代码埋点。

avatar
文章
阅读
粉丝