前端监控是一个大话题，无论在知乎，还是掘金，我都阅读过很多相关的文章。但是，在众多文章中，我发现他们都有一些共性，但是你却无法简单说哪些是共性的东西，哪些是专门的东西。为此，我打算写一篇文章，来讲解我在设计我的前端监控系统时，如何解决前端SDK的问题。

前端监控SDK的共性

和其他SDK不同，前端监控SDK基本上要求开箱即用，一个<script src>就可以完成所有监控逻辑。在文档中插入script标签时，可以带上data-appid属性，以区分当前监控的应用，脚本内可通过document.currentScript读取，当然，如果服务端以及绑定了域名，那不需要appid也无所谓。

我们要谈的是，作为SDK的提供方，我们要在SDK中怎么写，才能做到这种开箱即用，或者对于下游开发者而言更好用。

前端监控的目标各有不同，包括：测速、性能、错误、行为等方面。我在过去两年中，重点集中在研究监控用户行为，在长时间的探索中，我对SDK进行了多次重构，最终发现，无论以什么方向为目标，SDK的设计都需要包含如下几个方面：

• 数据收集
• 数据存储（日志的结构，日志是存在内存中，还是存在indexedDB中）
• 数据上报（上报周期：立即，延时；上报策略：什么情况下触发上报；上报压缩等）
• 生命周期
• 代码分离（快速加载主体代码，异步加载功能代码；将数据处理移到webworker中）

不管你是做性能监控，还是错误监控，SDK都可以从这几个方面去思考，当然，不同场景下，不一定全部都要，但是作为成年人，我们往往全想要。我在写用户行为监控时，还遇到一些特殊场景：

• 仅在某一个特定流程中进行录制，其他页面不需要录制，因此，要求SDK具有可选的录制策略，而不是定死的
• 一串用于演示用户行为导致的界面变化的日志，具有不可能遗漏性，一旦遗漏其中一个日志，都有可能导致无法最终还原出用户操作的界面效果，因此，对SDK收集的日志完整性有要求
• 由于考虑到不同业务场景下，对浏览器兼容性又有考虑，所以，对SDK的可扩展性以及功能可替换性有要求

因此，实际上，我们作为SDK的作者，要考虑两种场景：SDK直接被网站引用（开箱即用），或者被开发者引用（二次开发）。多次重构中，我逐渐摸索出一套共性的东西，并将它以框架的形式在腾讯内部发布。

通用的前端监控SDK框架

作为框架，它的主要面向用户是开发者，它并不提供直接的功能，而是提供创建功能的底层接口，让开发者通过接口完成功能开发。我刚开始撰写用户行为还原SDK时，将所有的功能耦合在一起，仅仅是为了完成用户行为信息收集和上报的功能。但是，随着我想要收集的信息的扩展，我发现之前的设计并不好，因为每加一个方面的信息，就要再次耦合其中。于是我开始了漫长的重构。

目标很明确，每加一个方面的信息收集能力，不需要修改原有代码，而是提供新的代码，在把新代码模块导出的接口插入到已有代码的某处。于是，一个基于插件系统的架构浮现在我脑海中。比如我现在想要收集用户进入我的网站到离开我的网站之间的时间这样一个信息，我不需要修改SDK原有的代码，而是写一个插件，按照SDK的规范，提供不同生命周期节点上的钩子函数，就可以了。

生命周期

既然提到了生命周期，那就来聊一聊生命周期吧。

我向开发者提供了一个类，姑且叫 TheLogger 吧。开发者需要实例化这个类，实例化时，传入各种参数，参数中就包含了插件，这个后面聊。实例在内存中运行，它会经历给个节点，完成日志的收集和上报。

init (实例化阶段) -> servup (启动服务阶段) -> start (开始收集) -> write (写入日志) -> stop (停止收集) -> destroy (实例销毁)
                                               ^                                    /
                                                `-------------(重新启动)------------

SDK在这些生命周期节点上提供钩子，插件们则在这些钩子上挂载一些函数，当框架运行到这些生命周期节点上时，就会触发插件的函数，以实现插件的功能。

以如何收集用户的点击事件为例子。当实例化时，会去调用插件的options和init方法，用以获取插件的配置和在SDK实例化时做一些工作。 实例化过程中，SDK会启动服务，这个过程对于插件而言，都是启用过程，插件如果有自己的服务，可以在这个阶段启动起来。启动之后，SDK服务就像一个运转中的轮子，当轮子开始转时，把插件挂上去，于是轮子就有了插件提供的能力。接下来，在插件中，我们要收集用户的点击信息。如何收集呢？当然是addEventListener啦。让插件暴露一个start方法，这个方法会在SDK运转到start这个生命周期节点时被调用。在start钩子中，插件可以通过addEventListener对用户的点击事件进行监听，回调函数中可以使用this.write方法把收集到的信息，写入到SDK服务中。在stop钩子函数中解除监听。这样，插件自己的任务就完成了。在写入日志时，也可以提供write钩子方法，对写入的日志进行改写。

关键不在于使用哪些名称的方法，关键在于，我采用了一套插件系统，开发者通过自己撰写一个插件，就可以在SDK原来的基础上，收集更多信息，为SDK提供更丰富的功能。几乎所有的功能，都可以基于插件去完成，Core是一个基于生命周期的调度器而已，不断调用插件的各个方法实现功能。

生命周期的设计，几乎是所有系统设计的共性，我们现在回来看生命周期，会发现，生命周期是一个系统，一个存在运行时系统的核心，不同的业务场景下，我们提炼出来的生命周期节点是不一样的，流转图也是不同的。在前端监控这个领域，SDK的生命周期却都大致相同，因为业务场景基本一致。它围绕监控日志的收集、存储、上报进行展开，所以，基本就是这些流程。一旦这个基本的生命周期流程确定之后，插件的生命周期也就确定了。

服务

这里的服务（Service）是“真服务”，它通过一个常驻的运转流程，不断的监听事件，当事件发生时提供一个响应。在TheLogger中，我提供了一套内置的服务，这套服务基于indexedDB+webworker，在后台不间断运行。但这套内置的服务是解耦的，它并不属于框架的一部分，框架并不提供具体的服务，只是提供了服务的抽象接口。开发者拿到SDK框架之后，默认是不包含服务代码的，开发者可以用一个extends关键字，重写serve, send方法，把服务挂载进去（通过插件也可以实现）。

这种设计的好处在于，如果你并不喜欢我的内置服务，你可以不用它，而代码并不在框架中，因此，你最终打包的代码并不包含这部分内容。我在为公司内的一个监控平台Aegis提供用户行为监控的能力时，由于Aegis平台有自己的日志存储和上报体系，因此，我不需要把我自己的Service部分再塞到我提供的SDK中，而是只挑选了要使用到的插件，打包之后，再到Aegis中提供一个基于该打包后的SDK的Aegis插件，这样，对于下游用户而言，他们使用了一个Aegis插件，而这个Aegis插件拥有了TheLogger的功能。

一个运行中的服务，本质上就是一个资源消费系统。你需要用资源喂它，让它按照它被设计的方式产出效果。在前端监控SDK里面，这个服务就是你把日志喂给它，然后让它按照一定的逻辑上报到后台。所以，我设计时，要求开发者从serve和send两个方法实现服务。serve方法用于实例化服务，也就是说在SDK中，你将以什么样的服务处理日志的存储和上报。send方法则是喂日志/消息。send方法接收一个消息，当type为不同值时，表示要求服务干一件对应的事情，例如type=write表示要服务把我丢过去的日志写入到本地存储中，当type=report时表示要服务把我之前丢进去的日志上报到服务器上面。当然，不同的开发者在实现send方法时，具体实现不同，极端情况下，我们提供一个同步的服务，当 send({ type: 'write', data }) 发生时，直接将该日志发送到服务端，不需要在本地进行存储，这种情况下，serve方法不需要写任何内容，在send中直接调用上传接口。

插件

插件是完成日志收集的主要场所。插件暴露的接口有两种类型，一种是为SDK框架所调用的生命周期函数，另一种是为增强SDK功能的功能函数。

因为插件的生命周期函数会被SDK的生命周期钩子勾着走，所以单纯看插件代码，插件自身仿佛也有了生命周期。比如，你可以说插件在实例化、启动、停止时都在做什么。在设计时，我着重强调start/stop两个过程。start过程是插件真正的收集开始自动化开展过程，stop则是停止这个自动化过程。比如对用户鼠标轨迹的收集，在start中通过addEventListener启动监听，自动收集，而在stop中removeEventListener停止这个自动收集过程。

但，插件的运作方式并非只有自动一种。某些情况下，我们可能不依靠自动收集，而是手动收集，通过在业务代码中调用SDK实例的一个方法记录一条日志。比如，你只想记录某一个button被点击的次数，你直接将插件的一个功能函数绑定到该button的click事件上，这样就完成对单一对象的事件收集。这时，插件需要做的，是提供一个功能函数（接口），方便你在业务代码中调用。当然，功能函数千变万化，提供什么功能，完全看开发者自己。关键的核心，不在于函数本身，而在于插件是增强SDK系统的一种方式。因为插件系统的设计，配合生命周期，你可以在SDK的框架上，开发出任意的客户端信息收集的逻辑。

前端监控SDK的设计技巧

现在，你有了SDK框架，接下来，你应该利用该框架，撰写一个属于自己的SDK了。当然，作为一个前端监控SDK，它必须配合后端的一些规则，不过，由于一般的日志存储系统都是NoSQL的，所以，只要一条符合设计的日志，都可以被存到后端数据库中。我们这里要探讨的是，在你的SDK中，可能会涉及一些技巧，以解决某些实际的问题。

延时批量上报

有些监控系统是实时上报的，有的甚至为了确保收集到的信息的完整性，采用<img/>的形式上报用户点击。但是，这种上报在确保实时性和完整性的同时，给后端带来了巨大压力，如果一个网站具有极大的PV，那么日志上报接口将面临巨大的流量压力，弄的不好是自己给自己创造DDos。而解决的办法之一，就是延时批量上报。比如收集到10条后，再一起上报。但是假如一直收集不到10条呢？你可以说10条都不到，没有价值。不过，我们可以通过一个throttle的设计，让它在一定时间周期内上报。

还有一种，我们并不采取主动策略自动上报日志，而是要等到服务端来索要日志，我们内部黑话叫“日志捞取”。可以通过websocket或用户访问某些接口的时候，下发一个指令，SDK得到这个指令之后再上报。这就要求，日志数据事先要放在客户端（浏览器）。这就涉及到一个前端数据存储的问题。

前端数据存储

如前文所说，如果我们将日志放在内存里面，那么用户刷新页面，或页面崩溃，这部分数据就丢失了。当然，如果不需要延时上报，立即上报的情况下，前端并不需要存储日志，但是，我们设计的是延时批量上报，这样可以给我们带来一些特性，比如按需捞取。既然如此，我们就需要挑选一个前端数据存储的方案。我推荐的存储方案是indexedDB，和localStorage相比而言，它不仅具有较大的容量（500M），更重要的一个原因在于localStorage无法在webworker中被读取，而在我的设计中，有一种方案时在webworker中处理日志和上报日志。

但是，indexedDB也有不少坑，包括webworker的坑也不少。indexedDB的原生操作比较复杂，你可以使用我写的库indb实现indexedDB的操作。我在设计时，使用了三个store，一个是config，用于在主线程和worker线程之间共享配置，一个是archive，用于存储所有日志，一个是moment，用于存储需要立即上报的日志的索引信息（索引字段）。由于indexedDB是严格的NoSQL数据库，所以非常适合存储日志。archive这个store将会保存所有被收集到的日志，存储的时候，并不需要按照某个顺序存，而且为了更快存入，存储过程不需要复杂逻辑。

上报策略

我在设计时，采用了三种不同的上报周期：

• 批量上报，任何日志，都写到archive store中，不需要任何顺序，因为正常用户操作的顺序并不代表日志入库顺序，因为操作会有异步的情况，archive store中存储着全部被收集的没有被上传的日志
• 立即上报，当发生错误或异常时，往moment store里面写入对应的日志索引，立即上报的周期比较短，所以，当周期到来时，直接将moment store中的全部索引取出，然后到archive store中取出索引对应的全部日志，一次性上报
• 回溯上报，在某些情况下，archive store中的日志过了很久的时间都没有被上报，这种情况造成的原因多种多样，不好确定，但是，这些日志可能又是有用的，因此，在一个比较长的周期里面（小于7天，因为indexedDB的新策略是会删除7天之后的数据），要从尾往前遍历，把早期存入的但没有上报的日志再次上报

在日志设计时，通过日志中的level字段来判别该日志属于什么级别。我自己在处理时，error的是立即上报，其他的是批量上报。实际上，我们还可以设计一种有选择性的上报，比如有些日志上报了没啥意义，可以不用上报，让浏览器自己处理过期日志，但是，如果我们通过服务端发送捞取指令时，又马上把这些日志组织起来进行上报。

上报压缩

为了减小流量，我们需要对要上报的日志进行压缩。我自己使用了一个叫pako的库来进行gzip压缩，但是压缩会有一个问题，由于压缩算法本身要占据一定容量，所以，如果不采取批量上报的逻辑，那么不需要任何压缩，只有当批量上报，且上报数量达到一定数量时才进行压缩，否则压缩一条日志，反而让日志容量变大，还要增加服务端解压压力。

任务/线程

对于一个前端监控的SDK而言，它有可能和页面中的其他脚本一起强资源，导致页面卡顿。因此，我们要想办法，降低SDK对界面的影响。我提供了两套方案：

1. 启用一个webworker，将所有日志的处理、存储、上报等等，全部放在worker线程中，主线程仅仅完成数据收集部分，这样，可以降低日志处理上报时，读写数据库等操作带来的卡顿
2. 直接在主线程完成日志处理和上报，但是创建一个idle任务，只有当页面存在空闲时，才执行日志处理和上报，当用户在界面进行操作，并且需要更新界面时，任务会被暂时搁置，等到有闲暇时间时再进行

但是，由于js是单线程运行，所以，即使任务是异步执行的，仍然还是会占用资源。作为监控SDK，要尽可能不对运行程序产生任何影响。

异步加载插件

在为Aegis撰写插件时，我们发现SDK包的体积对收集到一些特定信息很关键，例如应用启动时的数据。如果SDK包很大，半天加载不完，等脚本加载完，早都已经过了收集的窗口了。所以，在这种场景下，我们要让SDK尽可能小（10K以内）。但是，很明显，有些功能，这么小体积是不够的。因此，我们设计了一套异步加载的插件体系。对于这些插件而言，它们分为两部分，一部分是直接挂在SDK内部，也就是10K以内的代码里面，收集一些启动时的数据，而收集到的数据暂时放在内存中，等异步代码加载完运行之后，再取出来做下一步处理。

打点/无埋点

SDK的灵活性也很重要，在最前面我提到，假如开发者只想监听用户在某3个页面之间的操作信息，而不是全部页面的操作信息，该怎么处理呢？所以，在设计上，我们要提供不同的打点、上报的方式。我在设计时，提供了“无埋点、片段、单点”x“自动上报、手动上报”的不同组合方式。针对上述问题，这里简单讲一下怎么实现片段埋点。在前文Service那一节我已经指出，对于用户行为的监听本质上是一个服务，既然是一个服务，那么就可以让这个服务开始或停止。因此，在上述这个具体问题上，当用户进入指定页面A时，启动服务，服务启动之后，用户的所有操作就会被记录到日志中，用户经过B页然后离开C页时，停止服务，那么用户的这段操作就结束了，这一连串相关的日志，会被一个相同的traceId串联起来。同样的道理，上报本身也是一个服务，如果我们再实例化时，让服务自动运行，上报自动完成，我们也可以选择关闭这个能力，通过手动调用report方法来触发上报逻辑。

隐私策略

监控行为可能涉及到一些隐私策略问题。不同的产品，其隐私策略也是不同的。对于开放性大众产品，针对单用户的行为进行分析，很可能能得出针对该用户的一些预测行为，这对商业公司的吸引力非常大。但是我们要知道，互联网不是法外之地，我们在实现能力的时候，应该尊重和保护用户隐私。针对隐私问题，SDK框架应该提供可扩展的能力，遵循“开放封闭原则”，让开发者可以自己根据产品需要，有可以与用户交互的过程，而非一股脑全部封装死，不管三七二十一收集和提交日志。针对这个方面，我在设计时，做了如下约束：

• 任何与密码相关的数据不会被记录，包括用户鼠标在该元素上的操作
• 提供特定的html标记，这些标记元素产生的信息不会被收集
• 提供特定的方法，让开发者可以在方法中过滤日志，或者做脱敏处理
• 在运转流程上，SDK不是一股脑只完成自己的任务，开发者可以控制SDK的运作，比如只有在征得用户同意后才上传日志

总之，隐私策略是产品策略中的重要一环，也是目前我们国家重点关注的一个方面，任何与监控相关的设计都应该慎重考虑。

结语

本文详细阐述了我在前端监控SDK框架的设计上的一些经历，虽然没有具体的实现代码，但是文章中所提出的这些理念，都可以帮助开发者实现一款自己的SDK框架，在工作中发挥作用。

2020-11-27 6090 SDK, 前端监控