前端异常监控解决方案研究.docx
- 文档编号:1113156
- 上传时间:2022-10-17
- 格式:DOCX
- 页数:25
- 大小:214.77KB
前端异常监控解决方案研究.docx
《前端异常监控解决方案研究.docx》由会员分享,可在线阅读,更多相关《前端异常监控解决方案研究.docx(25页珍藏版)》请在冰豆网上搜索。
前端异常监控解决方案研究
前端异常监控解决方案研究
img.aligncenter{
display:
block;
margin:
auto;
}
table{
width:
100%;
margin-bottom:
10px;
}
tabletr{
border-bottom:
#f1f1f1solid1px;
}
tabletd{
padding:
5px10px;
}
前端监控包括行为监控、异常监控、性能监控等,本文主要讨论异常监控。
对于前端而言,和后端处于同一个监控系统中,前端有自己的监控方案,后端也有自己等监控方案,但两者并不分离,因为一个用户在操作应用过程中如果出现异常,有可能是前端引起,也有可能是后端引起,需要有一个机制,将前后端串联起来,使监控本身统一于监控系统。
因此,即使只讨论前端异常监控,其实也不能严格区分前后端界限,而要根据实际系统的设计,在最终的报表中体现出监控对开发和业务的帮助。
一般而言,一个监控系统,大致可以分为四个阶段:
日志采集、日志存储、统计与分析、报告和警告。
采集阶段:
收集异常日志,先在本地做一定的处理,采取一定的方案上报到服务器。
存储阶段:
后端接收前端上报的异常日志,经过一定处理,按照一定的存储方案存储。
分析阶段:
分为机器自动分析和人工分析。
机器自动分析,通过预设的条件和算法,对存储的日志信息进行统计和筛选,发现问题,触发报警。
人工分析,通过提供一个可视化的数据面板,让系统用户可以看到具体的日志数据,根据信息,发现异常问题根源。
报警阶段:
分为告警和预警。
告警按照一定的级别自动报警,通过设定的渠道,按照一定的触发规则进行。
预警则在异常发生前,提前预判,给出警告。
1前端异常
前端异常是指在用户使用Web应用时无法快速得到符合预期结果的情况,不同的异常带来的后果程度不同,轻则引起用户使用不悦,重则导致产品无法使用,使用户丧失对产品的认可。
1.1前端异常分类
根据异常代码的后果的程度,对前端异常的表现分为如下几类
a.出错
界面呈现的内容与用户预期的内容不符,例如点击进入非目标界面,数据不准确,出现的错误提示不可理解,界面错位,提交后跳转到错误界面等情况。
这类异常出现时,虽然产品本身功能还能正常使用,但用户无法达成自己目标。
b.呆滞
界面出现操作后没有反应的现象,例如点击按钮无法提交,提示成功后无法继续操作。
这类异常出现时,产品已经存在界面级局部不可用现象。
c.损坏
界面出现无法实现操作目的的现象,例如点击无法进入目标界面,点击无法内容等。
这类异常出现时,应用部分功能无法被正常使用。
d.假死
界面出现卡顿,无法对任何功能进行使用的现象。
例如用户无法登陆导致无法使用应用内功能,由于某个遮罩层阻挡且不可关闭导致无法进行任何后续操作。
这类异常出现时,用户很可能杀死应用。
e.崩溃
应用出现经常性自动退出或无法操作的现象。
例如间歇性crash,网页无法正常加载或加载后无法进行任何操作。
这类异常持续出现,将直接导致用户流失,影响产品生命力。
1.2异常错误原因分类
前端产生异常的原因主要分5类:
原因
案例
频率
逻辑错误
1) 业务逻辑判断条件错误
2) 事件绑定顺序错误
3) 调用栈时序错误
4) 错误的操作js对象
经常
数据类型错误
1) 将null视作对象读取property
2) 将undefined视作数组进行遍历
3) 将字符串形式的数字直接用于加运算
4) 函数参数未传
经常
语法句法错误
较少
网络错误
1) 慢
2) 服务端未返回数据但仍200,前端按正常进行数据遍历
3) 提交数据时网络中断
4) 服务端500错误时前端未做任何错误处理
偶尔
系统错误
1) 内存不够用
2) 磁盘塞满
3) 壳不支持API
4) 不兼容
较少
2异常采集
2.1采集内容
当异常出现的时候,我们需要知道异常的具体信息,根据异常的具体信息来决定采用什么样的解决方案。
在采集异常信息时,可以遵循4W原则:
WHO did WHAT and get WHICH exception in WHICH environment?
a.用户信息
出现异常时该用户的信息,例如该用户在当前时刻的状态、权限等,以及需要区分用户可多终端登录时,异常对应的是哪一个终端。
b.行为信息
用户进行什么操作时产生了异常:
所在的界面路径;执行了什么操作;操作时使用了哪些数据;当时的API吐了什么数据给客户端;如果是提交操作,提交了什么数据;上一个路径;上一个行为日志记录ID等。
c.异常信息
产生异常的代码信息:
用户操作的DOM元素节点;异常级别;异常类型;异常描述;代码stack信息等。
d.环境信息
网络环境;设备型号和标识码;操作系统版本;客户端版本;API接口版本等。
字段
类型
解释
requestId
String
一个界面产生一个requestId
traceId
String
一个阶段产生一个traceId,用于追踪和一个异常相关的所有日志记录
hash
String
这条log的唯一标识码,相当于logId,但它是根据当前日志记录的具体内容而生成的
time
Number
当前日志产生的时间(保存时刻)
userId
String
userStatus
Number
当时,用户状态信息(是否可用/禁用)
userRoles
Array
当时,前用户的角色列表
userGroups
Array
当时,用户当前所在组,组别权限可能影响结果
userLicenses
Array
当时,许可证,可能过期
path
String
所在路径,URL
action
String
进行了什么操作
referer
String
上一个路径,来源URL
prevAction
String
上一个操作
data
Object
当前界面的state、data
dataSources
Array<Object>
上游api给了什么数据
dataSend
Object
提交了什么数据
targetElement
HTMLElement
用户操作的DOM元素
targetDOMPath
Array<HTMLElement>
该DOM元素的节点路径
targetCSS
Object
该元素的自定义样式表
targetAttrs
Object
该元素当前的属性及值
errorType
String
错误类型
errorLevel
String
异常级别
errorStack
String
错误stack信息
errorFilename
String
出错文件
errorLineNo
Number
出错行
errorColNo
Number
出错列位置
errorMessage
String
错误描述(开发者定义)
errorTimeStamp
Number
时间戳
eventType
String
事件类型
pageX
Number
事件x轴坐标
pageY
Number
事件y轴坐标
screenX
Number
事件x轴坐标
screenY
Number
事件y轴坐标
pageW
Number
页面宽度
pageH
Number
页面高度
screenW
Number
屏幕宽度
screenH
Number
屏幕高度
eventKey
String
触发事件的键
network
String
网络环境描述
userAgent
String
客户端描述
device
String
设备描述
system
String
操作系统描述
appVersion
String
应用版本
apiVersion
String
接口版本
这是一份非常庞大的日志字段表,它几乎囊括了一个异常发生时,能够对异常周遭环境进行详细描述的所有信息。
不同情况下,这些字段并不一定都会收集,由于我们会采用文档数据库存储日志,因此,并不影响它的实际存储结果。
2.2异常捕获
前端捕获异常分为全局捕获和单点捕获。
全局捕获代码集中,易于管理;单点捕获作为补充,对某些特殊情况进行捕获,但分散,不利于管理。
a、全局捕获
通过全局的接口,将捕获代码集中写在一个地方,可以利用的接口有:
window.addEventListener(‘error’)/window.addEventListener(“unhandledrejection')/document.addEventListener(‘click’)等
框架级别的全局监听,例如aixos中使用interceptor进行拦截,vue、react都有自己的错误采集接口
通过对全局函数进行封装包裹,实现在在调用该函数时自动捕获异常
对实例方法重写(Patch),在原有功能基础上包裹一层,例如对console.error进行重写,在使用方法不变的情况下也可以异常捕获
b、单点捕获
在业务代码中对单个代码块进行包裹,或在逻辑流程中打点,实现有针对性的异常捕获:
try…catch
专门写一个函数来收集异常信息,在异常发生时,调用该函数
专门写一个函数来包裹其他函数,得到一个新函数,该新函数运行结果和原函数一模一样,只是在发生异常时可以捕获异常
2.3跨域脚本异常
由于浏览器安全策略限制,跨域脚本报错时,无法直接获取错误的详细信息,只能得到一个ScriptError。
例如,我们会引入第三方依赖,或者将自己的脚本放在CDN时。
解决ScriptError的方法:
方案一:
将js内联到HTML中
将js文件与HTML放在同域下
方案二:
为页面上script标签添加crossorigin属性
被引入脚本所在服务端响应头中,增加Access-Control-Allow-Origin来支持跨域资源共享
2.4异常录制
对于一个异常,仅仅拥有该异常的信息还不足以完全抓住问题的本质,因为异常发生的位置,并不一定是异常根源所在的位置。
我们需要对异常现场进行还原,才能复原问题全貌,甚至避免类似问题在其他界面中发生。
这里需要引进一个概念,就是“异常录制”。
录制通过“时间”“空间”两个维度记录异常发生前到发生的整个过程,对于找到异常根源更有帮助。
上图表示,当异常发生时,异常的根源可能离我们很远,我们需要回到异常发生的现场,找到异常根源。
就像现实生活中破案一样,如果有监控摄影机对案发过程的录影,对破案来说更加容易。
如果仅仅关注异常本身,要找到异常的根源,需要凭借运气,但有了异常录制的帮助,找到根源就更加容易。
所谓的“异常录制”,实际上就是通过技术手段,收集用户的操作过程,对用户的每一个操作都进行记录,在发生异常时,把一定时间区间内的记录重新运行,形成影像进行播放,让调试者无需向用户询问,就能看到用户当时的操作过程。
上图是来自阿里的一套异常录制还原方案示意图,用户在界面上的操作产生的even
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 前端 异常 监控 解决方案 研究
![提示](https://static.bdocx.com/images/bang_tan.gif)