前端异常监控解决方案研究

摘要： 异常监控不复杂也不简单啊...

• 原文：前端异常监控解决方案研究
• 做者：frustigor

前端监控包括行为监控、异常监控、性能监控等，本文主要讨论异常监控。对于前端而言，和后端处于同一个监控系统中，前端有本身的监控方案，后端也有本身等监控方案，但二者并不分离，由于一个用户在操做应用过程当中若是出现异常，有多是前端引发，也有多是后端引发，须要有一个机制，将先后端串联起来，使监控自己统一于监控系统。所以，即便只讨论前端异常监控，其实也不能严格区分先后端界限，而要根据实际系统的设计，在最终的报表中体现出监控对开发和业务的帮助。

通常而言，一个监控系统，大体能够分为四个阶段：日志采集、日志存储、统计与分析、报告和警告。

采集阶段：收集异常日志，先在本地作必定的处理，采起必定的方案上报到服务器。

存储阶段：后端接收前端上报的异常日志，通过必定处理，按照必定的存储方案存储。

分析阶段：分为机器自动分析和人工分析。机器自动分析，经过预设的条件和算法，对存储的日志信息进行统计和筛选，发现问题，触发报警。人工分析，经过提供一个可视化的数据面板，让系统用户能够看到具体的日志数据，根据信息，发现异常问题根源。

报警阶段：分为告警和预警。告警按照必定的级别自动报警，经过设定的渠道，按照必定的触发规则进行。预警则在异常发生前，提早预判，给出警告。

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 跨域脚本异常

因为浏览器安全策略限制，跨域脚本报错时，没法直接获取错误的详细信息，只能获得一个Script Error。例如，咱们会引入第三方依赖，或者将本身的脚本放在CDN时。

解决Script Error的方法：

方案一：

• 将js内联到HTML中
• 将js文件与HTML放在同域下

方案二：

1. 为页面上script标签添加crossorigin属性
2. 被引入脚本所在服务端响应头中，增长 Access-Control-Allow-Origin 来支持跨域资源共享

2.4 异常录制

对于一个异常，仅仅拥有该异常的信息还不足以彻底抓住问题的本质，由于异常发生的位置，并不必定是异常根源所在的位置。咱们须要对异常现场进行还原，才能复原问题全貌，甚至避免相似问题在其余界面中发生。这里须要引进一个概念，就是“异常录制”。录制经过“时间”“空间”两个维度记录异常发生前到发生的整个过程，对于找到异常根源更有帮助。

上图表示，当异常发生时，异常的根源可能离咱们很远，咱们须要回到异常发生的现场，找到异常根源。就像现实生活中破案同样，若是有监控摄影机对案发过程的录影，对破案来讲更加容易。若是仅仅关注异常自己，要找到异常的根源，须要凭借运气，但有了异常录制的帮助，找到根源就更加容易。

所谓的“异常录制”，实际上就是经过技术手段，收集用户的操做过程，对用户的每个操做都进行记录，在发生异常时，把必定时间区间内的记录从新运行，造成影像进行播放，让调试者无需向用户询问，就能看到用户当时的操做过程。

上图是来自阿里的一套异常录制还原方案示意图，用户在界面上的操做产生的events和mutation被产品收集起来，上传到服务器，通过队列处理按顺序存放到数据库中。当须要进行异常重现的时候，将这些记录从数据库中取出，采用必定的技术方案，顺序播放这些记录，便可实现异常还原。

2.5 异常级别

通常而言，咱们会将收集信息的级别分为info，warn，error等，并在此基础上进行扩展。

当咱们监控到异常发生时，能够将该异常划分到“重要——紧急”模型中分为A、B、C、D四个等级。有些异常，虽然发生了，可是并不影响用户的正常使用，用户其实并无感知到，虽然理论上应该修复，可是实际上相对于其余异常而言，能够放在后面进行处理。

下文会讨论告警策略，通常而言，越靠近右上角的异常会越快通知，保证相关人员能最快接收到信息，并进行处理。A级异常须要快速响应，甚至须要相关负责人知悉。

在收集异常阶段，可根据第一节划分的异常后果来判断异常的严重程度，在发生异常时选择对应的上报方案进行上报。

3 整理与上报方案

前文已经提到，除了异常报错信息自己，咱们还须要记录用户操做日志，以实现场景复原。这就涉及到上报的量和频率问题。若是任何日志都当即上报，这无异于自造的DDOS攻击。所以，咱们须要合理的上报方案。下文会介绍4种上报方案，但实际咱们不会仅限于其中一种，而是常常同时使用，对不一样级别的日志选择不一样的上报方案。

3.1 前端存储日志

咱们前面提到，咱们并不仅仅采集异常自己日志，并且还会采集与异常相关的用户行为日志。单纯一条异常日志并不能帮助咱们快速定位问题根源，找到解决方案。但若是要收集用户的行为日志，又要采起必定的技巧，而不能用户每个操做后，就当即将该行为日志传到服务器，对于具备大量用户同时在线的应用，若是用户一操做就当即上传日志，无异于对日志服务器进行DDOS攻击。所以，咱们先将这些日志存储在用户客户端本地，达到必定条件以后，再同时打包上传一组日志。

那么，如何进行前端日志存储呢？咱们不可能直接将这些日志用一个变量保存起来，这样会挤爆内存，并且一旦用户进行刷新操做，这些日志就丢失了，所以，咱们天然而然想到前端数据持久化方案。

目前，可用的持久化方案可选项也比较多了，主要有：Cookie、localStorage、sessionStorage、IndexedDB、webSQL 、FileSystem 等等。那么该如何选择呢？咱们经过一个表来进行对比：

存储方式	cookie	localStorage	sessionStorage	IndexedDB	webSQL	FileSystem
类型		key-value	key-value	NoSQL	SQL
数据格式	string	string	string	object
容量	4k	5M	5M	500M	60M
进程	同步	同步	同步	异步	异步
检索		key	key	key, index	field
性能		读快写慢		读慢写快

综合以后，IndexedDB是最好的选择，它具备容量大、异步的优点，异步的特性保证它不会对界面的渲染产生阻塞。并且IndexedDB是分库的，每一个库又分store，还能按照索引进行查询，具备完整的数据库管理思惟，比localStorage更适合作结构化数据管理。可是它有一个缺点，就是api很是复杂，不像localStorage那么简单直接。针对这一点，咱们可使用hello-indexeddb这个工具，它用Promise对复杂api进行来封装，简化操做，使IndexedDB的使用也能作到localStorage同样便捷。另外，IndexedDB是被普遍支持的HTML5标准，兼容大部分浏览器，所以不用担忧它的发展前景。

接下来，咱们究竟应该怎么合理使用IndexedDB，保证咱们前端存储的合理性呢？

上图展现了前端存储日志的流程和数据库布局。当一个事件、变更、异常被捕获以后，造成一条初始日志，被当即放入暂存区（indexedDB的一个store），以后主程序就结束了收集过程，后续的事只在webworker中发生。在一个webworker中，一个循环任务不断从暂存区中取出日志，对日志进行分类，将分类结果存储到索引区中，并对日志记录的信息进行丰富，将最终将会上报到服务端的日志记录转存到归档区。而当一条日志在归档区中存在的时间超过必定天数以后，它就已经没有价值了，可是为了防止特殊状况，它被转存到回收区，再经历一段时间后，就会被从回收区中清除。

3.2 前端整理日志

上文讲到，在一个webworker中对日志进行整理后存到索引区和归档区，那么这个整理过程是怎样的呢？

因为咱们下文要讲的上报，是按照索引进行的，所以，咱们在前端的日志整理工做，主要就是根据日志特征，整理出不一样的索引。咱们在收集日志时，会给每一条日志打上一个type，以此进行分类，并建立索引，同时经过object-hashcode计算每一个log对象的hash值，做为这个log的惟一标志。

• 将全部日志记录按时序存放在归档区，并将新入库的日志加入索引
• BatchIndexes：批量上报索引（包含性能等其余日志），可一次批量上报100条
• MomentIndexes：即时上报索引，一次所有上报
• FeedbackIndexes：用户反馈索引，一次上报一条
• BlockIndexes：区块上报索引，按异常/错误（traceId，requestId）分块，一次上报一块
• 上报完成后，被上报过的日志对应的索引删除
• 3天以上日志进入回收区
• 7天以上的日志从回收区清除

rquestId：同时追踪先后端日志。因为后端也会记录本身的日志，所以，在前端请求api的时候，默认带上requestId，后端记录的日志就能够和前端日志对应起来。

traceId：追踪一个异常发生先后的相关日志。当应用启动时，建立一个traceId，直到一个异常发生时，刷新traceId。把一个traceId相关的requestId收集起来，把这些requestId相关的日志组合起来，就是最终这个异常相关的全部日志，用来对异常进行复盘。

上图举例展现了如何利用traceId和requestId找出和一个异常相关的全部日志。在上图中，hash4是一条异常日志，咱们找到hash4对应的traceId为traceId2，在日志列表中，有两条记录具备该traceId，可是hash3这条记录并非一个动做的开始，由于hash3对应的requestId为reqId2，而reqId2开始于hash2，所以，咱们实际上要把hash2也加入到该异常发生的整个复盘备选记录中。总结起来就是，咱们要找出同一个traceId对应的全部requestId对应的日志记录，虽然有点绕，但稍理解就能够明白其中的道理。

咱们把这些和一个异常相关的全部日志集合起来，称为一个block，再利用日志的hash集合，得出这个block的hash，并在索引区中创建索引，等待上报。

3.3 上报日志

上报日志也在webworker中进行，为了和整理区分，能够分两个worker。上报的流程大体为：在每个循环中，从索引区取出对应条数的索引，经过索引中的hash，到归档区取出完整的日志记录，再上传到服务器。

按照上报的频率（重要紧急度）可将上报分为四种：

a. 即时上报

收集到日志后，当即触发上报函数。仅用于A类异常。并且因为受到网络不肯定因素影响，A类日志上报须要有一个确认机制，只有确认服务端已经成功接收到该上报信息以后，才算完成。不然须要有一个循环机制，确保上报成功。

b. 批量上报

将收集到的日志存储在本地，当收集到必定数量以后再打包一次性上报，或者按照必定的频率（时间间隔）打包上传。这至关于把屡次合并为一次上报，以下降对服务器的压力。

c. 区块上报

将一次异常的场景打包为一个区块后进行上报。它和批量上报不一样，批量上报保证了日志的完整性，全面性，但会有无用信息。而区块上报则是针对异常自己的，确保单个异常相关的日志被所有上报。

d. 用户主动提交

在界面上提供一个按钮，用户主动反馈bug。这有利于增强与用户的互动。

或者当异常发生时，虽然对用户没有任何影响，可是应用监控到了，弹出一个提示框，让用户选择是否愿意上传日志。这种方案适合涉及用户隐私数据时。

	即时上报	批量上报	区块上报	用户反馈
时效	当即	定时	稍延时	延时
条数	一次所有上报	一次100条	单次上报相关条目	一次1条
容量	小	中	–	–
紧急	紧急重要	不紧急	不紧急但重要	不紧急

即时上报虽然叫即时，可是其实也是经过相似队列的循环任务去完成的，它主要是尽快把一些重要的异常提交给监控系统，好让运维人员发现问题，所以，它对应的紧急程度比较高。

批量上报和区块上报的区别：批量上报是一次上报必定条数，好比每2分钟上报1000条，直到上报完成。而区块上报是在异常发生以后，立刻收集和异常相关的全部日志，查询出哪些日志已经由批量上报上报过了，剔除掉，把其余相关日志上传，和异常相关的这些日志相对而言更重要一些，它们能够帮助尽快复原异常现场，找出发生异常的根源。

用户提交的反馈信息，则能够慢悠悠上报上去。

为了确保上报是成功的，在上报时须要有一个确认机制，因为在服务端接收到上报日志以后，并不会当即存入数据库，而是放到一个队列中，所以，先后端在确保日志确实已经记录进数据库这一点上须要再作一些处理。

上图展现了上报的一个大体流程，在上报时，先经过hash查询，让客户端知道准备要上报的日志集合中，是否存在已经被服务端保存好的日志，若是已经存在，就将这些日志去除，避免重复上报，浪费流量。

3.4 压缩上报数据

一次性上传批量数据时，必然遇到数据量大，浪费流量，或者传输慢等状况，网络很差的状态下，可能致使上报失败。所以，在上报以前进行数据压缩也是一种方案。

对于合并上报这种状况，一次的数据量可能要十几k，对于日 pv 大的站点来讲，产生的流量仍是很可观的。因此有必要对数据进行压缩上报。lz-string是一个很是优秀的字符串压缩类库，兼容性好，代码量少，压缩比高，压缩时间短，压缩率达到惊人的60%。但它基于LZ78压缩，若是后端不支持解压，可选择gzip压缩，通常而言后端会默认预装gzip，所以，选择gzip压缩数据也能够，工具包pako中自带了gzip压缩，能够尝试使用。

4 日志接收与存储

4.1 接入层与消息队列

通常经过提供独立的日志服务器接收客户端日志，接收过程当中，要对客户端日志内容的合法性、安全性等进行甄别，防止被人攻击。并且因为日志提交通常都比较频繁，多客户端同时并发的状况也常见。经过消息队列将日志信息逐一处理后写入到数据库进行保存也是比较经常使用的方案。

上图为腾讯BetterJS的架构图，其中“接入层”和“推送中心”就是这里提到的接入层和消息队列。BetterJS将整个前端监控的各个模块进行拆分，推送中心承担了将日志推送到存储中心进行存储和推送给其余系统（例如告警系统）的角色，但咱们能够把接收日志阶段的队列独立出来看，在接入层和存储层之间作一个过渡。

4.2 日志存储系统

存储日志是一个脏活累活，可是不得不作。对于小应用，单库单表加优化就能够应付。一个成规模的应用，若是要提供更标准高效的日志监控服务，经常须要在日志存储架构上下一些功夫。目前业界已经有比较完备的日志存储方案，主要有：Hbase系，Dremel系，Lucene系等。整体而言，日志存储系统主要面对的问题是数据量大，数据结构不规律，写入并发高，查询需求大等。通常一套日志存储系统，要解决上面这些问题，就要解决写入的缓冲，存储介质按日志时间选择，为方便快速读取而设计合理的索引系统等等。

因为日志存储系统方案比较成熟，这里就再也不作更多讨论。

4.3 搜索

日志的最终目的是要使用，因为通常日志的体量都很是大，所以，要在庞大的数据中找到须要的日志记录，须要依赖比较好的搜索引擎。Splunk是一套成熟的日志存储系统，但它是付费使用的。按照Splunk的框架，Elk是Splunk的开源实现，Elk是ElasticSearch、Logstash、Kibana的结合，ES基于Lucene的存储、索引的搜索引擎；logstash是提供输入输出及转化处理插件的日志标准化管道；Kibana提供可视化和查询统计的用户界面。

5 日志统计与分析

一个完善的日志统计分析工具须要提供各方面方便的面板，以可视化的方式给日志管理员和开发者反馈信息。

5.1 用户纬度

同一个用户的不一样请求实际上会造成不一样的story线，所以，针对用户的一系列操做设计惟一的request id是有必要的。同一个用户在不一样终端进行操做时，也能进行区分。用户在进行某个操做时的状态、权限等信息，也须要在日志系统中予以反应。

5.2 时间维度

一个异常是怎么发生的，须要将异常操做的先后story线串联起来观察。它不仅仅涉及一个用户的一次操做，甚至不限于某一个页面，而是一连串事件的最终结果。

5.3 性能维度

应用运行过程当中的性能状况，例如，界面加载时间，api请求时长统计，单元计算的消耗，用户呆滞时间。

5.4 运行环境维度

应用及服务所运行的环境状况，例如应用所在的网络环境，操做系统，设备硬件信息等，服务器cpu、内存情况，网络、宽带使用状况等。

5.5 细粒度代码追踪

异常的代码stack信息，定位到发生异常的代码位置和异常堆栈。

5.6 场景回溯

经过将异常相关的用户日志链接起来，以动态的效果输出发生异常的过程。

6 监控与通知

对异常进行统计和分析只是基础，而在发现异常时能够推送和告警，甚至作到自动处理，才是一个异常监控系统应该具有的能力。

6.1 自定义触发条件的告警

a. 监控实现

当日志信息进入接入层时，就能够触发监控逻辑。当日志信息中存在较为高级别的异常时，也能够当即出发告警。告警消息队列和日志入库队列能够分开来管理，实现并行。

对入库日志信息进行统计，对异常信息进行告警。对监控异常进行响应。所谓监控异常，是指：有规律的异常通常而言都比较让人放心，比较麻烦的是忽然之间的异常。例如在某一时段忽然频繁接收到D级异常，虽然D级异常是不紧急通常重要，可是当监控自己发生异常时，就要提升警戒。

b. 自定义触发条件

除了系统开发时配置的默认告警条件，还应该提供给日志管理员可配置的自定义触发条件。

• 日志内含有什么内容时
• 日志统计达到什么度、量时
• 向符合什么条件的用户告警

6.2 推送渠道

可选择的途径有不少，例如邮件、短信、微信、电话。

6.3 推送频率

针对不一样级别的告警，推送的频率也能够进行设定。低风险告警能够以报告的形式一天推送一次，高风险告警10分钟循环推送，直处处理人手动关闭告警开关。

6.4 自动报表

对于日志统计信息的推送，能够作到自动生成日报、周报、月报、年报并邮件发送给相关群组。

6.5 自动产生bug工单

当异常发生时，系统能够调用工单系统API实现自动生成bug单，工单关闭后反馈给监控系统，造成对异常处理的追踪信息进行记录，在报告中予以展现。

7 修复异常

7.1 sourcemap

前端代码大部分状况都是通过压缩后发布的，上报的stack信息须要还原为源码信息，才能快速定位源码进行修改。

发布时，只部署js脚本到服务器上，将sourcemap文件上传到监控系统，在监控系统中展现stack信息时，利用sourcemap文件对stack信息进行解码，获得源码中的具体信息。

可是这里有一个问题，就是sourcemap必须和正式环境的版本对应，还必须和git中的某个commit节点对应，这样才能保证在查异常的时候能够正确利用stack信息，找到出问题所在版本的代码。这些能够经过创建CI任务，在集成化部署中增长一个部署流程，以实现这一环节。

7.2 从告警到预警

预警的本质是，预设可能出现异常的条件，当触发该条件时异常并无真实发生，所以，能够赶在异常发生以前对用户行为进行检查，及时修复，避免异常或异常扩大。

怎么作呢？其实就是一个统计聚类的过程。将历史中发生异常的状况进行统计，从时间、地域、用户等不一样维度加以统计，找出规律，并将这些规律经过算法自动加入到预警条件中，当下次触发时，及时预警。

7.3 智能修复

自动修复错误。例如，前端要求接口返回数值，但接口返回了数值型的字符串，那么能够有一种机制，监控系统发送正确数据类型模型给后端，后端在返回数据时，根据该模型控制每一个字段的类型。

8 异常测试

8.1 主动异常测试

撰写异经常使用例，在自动化测试系统中，加入异常测试用户。在测试或运行过程当中，每发现一个异常，就将它加入到原有的异经常使用例列表中。

8.2 随机异常测试

模拟真实环境，在模拟器中模拟真实用户的随机操做，利用自动化脚本产生随机操做动做代码，并执行。

定义异常，例如弹出某个弹出框，包含特定内容时，就是异常。将这些测试结果记录下来，再聚类统计分析，对防护异常也颇有帮助。

9 部署

9.1 多客户端

一个用户在不一样终端上登陆，或者一个用户在登陆前和登陆后的状态。经过特定算法生成requestID，经过该requestId能够肯定某个用户在独立客户端上的一系列操做，根据日志时序，能够梳理出用户产生异常的具体路径。

9.2 集成便捷性

前端写成包，全局引用便可完成大部分日志记录、存储和上报。在特殊逻辑里面，能够调用特定方法记录日志。

后端与应用自己的业务代码解耦，能够作成独立的服务，经过接口和第三方应用交互。利用集成部署，能够将系统随时进行扩容、移植等操做。

9.3 管理系统的可扩展

整套系统可扩展，不只服务单应用，可支持多个应用同时运行。同一个团队下的全部应用均可以利用同一个平台进行管理。

9.4 日志系统权限

不一样的人在访问日志系统时权限不一样，一个访问者只能查看本身相关的应用，有些统计数据若是比较敏感，能够单独设置权限，敏感数据可脱敏。

10 其余

10.1 性能监控

异常监控主要针对代码级别的报错，但也应该关注性能异常。性能监控主要包括：

• 运行时性能：文件级、模块级、函数级、算法级
• 网络请求速率
• 系统性能

10.2 API Monitor

后端API对前端的影响也很是大，虽然前端代码也控制逻辑，可是后端返回的数据是基础，所以对API的监控能够分为：

• 稳定性监控
• 数据格式和类型
• 报错监控
• 数据准确性监控

10.3 数据脱敏

敏感数据不被日志系统采集。因为日志系统的保存是比较开放的，虽然里面的数据很重要，可是在存储上大部分日志系统都不是保密级，所以，若是应用涉及了敏感数据，最好作到：

• 独立部署，不和其余应用共享监控系统
• 不采集具体数据，只采集用户操做数据，在重现时，经过日志信息能够取出数据api结果来展现
• 日志加密，作到软硬件层面的加密防御
• 必要时，可采集具体数据的ID用于调试，场景重现时，用mock数据替代，mock数据可由后端采用假的数据源生成
• 对敏感数据进行混淆

结语

本文主要是对前端异常监控的总体框架进行了研究，没有涉及到具体的技术实现，涉及前端部分和后台部分以及与整个问题相关的一些知识点，主要关注前端部分，它和后端的监控有重叠部分也有分支部分，须要在一个项目中不断实践，总结出项目自己的监控需求和策略。

感谢你的阅读，本文出自 Tencent CDC，转载时请注明出处，谢谢合做。 格式为：Tencent CDC（https://cdc.tencent.com/2018/09/13/frontend-exception-monitor-research/）

关于Fundebug

Fundebug专一于JavaScript、微信小程序、微信小游戏、支付宝小程序、React Native、Node.js和Java线上应用实时BUG监控。 自从2016年双十一正式上线，Fundebug累计处理了20亿+错误事件，付费客户有阳光保险、核桃编程、荔枝FM、掌门1对一、微脉、青团社等众多品牌企业。欢迎你们免费试用！