导读：随着业务快速迭代发展，系统对业务的监控、优化不再局限于行为、性能监控。前端异常监控更能反应用户端的真实体验。精细化的监控可以及时主动发现问题减少损失，针对性的分析治理甚至能带来业务增益。本文结合广告托管团队异常监控治理的经验，介绍从异常打点收集、报警监控、排查分析、治理优化的实战总结。

全文8455字，预计阅读时间19分钟。

一、前言

1.1 业务背景介绍

• 对于网民来说我们要保障流畅的阅读、交互体验。
• 对于广告主来说，我们要提供高质量保障。

1.1.1 要解决什么问题

• 页面整体或某些部分渲染异常，影响体验甚至广告转化和成本。可能造成的原因举例：
• 静态资源加载异常，包含script资源、图片素材等
• API访问异常
• JS执行异常

• 小流量场景提前发现问题

说明：本文更多从业务应用视角讨论问题，对于通用的埋点接受服务、数据处理、展示平台不做太多探讨，所幸团队已经有这样的专业人员和平台。结合我们的业务场景需求，和平台共同设计并支持了通用监控之外的业务异常监控，后面会介绍。

二、异常收集

2.1 通用异常收集

• 由于网络请求导致的资源加载型异常，比如图片加载失败、script链接加载失败
• 由于运行时导致的异常，这类异常多数是由于一些代码的兼容性或者未考虑到的边界情况产生的

1. 使用资源自身的 onerror 事件，在资源加载失败时将错误上报出去。这种场景一般需要借助打包工具，在代码打包时，针对相关的资源添加onerror 的逻辑，例如使用 script-ext-html-webpack-plugin 针对所有script 标签添加 onerror 属性。
2. 利用：

window.addEventListener('error', fn, true)
进行捕获。这种方式的好处是，无需在每一个资源中进行错误的处理。但需要注意的一点是由于网络请求异常不会事件冒泡，因此必须在捕获阶段将其捕获到才行。

window.onerror 或 window.addEventListener('error', fn)

window.addEventListener('unhandledrejection', fn)

Error boundaries do not catch errors for:

• Event handlers 
• Asynchronous code (e.g. e.g. setTimeout or requestAnimationFrame callbacks)
• Server side rendering
• Errors thrown in the error boundary itself (rather than its children)

Vue.config.errorHandler = (err, vm, info) => {}

从 2.2.0 起，这个钩子也会捕获组件生命周期钩子里的错误。同样的，当这个钩子是 undefined 时，被捕获的错误会通过 console.error 输出而避免应用崩溃。

从 2.4.0 起，这个钩子也会捕获 Vue 自定义事件处理函数内部的错误了。

从 2.6.0 起，这个钩子也会捕获 v-on DOM 监听器内部抛出的错误。另外，如果任何被覆盖的钩子或处理函数返回一个 Promise 链 (例如 async 函数)，则来自其 Promise 链的错误也会被处理。

2.2 业务异常收集

2.2.1 如何定义业务异常

• 无法直接从底层捕获到

虽然控制台中你看不到飘红的报错，但从业务角度来看有些问题仍需关注。

如：APP 下载业务中，客户需要在页面中绑定渠道下载包，再用页面进行广告投放。有时候客户操作失误，将安卓下载包投放到了 iOS 中，这种情况在页面渲染阶段不会有什么异常，但明显对广告转化是不利的，从业务视角需要被发现解决。

• 一些异常堆栈信息不充分

我们需要获取一些运行时的数据，来辅佐后续问题的定位和分析。比如当前访问的账户 id ，当时应用状态中的某些关键业务数据等。

如：某次业务中发现大量的 "onAndroidBack is not defined" 的异常，通过异常信息中携带的产品线 id ，快速定位到产生异常的产品线，和开发同学沟通后，定位到了问题代码进而进行业务兼容。

• 分析成本高，报警时效低

如果你有过实践，会发现异常数据的分析、统计工作并不轻松，尤其是在非常通用的异常堆栈中找到更精准的问题，及时报警、排查、止损。业务异常能让我们在异常发生时，更加直观地定位根因。我们并不是想在分析阶段偷懒，而是让数据服务的计算逻辑更加简单直接，这样大数据处理时效更高，报警后人工分析修复问题也更高效。

2.3 异常收集协议

{    exception: // 储存异常堆栈相关信息    request：// 储存当前页面相关的信息    meta: {        xxx: // 业务相关字段        extra：{            // 开发者可自行扩展的字段        }    }}

• 业务中用于归因分析的 id 字段
• 以 extra 字段为代表的辅助进行信息排查的字段

window.addEventListener('error', error => {    logSdk.addWindowErrorLog(error)},true)
// 借助vue 框架的能力，将运行时的js 异常进行上报Vue.config.errorHandler = (err, vm, info) => {    logSdk.addCustomErrorLog({        errorKey: xx, // 框架收集到的异常，会有一个默认确定的errorKey。        error: err,        userExtra: {            message: info        }    });};

try {    xxx 业务逻辑} catch(e) {    logSdk.addCustomErrorLog({        errorKey: 'xxx', // 具体的业务类型        error: e,        userExtra: {            // 业务自定义扩展字段。对应传输协议中的extra。        }    })}

三、完善监控报警

3.1 圈定监控项

3.2 制定报警策略

• 聚合周期

• 触发机制

• 报警接收组

3.3 挑战

• 排除爬虫流量（通过ua）
• 只看商业流量（通过商业投放参数判断）
• 逐步完善的异常黑名单（已知的无法解决的异常，比如外部注入导致的 "Script error" 等异常）

业务线 = xxx && 错误类型 = js异常

业务线 = xxx&& 错误类型 = js异常&& 商业流量标志 != '' // 排除掉非商业流量&& ua not like '爬虫ua' // 排除掉爬虫流量&& error_message not like 'Script error' // 排除掉黑名单中的异常

1. 同环比的设置不应该在一开始设置的，应该观察一段时间再设置。比如，同比昨天的数据，这个阈值的设置应该在至少积累2天数据后再设置，以实际每天数据的波动情况来进行合理的阈值百分比设置。
2. 同比环比的设置不应一成不变的，应该隔一段时间更新一次。随着业务的发展，线上的异常请求是不断变化的，如果发现一段时间内的报警变多了，而排查后发现大部分是无效的报警，这个时候，你就需要重新考虑你的报警设置的是否合理了。

四、异常排查

• 善用聚合

• 完善基础能力的支持

五、异常治理

• JS 执行异常
• API 异常
• 图片资源加载异常
• SCRIPT 资源加载异常

• 由于托管落地页运行的场景不一，为排除一些测试数据或者网络爬虫数据的影响，在数据的筛选时只看来自商业流量的错误。
• 线上已知的一些由于端上注入导致的一些不影响前端稳定性的异常错误信息，建立错误信息的黑名单，通过具体的错误信息，排除此类错误的干扰。

1. 给出基准时间段
2. 计算出基准时间范围内每天不同产品线的单次广告点击图片/ SCRIPT 加载失败数以及 API 请求失败数，并给出80分位值
3. 以基准时间内最小的一个80分位值作为优化的目标。（可基于业务自行调整）

核心思路：此类异常都是由于网络原因导致的，不同产品线之间的值应该趋于一致。基于此，取80分位值作为优化的基准线，没有达到这个基准线的产品线除了网络因素外一定存在其他的问题，可以推动这些产品线向这个统一的标准对齐。（为了避免某一天的数据过于极端，可以考虑取平均值或者去除突刺数据后取最小值来得到最后的目标值）

1. 给出基准时间段
2. 按照 errorKey，errorMessage 进行聚合并按照从大到小排序。在结果中找出是由于托管页自身的 JS 执行时导致的异常。这些异常是预期可以被优化到0的异常。排除掉这些得到的最终值再除以落地页的流量得到一天的单次广告点击 JS 执行异常的数据。
3. 以基准时间内最小的一个值作为优化的目标。（可基于业务自行调整）

1. 改用 CDN 链接或减少资源大小可降低第一次加载失败率
1. 图片使用 CDN 链接
2. 图片进行合理压缩或使用更高压缩比的图片格式（如webp等）
2. 重试可以降低最终资源加载失败率

1. 从通用的异常监控中发现业务可优化异常；
2. 通过细化具体的监控条件，针对该业务异常建立单独的监控；
3. 上线优化方案，处理该类异常；
4. 观察监控数据下降是否符合预期。

六、后记