导读：随着业务疾速迭代倒退，系统对业务的监控、优化不再局限于行为、性能监控。前端异样监控更能反馈用户端的实在体验。精细化的监控能够及时被动发现问题缩小损失，针对性的剖析治理甚至能带来业务增益。本文联合广告托管团队异样监控治理的教训，介绍从异样打点收集、报警监控、排查剖析、治理优化的实战总结。

全文 8455 字，预计浏览工夫 19 分钟。

一、前言

行为、性能、异样打点是前端畛域的陈词滥调，实际层面很多团队对这些打点的利用范畴也是：行为 > 性能 > 异样。这不难理解，行为统计从团队收益角度来看，短期内更加直观，甚至有一些打点自身就是业务需要，如性能上线后的 PV、UV 统计等。

个别对于线上服务来说，后端异样监控是必须项，服务异样的被动发现也多从后端来，前端的异样监控能表演什么样的角色呢？退出这样的投入从管理者角度来看是划算的吗？异样怎么监控能更快的发现并疏导止损？面对这些问题，很多业务的前端异样监控工作，还没开始就完结了。

咱们团队在实践中总结了一些思考和教训，心愿能对读者有一点帮忙。

1.1 业务背景介绍

咱们是百度广告托管业务，承接着泛滥行业的站点建设工作。这其中蕴含挪动 / 桌面端的 web 站点、小程序、HN（百度 App 的类 ReactNative 计划）等多种载体，每天有大量的拜访流量。

• 对于网民来说咱们要保障晦涩的浏览、交互体验。
• 对于广告主来说，咱们要提供高质量保障。

通过前端异样监控与治理，业务团队播种了提前发现问题、及时止损，优化广告成果等诸多收益。

1.1.1 要解决什么问题

如文章一开始介绍，业务倒退的相当一段时间内，团队的重心始终在后端的监控和报警欠缺上。但当咱们将服务的稳定性治理达到肯定的规范后，发现一些线上问题依然难以召回，例如

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

相较后端异样监控，资源加载、JS 执行异样都是前端异样监控带来的增量场景，端到端的接口稳定性更靠近用户的实在感知，更能表明网络对稳定性带来的影响。

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

产品的公布往往须要小流量、AB 测试的验证。或者某些问题仅在一些特定场景下触发，因为流量限度，很难通过服务数据稳定发现，随着扩量造成更大负向影响或客户投诉后才被发现。

前端异样监控能很好地帮忙咱们解决这些场景的问题。上面将从 异样收集 、 欠缺监控报警 、 异样排查 、 异样治理 几个阶段，介绍咱们的次要工作和教训。

阐明：本文更多从业务利用视角探讨问题，对于通用的埋点承受服务、数据处理、展现平台不做太多探讨，所幸团队曾经有这样的业余人员和平台。联合咱们的业务场景需要，和平台独特设计并反对了 通用监控 之外的 业务异样监控，前面会介绍。

===

二、异样收集

第一步，咱们要把异常情况，以打点的模式发送至收集服务。这蕴含很多文章提到的通过 window 监听捕捉到的 error 等通用计划，还有一些更加荫蔽，但对业务有很大影响的业务异样。

2.1 通用异样收集

通用异样收集是一种无侵入的异样收集形式，无需业务开发者被动表白，在零碎产生异样时，通过事件的冒泡、事件捕捉或者一些框架提供的 hook 函数来进行谬误的收集。

针对页面中异样进行收集时，次要会波及两类场景:

• 因为网络申请导致的资源加载型异样，比方图片加载失败、script 链接加载失败
• 因为运行时导致的异样，这类异样少数是因为一些代码的兼容性或者未思考到的边界状况产生的

针对资源加载异样，业务中会有以下两种监控形式：

1. 应用资源本身的 onerror 事件，在资源加载失败时将谬误上报进来。这种场景个别须要借助打包工具，在代码打包时，针对相干的资源增加 onerror 的逻辑，例如应用 script-ext-html-webpack-plugin 针对所有 script 标签增加 onerror 属性。
2. 利用：

window.addEventListener('error', fn, true)

针对运行时产生的异样, 通常咱们应用以下形式进行监控：

页面顶层增加如下事件：

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

但这种解决形式也有其局限性，针对未 catch 住的 promise 产生的异样无奈进行捕捉，所以在业务应用时，个别是额定再增加一个事件监听办法来捕捉未被解决的 promise 异样。

window.addEventListener('unhandledrejection', fn)

针对运行时产生的异样，一些前端框架也给咱们提供了配置办法来简化咱们的日常开发。

React 框架：

在 React 16 之后，框架反对 componentDidCatch 用于对 render 时异样进行捕捉。但在应用时须要留神，参见 error boundary

(https://reactjs.org/docs/erro…)

Error boundaries do not catch errors for:

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

Vue 框架：

Vue 框架也提供了相似全局的谬误配置。上面办法能够指定组件的渲染和察看期间未捕捉谬误的处理函数。

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 链的谬误也会被解决。

留神：

在捕捉到的异样中，常常会看到错误信息为 “Script error” 的异样。该类异样产生的场景是网站申请并执行一个跨域脚本，如果该脚本报错，在全局监听异样的办法中，就会捕捉到错误信息为 “Script error” 的异样。因为浏览器的平安限度，这里并未展现出具体的报错信息，这对排查问题是非常不敌对的。目前的我的项目打包之后的资源文件大多会独自部署到 CDN 服务上，资源的援用域名为 CDN 域名，与页面运行的域名不统一。

常见的解决形式为应用打包工具，在 script 链接上增加：

crossorigin(https://developer.mozilla.org…)属性，同时要在资源的返回头中增加 access-control-allow-origin: yourorigin.com。这样，通过 CDN 地址引入的 JS 在运行报错时，基于全局的谬误监听办法就能够获取到残缺的错误信息了。

2.2 业务异样收集

2.2.1 如何定义业务异样

在通用的异样收集根底上，零碎减少了业务自定义异样的打点。它是一种“有埋点”的开发方式（绝对下层开发者不感知的“无埋点”形式来说）。开发者在程序中显式收回数据点，并常随同一些过后的运行数据。

为什么要减少这种形式？规范形式采集到的异样数据信息量无限，大多是异样堆栈等。但仍有一些场景不能很好满足：

• 无奈间接从底层捕捉到

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

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

• 一些异样堆栈信息不充沛

咱们须要获取一些运行时的数据，来辅助后续问题的定位和剖析。比方以后拜访的账户 id，过后利用状态中的某些要害业务数据等。

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

• 剖析老本高，报警时效低

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

2.3 异样收集协定

为了可能反对 通用异样 和业务自定义异样，须要设计对立的传输、存储数据协定。

传输和存储协定的设计：

传输协定的的设计须要遵循以下准则：顶层 schema 稳固，业务信息可扩大。除此之外，上游数据处理模块可能疾速对接也是其设计时须要重点思考的一个因素，于是咱们对整体的数据传输协定格局进行了以下的定义：

一级 key 连续通用的数据处理模块反对的数据结构，比拟重要的有以下几个字段。其中 meta 字段为广告托管业务中一些通用的数据字段。并且对 meta 中的 extra 字段进行了二次凋谢，通过埋点 sdk 对外裸露的 api，开发者能够将一些其余的业务数据一起上传，以辅助前期异样的排查。

{exception: // 贮存异样堆栈相干信息    request：// 贮存以后页面相干的信息    meta: {        xxx: // 业务相干字段        extra：{            // 开发者可自行扩大的字段}    }}

上述的设计在满足稳定性，齐备性的前提下，又反对业务的灵便扩大。

这里或者大家会有疑难，为什么 extra 的字段不能打平放在 meta 中？

之所以这样设计，和底层的表构造索引的建设以及上游数据处理的复杂度非亲非故。放在 meta 中的业务相干字段是托管页的通用字段，为了不便后续的查问，在数据库中是以列的模式存在，须要提前枚举出，为了定义这些一级 key，对整体业务进行梳理。最终定义在一级 key 中的字段特色为：

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

寄存在 meta 一级 key 中的数据降级老本较高，须要上下游都了解其业务含意后对立降级。为了不便业务方进行信息的灵便扩大，在 meta 中增加 extra 字段，并将该字段以字符串模式存储到数据库中。数据库存储应用了百度自研的 BaikalDB(https://github.com/baidu/Baik…)，对这类结构化信息的实时存储和读取有很好的反对。

为了能实现通用异样和自定义异样的上报，咱们对异样捕捉进行了分级。

通用异样 应用上面的形式进行上报：

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。}    })}

在页面关上时，通过传入业务 meta 信息对埋点 sdk 进行实例化。当产生异样时，如果业务方进行了捕捉，则由业务方自行结构谬误参数，调用 API 进行上报。未被业务捕捉到的异样，将通过框架的对立异样解决逻辑进行上报。同时，注册全局的 error 事件处理办法，针对一些资源加载异样，以及一些其余的异样进行捕捉。

这样层层嵌套的模式，即实现了业务方自定义异样的诉求，又能够对未被业务方捕捉的异样进行对立收集上报。

在异样日志存储入库前须要对数据进行预处理，这里借助了公司内流式计算平台的能力，针对每条日志数据进行实时 ETL 解决，最终将 meta 中的数据以及在 nginx 层获取到的一些数据实时存储到数据库中。

这样从传输协定的通用性到存储查问的高效性综合思考后，最终失去了一个存储线上异样日志的表，这个存储异样数据的表构造列十分之多，是一个很大的“宽表”，这个“宽表”为前面的数据聚合报警提供数据反对。

三、欠缺监控报警

大量的数据要想产生精确高效报警，须要通过下图的流程：基于打点的元数据，创立监控项；基于监控项的统计，设定报警策略。

3.1 圈定监控项

如前所述，监控平台将异样收集并造成一个大宽表，基于宽表，多个聚合项的条件剖析，能够满足绝大多数的监控项诉求。

监控项：对某列数据的过滤，如 URL 蕴含某个 query，业务类型属于某个范畴。平台上反对了如下图的多种过滤条件(反对正则）。

监控聚合：多个监控项的交加。如(业务线 === XXX) && (申请状态码 === 500)。

3.2 制订报警策略

报警策略有三大关键因素：聚合周期、报警接管组、触发机制。

• 聚合周期

监控项是一种统计规定，聚合周期是对规定统计的窗口。依据数据量、重要性等设定正当的聚合周期。如对于最高优的、稳定敏感的广告转化相干异样设定 30 秒的准实时报警；反之能够适当加大窗口。防止稳定较大的监控项频繁误报。

• 触发机制

触发有阈值和稳定两种形式。针对比拟安稳的异样数能够设定阈值，例如分日看某些业务指标根本持平；针对有稳定的异样，能够通过昨日、上周、两周前来比照，例如用户访问量在一天内成肯定法则稳定，异样量会追随稳定变动。

如下图稳定较大，没有显著的工夫法则，适宜用阈值：

如下图异样数量有工夫法则，能够设定 稳定报警。

在实际过程中，咱们经常并行不悖，均衡报警的准招率是一个很不简单的事件。咱们也会一边察看、治理，一边调参。更多的一些挑战和计划，会在前面提到。

• 报警接管组

通过邮件、即时通信音讯、短信等形式保障报警触达。最重要的教训是，报警接管人永远不要 单点依赖！

3.3 挑战

后面提到，异样监控报警的准招重要且有很大挑战。个别 Server 服务会有网关，运行环境稳固，而前端代码运行的环境会更加不可控，对欠缺监控都是很大挑战。

挑战 1: 如何建设齐备的监控？

异样都上报之后，必须针对每类异样都可能感知，失常来说，依照异样的类型（资源加载异样、API 异样、JS 执行异样）来分类，针对每一类异样建设监控，即可满足齐备性的要求。

然而在实践中发现，这种设置不适宜托管页。文章结尾提到，托管页的业务场景笼罩不同的端。不同端之前的流量差别微小，不同端之间复用同一个异样监控项，流量小的端产生的谬误很容易被吞没在整体异样中。因而，从托管业务登程，将异样划分为两个维度：异样类型和异样所在的端。

两个维度进行组合进行建设的监控项既能够满足齐备性的要求，又能够及时的发现不同端之间产生的问题。

挑战 2: 如何进步报警的精准度？

托管页的报警是基于各种条件进行实时的聚合，而后与预设的阈值进行比照来判断是否触发了报警。实践上来讲，报警的准确度取决于业务方，只有聚合的条件足够精准，报警就足够的精准。然而这是一个老本与实际的重复试验，在报警触发之前，你不晓得什么样的条件可能排除掉这种有效报警。因而，在业务的一直实际摸索中，积淀了一些通用的异样聚合条件以晋升报警的精准性：

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

举例来说：开始的时候设置来自某个业务线的 JS 异样报警。聚合条件设置如下

业务线 = xxx && 谬误类型 = js 异样

优化后的报警聚合条件为：

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

为防止每个报警项都反复的设置雷同的聚合条件，把一些通用的数据在顶层进行过滤，在晋升报警精准性的同时缩小了每个业务方的配置工作。

挑战 3：带有显著周期性的异样监控项如何设置监控的同比和环比？

针对有显著周期性的异样监控在初期设置的时候，个别都会比拟审慎。设置的过小，产生的 有效报警 会很多。设置的过大，有报警时无奈及时触发。

这种状况在实践中发现：

1. 同环比的设置不应该在一开始设置的，应该察看一段时间再设置。比方，同比昨天的数据，这个阈值的设置应该在至多积攒 2 天数据后再设置，以理论每天数据的稳定状况来进行正当的阈值百分比设置。
2. 同比环比的设置不应变化无穷的，应该隔一段时间更新一次。随着业务的倒退，线上的异样申请是一直变动的，如果发现一段时间内的报警变多了，而排查后发现大部分是有效的报警，这个时候，你就须要重新考虑你的报警设置的是否正当了。

挑战 4：如何监控报警后的问题跟进状况？

托管页的异样治理，不仅是一个根底能力的建设。还心愿造成异样问题发现、异样跟进、异样解决的工程化能力闭环。异样的跟进买通公司外部工作治理平台，针对每一个报警创立一个工作卡片，由具体的异样负责人进行跟进。当问题解决后，能够在工作卡片上进行具体信息的录入，以此来实现每个异样都有专人跟进解决的指标。为晋升问题的跟进率，咱们还会基于工作卡片的信息进行例行化的统计，针对卡片停留时长、卡片个数等进行剖析计算并买通外部即时通讯工具对卡片统计信息进行例行化推送。

===

四、异样排查

在收到一个异样报警后，疾速定位到报警产生的起因是一个十分常见的业务场景。

从实际中，咱们总结出几点可能疾速晋升异样排查效率的形式：

• 善用聚合

很多时候，线上的异样数据是在某个区间内来回稳定。当忽然呈现一个突刺时，通过聚合能够疾速的查问到问题所在。

通过这些聚合条件，能够疾速的发现这些突发异样的类似点。罕用的聚合选项能够有 ip、ua、设施 id、URL 等。

例如：一次线上的资源加载失败报警中，发现异常日志中的页面 URL、资源失败 URL、投放参数均不雷同。排除了个别广告页加大投放流量的可能，也排除了机器脚本刷页面的可能。最初通过 ip 聚合后，发现异常都是在某个地区，和 CDN 同学反馈后，发现这个地区缺失存在网络故障，及时的推动，防止了更大范畴的损失。

• 欠缺根底能力的反对

目前线上的 JS 都是压缩之后的。一旦产生了异样信息，在异样堆栈中存储的也是压缩之后的信息，不便于问题的排查。因而，咱们协同上游谬误剖析平台，上传托管页相干的 sourcemap 资源。这样在产生的 JS 执行异样中的报错信息就能够通过 sourcemap 文件，间接定位到原始谬误文件地位，不便开发者疾速的定位到产生问题的代码地位，晋升问题排查效率。

五、异样治理

下面介绍的异样收集、异样报警以及异样的排查，偏重于一种被动的场景。触发了线上报警，才会染指问题的排查。但其实除了这些偶然的突刺带来的报警问题跟进，咱们也主动出击，针对线上现存的一些异样，探索一些通用的计划，以被动优化线上的异样场景，晋升托管页线上的稳定性。

首先，为了对立治理指标，协同各方一起解决线上异样，咱们从以下几步登程进行线上异样治理指标的设定：

1. 明确异样谬误类型

在 JS 执行异样，API 异样，资源加载异样的根底上，再次进行细分。最终落地 4 个异样类型，别离为：

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

2. 荡涤数据

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

3. 建设适合的数据规范

为抹平不同产品线之间的流量差别，咱们提出了 单次广告点击产生的异样数 的概念。将异样数量的绝对值变成了一个以广告流量为基准的相对值，以此来掂量不同流量产品线下的异样量。这样归一化之后，排除了广告流量对异样数据量的影响。

针对和 网络状况 相干指标比方：单次广告点击图片 / SCRIPT 加载失败数以及 API 申请失败数

建设数据规范的流程是：

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

外围思路：此类异样都是因为网络起因导致的，不同产品线之间的值应该趋于统一。基于此，取 80 分位值作为优化的基准线，没有达到这个基准线的产品线除了网络因素外肯定存在其余的问题，能够推动这些产品线向这个对立的规范对齐。（为了防止某一天的数据过于极其，能够思考取平均值或者去除突刺数据后取最小值来失去最初的目标值）

针对和运行时关系比拟亲密的指标：单次广告点击 JS 失败数

建设数据规范的流程是：

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

建设优化指标后，便能够针对性的优化。

针对因为网络起因导致的资源加载异样外围采取以下思路。

1. 改用 CDN 链接或缩小资源大小可升高第一次加载失败率
2. 图片应用 CDN 链接
3. 图片进行正当压缩或应用更高压缩比的图片格式（如 webp 等）
4. 重试能够升高最终资源加载失败率

咱们针对 API 申请异样、SCRIPT 加载异样、图片加载异样别离从底层登程，建设了相应的重试机制。其中，除 SCRIPT 加载异样的重试业务方无感知外，API 申请异样以及图片加载异样，业务方都能够通过传入相干参数来进行业务表白，以反对不同的业务场景。

针对 JS 执行时的异样，咱们建设了一个残缺的解决流程:

1. 从通用的异样监控中发现业务可优化异样；
2. 通过细化具体的监控条件，针对该业务异样建设独自的监控；
3. 上线优化计划，解决该类异样；
4. 察看监控数据降落是否合乎预期。

通过以上四步来优化每一类具体的业务异样。

通过以上形式，咱们设定了适合的指标，并进行了针对性的优化。最终，每个异样指标的数据在针对性治理后均有不同水平的降落，同时，在异样治理时引入线上试验以掂量升高线上异样数对广告转化的影响，试验结果表明：app 下载，以及线索的转化均有所晋升。

六、后记

异样治理是一条难但正确的路线。在业务落地实际中，遇到了很多问题和挑战，咱们实现了从 0 到 1 的过程，摸索了一种可继续的前端异样监控与治理的形式，然而很多事件还须要深耕，这样能力一直的升高托管页前端的异样数量，晋升托管页线上的稳定性。

———- END ———-

百度 Geek 说

百度官网技术公众号上线啦！

技术干货 · 行业资讯 · 线上沙龙 · 行业大会

招聘信息 · 内推信息 · 技术书籍 · 百度周边

欢送各位同学关注