字节前端监控实践

简述

Slardar 前端监控自18年底开始建设以来，从仅仅作为 Sentry 的替代，经历了一系列迭代和发展，目前做为一个监控解决方案，已经应用到抖音、西瓜、今日头条等众多业务线。

据21年下旬统计，Slardar 前端监控（Web + Hybrd) 工作日晚间峰值 qps 300w+，日均处理数据超过千亿条。

本文，我将针对在这一系列的发展过程中，字节内部监控设计和迭代遇到的落地细节设计问题，管中窥豹，向大家介绍我们团队所思考和使用的解决方案。

他们主要围绕着前端监控体系建设的一些关键问题展开。也许大家对他们的原理早已身经百战见得多了，不过当实际要落地实现的时候，还是有许多细节可以再进一步琢磨的。

如何做好 JS 异常监控

JS 异常监控本质并不复杂，浏览器早已提供了全局捕获异常的方案。

window.addEventListenr('error', (err) => {
    report(normalize(err))
});

window.addEventListenr('unhandledrejection', (rejection) => {
    report(normalize(rejection))
});

但捕获到错误仅仅只是相关工作的第一步。在我看来，JS 异常监控的目标是：

1. 开发者迅速感知到 JS 异常发生
2. 通过监控平台迅速定位问题
3. 开发者能够高效的处理问题，并统计，追踪问题的处理进度

在异常捕获之外，还包括堆栈的反解与聚合，处理人分配和报警这几个方面。

堆栈反解： Sourcemap

大家都知道 Script 脚本在浏览器中都是以明文传输并执行，现代前端开发方案为了节省体积，减少网络请求数，不暴露业务逻辑，或从另一种语言编译成 JS。都会选择将代码进行混淆和压缩。在优化性能，提升用户体验的同时，也为异常的处理带来了麻烦。

在本地开发时，我们通常可以清楚的看到报错的源代码堆栈，从而快速定位到原始报错位置。而线上的代码经过压缩，可读性已经变得非常糟糕，上报的堆栈很难对应到原始的代码中。 Sourcemap 正是用来解决这个问题的。

简单来说，Sourcemap 维护了混淆后的代码行列到原代码行列的映射关系，我们输入混淆后的行列号，就能够获得对应的原始代码的行列号，结合源代码文件便可定位到真实的报错位置。

Sourcemap 的解析和反解析过程涉及到 VLQ 编码，它是一种将代码映射关系进一步压缩为类base64编码的优化手段。

在实际应用中，我们可以把它直接当成黑盒，因为业界已经为我们提供了方便的解析工具。下面是一个利用 mozila 的 sourcemap 库进行反解的例子。

以上代码执行后通常会得到这样的结果，实际上我们的在线反解服务也就是这样实现的

当然，我们不可能在每次异常发生后，才去生成 sourcemap，在本地或上传到线上进行反解。这样的效率太低，定位问题也太慢。另一个方案是利用 sourcemappingURL 来制定sourcemap 存放的位置，但这样等于将页面逻辑直接暴露给了网站使用者。对于具有一定规模和保密性的项目，这肯定是不能接受的。

 //# sourceMappingURL=http://example.com/path/hello.js.map 

为了解决这个问题，一个自然的方案便是利用各种打包插件或二进制工具，在构建过程中将生成的 sourcemap 直接上传到后端。Sentry 就提供了类似的工具，而字节内部也是使用相似的方案。

通过如上方案，我们能够让用户在发版构建时就可以完成 sourcemap 的上传工作，而异常发生后，错误可以自动完成解析。不需要用户再操心反解相关的工作了。

堆栈聚合策略

当代码被成功反解后，用户已经可以看到这一条错误的线上和原始代码了，但接下来遇到的问题则是，如果我们只是上报一条存一条，并且给用户展示一条错误，那么在平台侧，我们的异常错误列表会被大量的重复上报占满，

对于错误类型进行统计，后续的异常分配操作都无法正常进行。

在这种情况下，我们需要对堆栈进行分组和聚合。也就是，将具有相同特征的错误上报，归类为统一种异常，并且只对用户暴露这种聚合后的异常。

堆栈怎么聚合效果才好呢？我们首先可以观察我们的JS异常所携带的信息，一个异常通常包括以下部分

• name： 异常的 Type，例如 TypeError, SyntaxError, DOMError
• Message：异常的相关信息，通常是异常原因，例如 a.b is not defined.
• Stack （非标准）异常的上下文堆栈信息，通常为字符串

那么聚合的方案自然就出来了，利用某种方式，将 error 相关的信息利用提取为 fingerprint，每一次上报如果能够获得相同的 fingerprint，它们就可以归为一类。那么问题进一步细化为：如何利用 Error 来保证 fingerprint 的区分尽量准确呢？

如果跟随标准，我们只能利用 name + message 作为聚合依据。但在实践过程中，我们发现这是远远不够的。如上所示，可以看到这两个文件发生的位置是完全不同的，来自于不同的代码段，但由于我们只按照 name + message 聚合。它们被错误聚合到了一起，这样可能造成我们修复了其中一个错误后。误以为相关的所有异常都被解决。

因此，很明显我们需要利用非标准的 error.stack 的信息来帮我们解决问题了。在这里我们参考了 Sentry 的堆栈聚合策略：

除了常规的 name, message, 我们将反解后的 stacktrace 进一步拆分为一系列的 Frame，每一个 Frame 内我们重点关注其调用函数名，调用文件名以及当前执行的代码行(图中的context_line)。

Sentry 将每一个拆分出的部分都称为一个 GroupingComponent，当堆栈反解完毕后，我们首先自上而下的递归检测，并自下而上的生成一个个嵌套的 GroupingComponent。最后，在顶层调用 GroupingComponent.getHash() 方法, 得到一个最终的哈希值，这就是我们最终求得的 fingerprint。

相较于message+name, 利用 stacktrace 能够更细致的提取堆栈特征，规避了不同文件下触发相同 message 的问题。因此获得的聚合效果也更优秀。这个策略目前在字节内部的工作效果良好，基本上能够做到精确的区分各类异常而不会造成混淆和错误聚合。

处理人自动分配策略

异常已经成功定位后，如果我们可以直接将异常分配给这行代码的书写者或提交者，可以进一步提升问题解决的效率，这就是处理人自动分配所关心的，通常来说，分配处理人依赖 git blame 来实现。

一般的团队或公司都会使用 Gitlab / Github 作为代码的远端仓库。而这些平台都提供了丰富的 open-api 协助用户进行blame，

我们很自然的会联想到，当通过 sourcemap 解出原始堆栈路径后，如果可以结合调用 open-api，获得这段代码所在文件的blame历史, 我们就有机会直接在线上确定某一行的可能的 author / commitor 究竟是谁。从而将这个异常直接分配给他。

思路出来了，那么实际怎么落地呢？

我们需要几个信息

1. 线上报错的项目对应的源代码仓库名，如 toutiao-fe/slardar
2. 线上报错的代码发生的版本，以及与此版本关联的 git commit 信息，为什么需要这些信息呢？

默认用来 blame 的文件都是最新版本，但线上跑的不一定是最新版本的代码。不同版本的代码可能发生行的变动，从而影响实际代码的行号。如果我们无法将线上版本和用来 blame 的文件划分在统一范围内，则很有可能自动定位失败。

因此，我们必须找到一种方法，确定当前 blame 的文件和线上报错的文件处于同一版本。并且可以直接通过版本定位到关联的源代码 commit 起止位置。这样的操作在 Sentry 的官方工具 Sentry-Cli 中亦有提供。字节内部同样使用了这种方案。

通过 相关的 二进制工具，在代码发布前的脚本中提供当前将要发布的项目的版本和关联的代码仓库信息。同时在数据采集侧也携带相同的版本，线上异常发生后，我们就可以通过线上报错的版本找到原始文件对应的版本，从而精确定位到需要哪个时期的文件了。

异常报警

当异常已经成功反解和聚合后，当用户访问监控平台，已经可以观察并处理相关的错误，不过到目前为止，异常的发生还无法触及开发者，问题的解决依然依靠“走查”行为。这样的方案对严重的线上问题依然是不够用，因此我们还需要主动通知用户的手段，这就是异常报警。

在字节内部，报警可以分为宏观报警，即针对错误指标的数量/比率的报警，以及微观报警，即针对新增异常的报警。

宏观报警

宏观报警是数量/比率报警, 它只是统计某一类指标是否超出了限定的阈值，而不关心它具体是什么。因此默认情况下它并不会告诉你报警的原因。只有通过归因维度或者下文会提到的 微观(新增异常)报警 才能够知晓引发报警的具体原因

关于宏观报警，我们有几个关键概念

• 第一是样本量，用户数阈值: 在配置比率指标时。如果上报量过低，可能会造成比率的严重波动，例如错误率 > 20%, 的报警下，如果 JS 错误数从 0 涨到 1， 那就是比率上涨到无限大从而造成没有意义的误报。如果不希望被少量波动干扰，我们设置了针对错误上报量和用户数的最低阈值，例如只有当错误影响用户数 > 5 时，才针对错误率变化报警。

• 第二是归因维度： 对于数量，比率报警，仅仅获得一个异常指标值是没什么意义的，因为我们无法快速的定位问题是由什么因素引发的，因此我们提供了归因维度配置。例如，通过对 JS 异常报警配置错误信息归因，我们可以在报警时获得引发当前报警的 top3 关键错误和增长最快的 top3 错误信息。
• 第三是时间窗口，报警运行频率： 如上文所说，报警是数量，比率报警，而数量，比率一定有一个统计范围，这个就是通过 时间窗口 来确定的。而报警并不是时时刻刻盯着我们的业务数据的，可以理解为利用一个定时器来定期检查 时间窗口 内的数据是否超出了我们定义的阈值。而这个定时器的间隔时间，就是 报警运行频率。通过这种方式，我们可以做到类实时的监测异常数据的变化，但又没有带来过大的资源开销。

微观报警(新增异常)

相较于在意宏观数量变化的报警，新增异常在意每一个具体问题，只要此问题是此前没有出现过的，就会主动通知用户。

同时，宏观报警是针对数据的定时查找，存在运行频率和时间窗口的限制，实时性有限。微观报警是主动推送的，具有更高的实时性。

微观报警适用于发版，灰度等对新问题极其关注，并且不方便在此时专门配置相关数量报警的阶段。

如何判断“新增”？

我们在 异常自动分配章节讲到了，我们的业务代码都是可以关联一个版本概念的。实际上版本不仅和源代码有关，也可以关联到某一类错误上。

在这里我们同样也可以基于版本视角判断“新增错误”。

对于新增异常的判断，针对两种不同场景做了区分

• 对于指定版本、最新版本的新增异常报警，我们会分析该报警的 fingerprint 是否为该版本代码中首次出现。
• 而对于全体版本，我们则将”首次”的范围增加了时间限制，因为对于某个错误，如果在长期没有出现后又突然出现，他本身还是具有通知的意义的，如果不进行时间限制，这个错误就不会通知到用户，可能会出现信息遗漏的情况。

如何做好性能监控？

如果说异常处理是前端监控体系60分的分界线，那么性能度量则是监控体系能否达到90分的关键。一个响应迟钝，点哪儿卡哪儿的页面，不会比点开到处都是报错的页面更加吸引人。页面的卡顿可能会直接带来用户访问量的下降，进而影响背后承载的服务收入。因此，监控页面性能并提升页面性能也是非常重要的。针对性能监控，我们主要关注指标选取，品质度量 、瓶颈定位三个关键问题。

指标选取

指标选取依然不是我们今天文章分享的重点。网上关于 RUM 指标，Navigation 指标的介绍和采集方式已经足够清晰。通常分为两个思路：

1. RUM (真实用户指标) -> 可以通过 Web Vitals （github.com/GoogleChrom…*
2. 页面加载指标 -> NavigationTiming (ResourceTiming + DOM Processing + Load) 可以通过 MDN 相关介绍学习。这里都不多赘述。

瓶颈定位

收集到指标只是问题的第一步，接下来的关键问题便是，我们应该如何找出影响性能问题的根因，并且针对性的进行修复呢？

慢会话 + 性能时序分析

如果你对“数据洞察/可观测性”这个概念有所了解，那么你应该对 Kibana 或 Datadog 这类产品有所耳闻。在 kibana 或 Datadog 中都能够针对每一条上传的日志进行详细的追溯。和详细的上下文进行关联，让用户的体验可被观测，通过多种筛选找到需要用户的数据。

在字节前端的内部建设中，我们参考了这类数据洞察平台的消费思路。设计了数据探索能力。通过数据探索，我们可以针对用户上报的任意维度，对一类日志进行过滤，而不只是获得被聚合过的列表信息数据。这样的消费方式有什么好处呢？

1. 我们可以直接定位到一条具体日志，找到一个现实的 data point 来分析问题
2. 这种视图的状态是易于保存的，我们可以将找到的数据日志通过链接发送给其他人，其他用户可以直接还原现场。

对于性能瓶颈，在数据探索中，可以轻松通过针对某一类 PV 上报所关联的性能指标进行数值筛选。也可以按照某个固定时段进行筛选，从而直接获得响应的慢会话。这样的优势在于我们不用预先设定一个“慢会话阈值”，需要哪个范围的数据完全由我们自己说了算。例如，通过对 FCP > 3000ms 进行筛选，我们就能够获得一系列 FCP > 3s 的 PV 日志现场。

在每次 PV 上报后，我们会为数据采集的 SDK 设置一个全局状态，比如 view_id, 只要没有发生新的页面切换，当前的 view_id 就会保持不变。

而后续的一系列请求，异常，静态资源上报就可以通过 view_id 进行后端的时序串联。形成一张资源加载瀑布图。在瀑布图中我们可以观察到各类性能指标和静态资源加载，网络请求的关系。从而检测出是否是因为某些不必要的或者过大的资源，请求导致的页面性能瓶颈。这样的瀑布图都是一个个真实的用户上报形成的，相较于统计值产生的甘特图，更能帮助我们解决实际问题。

结合Longtask + 用户行为分析

通过指标过滤慢会话，并且结合性能时序瀑布图分析，我们能够判断出当前页面中是否存在由于网络或过大资源因素导致的页面加载迟缓问题

但页面的卡顿不一定全是由网络因素造成的。一个最简单的例子。当我在页面的 head 中插入一段非常耗时的同步脚本（例如 while N 次），则引发页面卡顿的原因就来自于代码执行而非资源加载。

针对这种情况，浏览器同样提供了 Longtask API 供我们收集这类占据主线程时间过长的任务。
同样的，我们将这类信息一并收集，并通过上文提到的 view_id 串联到一次页面访问中。用户就可以观察到某个性能指标是否受到了繁重的主线程加载的影响。若有，则可利用类似 lighthouse 的合成监控方案集中检查对应页面中是否存在相关逻辑了。

受限于浏览器所收集到的信息，目前的 longtask 我们仅仅只能获得它的执行时间相关信息。而无法像开发者面板中的 performance 工具一样准确获取这段逻辑是由那段代码引发的。如果我们能够在一定程度上收集到longtask触发的上下文，则可定位到具体的慢操作来源。

此外，页面的卡顿不一定仅仅发生在页面加载阶段，有时页面的卡顿会来自于页面的一次交互，如点击，滚动等等。这类行为造成的卡顿，仅仅依靠 RUM / navigation 指标是无法定位的。如果我们能够通过某种方式（在PPT中已经说明），对操作行为计时。并将操作计时范围内触发的请求，静态资源和longtask上报以同样的瀑布图方式收敛到一起。则可以进一步定位页面的“慢操作”，从而提升页面交互体验。

如下图所示，我们可以检查到，点击 slardar_web 这个按钮 / 标签带来了一系列的请求和 longtask，如果这次交互带来了一定的交互卡顿。我们便可以集中修复触发这个点击事件所涉及的逻辑来提升页面性能表现。

品质度量

当我们采集到一个性能指标后，针对这样一个数字，我们能做什么？

我们需要结论：好还是不好？

实际上我们通常是以单页面为维度来判定指标的，以整站视角来评判性能的优劣的置信度会受到诸多因素影响，比如一个站点中包含轻量的登陆页和功能丰富的中后台，两者的性能要求和用户的容忍度是不一致的，在实际状况下两者的绝对性能表现也是不一致的。而简单平均只会让我们观察不到重点，页面存在的问题数据也可能被其他的页面拉平。

其次，指标只是冷冰冰的数据，而数据想要发挥作用，一定需要参照系。比如，我仅仅提供 FMP = 4000ms，并不能说明这个页面的性能就一定需要重点关注，对于逻辑较重的PC页面，如数据平台，在线游戏等场景，它可能是符合业务要求的。而一个 FMP = 2000ms的页面则性能也不一定好，对于已经做了 SSR 等优化的回流页。这可能远远达不到我们的预期。

一个放之四海而皆准的指标定义是不现实的。不同的业务场景有不同的性能基准要求。我们可以把他们转化为具体的指标基准线。

通过对于现阶段线上指标的分布，我们可以可以自由定义当前站点场景下针对某个指标，怎样的数据是好的，怎样的数据是差的。

基准线应用后，我们便可以在具体的性能数据产出后，直观的观察到，在什么阶段，某些指标的表现是不佳的，并且可以集中针对这段时间的性能数据日志进行排查。

一个页面总是有多个性能指标的，现在我们已经知道了单个性能指标的优劣情况，如何整体的判断整个页面，乃至整个站点的性能状况，落实到消费侧则是，我们如何给一个页面的性能指标评分？

如果有关注过 lighthouse 的同学应该对这张图不陌生。

lighthouse 通过 google 采集到的大量线上页面的性能数据，针对每一个性能指标，通过对数正态分布将其指标值转化成 百分制分数。再通过给予每个指标一定的权重（随着 lighthouse 版本更迭), 计算出该页面性能模块的一个“整体分数”。在即将上线的“品质度量”能力中，我们针对 RUM 指标，异常指标，以及资源加载指标均采取了类似的方案。

我们通常可以给页面的整体性能分数再制定一个基准分数，当上文所述的性能得分超过分数线，才认为该页面的性能水平是“达标”的。而整站整体的达标水平，则可以利用整站达标的子页面数/全站页面数来计算，也就是达标率，通过达标率，我们可以非常直观的迅速找到需要优化的性能页面，让不熟悉相关技术的运营，产品同学也可以定期巡检相关页面的品质状况。

如何做好请求 / 静态资源监控？

除了 JS 异常和页面的性能表现以外，页面能否正常的响应用户的操作，信息能否正确的展示，也和 api 请求，静态资源息息相关。表现为 SLA，接口响应速度等指标。现在主流的监控方案通常是采用手动 hook相关 api 和利用 resource timing 来采集相关信息的。

手动打点通常用于请求耗时兜底以及记录请求状态和请求响应相关信息。

1. 对于 XHR 请求： 通过 hook XHR 的 open 和 send 方法, 获取请求的参数，在 onreadystatechange 事件触发时打点记录请求耗时。

   1.  // 记录 method
       hookObjectProperty(XMLHttpRequest.prototype, 'open', hookXHROpen); 
       // hook onreadystateChange，调用前后打点计算
       hookObjectProperty(XMLHttpRequest.prototype, 'send', hookXHRSend);
      

2. 对于fetch请求，则通过 hook Fetch 实现

   1. hookObjectProperty(global, 'fetch', hookFetch)
      

• 第二种则是 resourceTiming 采集方案

• 1. 静态资源上报:

     1. pageLoad 前：通过 performance.getEntriesByType 获取 resource 信息
     2. pageLoad后：通过 PerformanceObserver 监控 entryType 为 resource 的资源

• const callback = (val, i, arr, ob) => // ... 略
  const observer = new PerformanceObserver((list, ob) => {
      if (list.getEntries) {
        list.getEntries().forEach((val, i, arr) => callback(val, i, arr, ob))
      } else {
        onFail && onFail()
      }
      // ...
   });
   
  observer.observe({ type: 'resource', buffered: false })
  

手动打点的优势在于无关兼容性，采集方便，而 Resource timing 则更精准，并且其记录中可以避开额外的事件队列处理耗时

如何理解和使用 resource timing 数据？

我们现在知道 ResourceTiming 是更能够反映实际资源加载状况的相关指标，而在工作中，我们经常遇到前端请求上报时间极长而后端对应接口日志却表现正常的情况。这通常就可能是由使用单纯的打点方案计算了太多非服务端因素导致的。影响一个请求在前端表现的因素除了服务端耗时以外，还包括网络，前端代码执行排队等因素。我们如何从 ResourceTiming 中分离出这些因素，从而更好的对齐后端口径呢？

第一种是 Chrome 方案（阿里的 ARMS 也采用的是这种方案)：

它通过将线上采集的 ResoruceTiming 和 chrome timing 面板的指标进行类比还原出一个近似的各部分耗时值。他的简单计算方式如图所示。

不过 chrome 实际计算 timing 的方式不明，这种近似的方式不一定能够和 chrome 的面板数据对的上，可能会被用户质疑数据不一致。

第二种则是标准方案: 规范划分阶段，这种划分是符合 W3C 规范的格式，其优势便在于其通用性好，且数据一定是符合要求的而不是 chrome 方案那种“近似计算”。不过它的缺陷是阶段划分还是有点太粗了，比如用户无法判断出浏览器排队耗时，也无法完全区分网络下载和下载完成后的资源加载阶段。只是简单的划分成了 Request / Response 阶段，给用户理解和分析带来了一定成本

在字节内部，我们是以标准方案为主，chrome方案为辅的，用户可以针对自己喜好的那种统计方式来对齐指标。通常来说，和服务端对齐耗时阶段可以利用标准方案的request阶段减去severtiming中的cdn，网关部分耗时来确定。

接下来我们再谈谈采集 SDK 的设计。

SDK 如何降低侵入，减少用户性能损耗？体积控制和灵活使用可以兼得吗？

常需要尽早执行，其资源加载通常也会造成一定的性能影响。更大的资源加载可能会导致更慢的 Load，LCP，TTI 时间，影响用户体验。

为了进一步优化页面加载性能，我们采用了 JS Snippets 来实现异步加载 + 预收集。

1. 异步加载主要逻辑

首先，如果通过 JS 代码创建 script 脚本并追加到页面中，新增的 script 脚本默认会携带 async 属性，这意味着这这部分代码将通过async方式延迟加载。下载阶段不会阻塞用户的页面加载逻辑。从而一定程度的提升用户的首屏性能表现。

2. 预收集

试想一下我们通过 npm 或者 cdn 的方式直接引入监控代码，script必须置于业务逻辑最前端，这是因为若异常先于监控代码加载发生，当监控代码就位时，是没有办法捕获到历史上曾经发生过的异常的。但将script置于前端将不可避免的对用户页面造成一定阻塞，且用户的页面可能会因此受到我们监控 sdk 服务可用性的影响。

为了解决这个问题，我们可以同步的加载一段精简的代码，在其中启动 addEventListener 来采集先于监控主要逻辑发生的错误。并存储到一个全局队列中，这样，当监控代码就位，我们只需要读取全局队列中的缓存数据并上报，就不会出现漏报的情况了。

更进一步：事件驱动与插件化

方案1. 2在大部分情况下都已经比较够用了，但对于字节的某些特殊场景却还不够。由于字节存在大量的移动端页面，且这些页面对性能极为敏感。因而对于第三方库的首包体积要求非常苛刻，同时，也不希望第三方代码的执行占据主线程太长时间。

此外，公司内也有部分业务场景特殊，如 node 场景，小程序场景，electron，如果针对每一种场景，都完全重新开发一套新的监控 SDK，有很大的人力重复开发的损耗。

如果我们能够将 SDK 的框架逻辑做成平台无关的，而各个数据监控，收集方案都只是以插件形式存在，那么这个 SDK 完全是可插拔的，类似 Sentry 所使用的 integration 方案。用户甚至可以完全不使用任何官方插件，而是通过自己实现相关采集方案，来做到项目的定制化。

关于框架设计可以参见下图

1. 我们把整个监控 SDK 看作一条流水线（Client），接受的是用户配置（config)（通过 ConfigManager)，收集和产出的是具体事件（Event, 通过 Plugins)。流水线是平台无关的，它不关心处理的事件是什么，也不关心事件是从哪来的。它其实是将这一系列的组件交互都抽象为 client 上的事件，从而使得数据采集器能够介入数据流转的每个阶段
   Client 通过 builder 包装事件后，转运给 Sender 负责批处理，Sender 最终调用 Transporter 上报。Transporter 是平台强相关的，例如 Web 使用 xhr 或 fetch，node 则使用 request 等。 同时，我们利用生命周期的概念设置了一系列的钩子，可以让用户可以在适当阶段处理流水线上的事件。例如利用 beforeSend 钩子去修改即将被发送的上报内容等。

当整体的框架结构设计完后，我们就可以把视角放到插件上了。由于我们将框架设置为平台无关的，它本身只是个数据流，有点像是一个精简版的 Rx.js。而应用在各个平台上，我们只需要根据各个平台的特性设计其对应的采集或数据处理插件。

插件方案某种意义上实现了 IOC，用户不需要关心事件怎么处理，传入的参数是哪里来的，只需要利用传入的参数去获取配置，启动自己的插件等。如下这段JS采集器代码，开发插件时，我们只需要关心插件自身相关的逻辑，并且利用传入 client 约定的相关属性和方法工作就可以了。不需要关心 client 是怎么来的，也不用关心 client 什么时候去执行它。

当我们写完了插件之后，它要怎么才能被应用在数据采集和处理中呢？为了达成降低首包大小的目标，我们将插件分为同步和异步两种加载方式。

1. 可以预收集的监控代码都不需要出现在首包中，以异步插件方式接入
2. 无法做到预收集的监控代码以同步形式和首包打在一起，在源码中将client传入，尽早启动，保证功能稳定。

3. 异步插件采用约定式加载，用户在使用层面是完全无感的。我们通过主包加载时向在全局初始化注册表和注册方法，在读取用户配置后，拉取远端插件加载并利用全局注册方法获取插件实例，最后传入我们的 client 实现代码执行。

经过插件化和一系列 SDK 的体积改造后，我们的sdk 首包体积降低到了从63kb 降低到了 34 kb。

总结

本文主要从 JS 异常监控，性能监控和请求，静态资源监控几个细节点讲述了 Slardar 在前端监控方向所面临关键问题的探索和实践，希望能够对大家在前端监控领域或者将来的工作中产生帮助。其实前端监控还有许多方面可以深挖，例如如何利用拨测，线下实验室数据采集来进一步追溯问题，如何捕获白屏等类崩溃异常，如何结合研发流程来实现用户无感知的接入等等。