呀！原来这就是前端监控系统

大厂技术  高级前端  Node进阶

点击上方 程序员成长指北，关注公众号

回复1，加入高级Node交流群

在刚开始学前端的时候，那时候开发的应用总是在用户的设备中出现一些报错，开发者只知道这个型号的设备出现这个问题，但对其他信息却全然不知，比如说其他操作系统、其他设备型号、其他页面会有这个报错吗，这个报错出现的频率又是多少。每次出问题只能等待用户反馈，不能第一时间去解决问题，甚至用户没反馈的话永远也无法发现某些报错。

后来了解到前端监控这个东西，才知道原来可以这样去监控用户设备上的应用。“前端监控”不单单包括web性能和JS异常的监听，还包括处理日志的平台。下面就来总结一下打造一个完整的前端监控系统的过程。

了解业务需求

首先要了解自己所在的团队或者公司的具体需求。

• 如果是一个小团队，可能只需要简单的几个数据即可，业务也只有一两种，这样的话整个系统会简单很多，不用划分很多模块

• 如果是中厂或者大厂，很多个前端部门都需要用到这个平台，那么就需要划分成很多模块，而且需要很多通用的特性（比如说维度，下面会讲到）

了解完这个产品覆盖的范围后，就要开始调查开发者们需要在用户手机中需要收集的数据，根据这些字段设计日志的数据结构和数据库的设计

这里提到的数据可以包含以下几个点和无数小点

1. 性能统计

   1. 基础数值（首次渲染时间、白屏时间等）

   2. 可交互（首次加载时页面卡顿、操作时的js加载情况等）

   3. 资源（包括资源大小和资源的加载时间）

2. 异常统计

   1. JS异常

   2. ajax异常

   3. 资源文件

img

其中大点需要一开始就确定，大点下面的小点我把他成为分组，分组可以被每个业务方根据自己的业务自定义，这样可以极大增加系统的灵活性。

确定日志格式

1. type：首先要有一个type字段区分日志的类型，value比如performance（性能统计），abnormal（异常统计），除了这两种比较常见的type，自己也可以根据团队或公司业务来拓展value。

2. module：然后我们需要根据module字段区分各业务方，如商业研发部、基础架构部，考虑到部门的名字用英文表示太长且容易误会，可以用数字（分为前标和后标）映射来表示，如"1_1"表示商业研发部，"1_2"表示商业技术研发部，"2_1"表示基础架构部，按申请的部的顺序顺延，相同的大部门可以使用相同的“前标”，“后标”也可以表示不同的项目，这些都可以根据自己的部门自定义。

3. group：使用group表示分组，比如可以将一个项目中不同的落地页分成不同的组，将一个落地页中不同的组件分为不同组，还是根据自己的业务自行调整。

4. dim：即dimension维度，这个比较重要，简单说就是将每个数据都分为多个模块来统计，常见的dim如操作系统（Android or iOS）、浏览器类型、是否落地页、网络类型等等。

5. info：性能或异常的具体信息，一个“大点”中的info要求一样，这样方便统计，如异常统计的info可以分为“异常信息”、“异常时间”、“异常类型”、“具体的异常位置（行数）”。还包括一些诸如操作系统和浏览器类型的公共信息。

img

数据结构如下

{
 type: String,
  module: String,
  group: String,
  dim: {
    // 各个维度的信息
  },
  info: {
    // 具体信息
  }
}

打造日志接收平台

• 接收日志的接口可以设置在前端监控平台的server端，暴露一个接口即可，通过type来调用不同的处理函数。

• 可以同时接收get请求和post请求。

• 支持get请求主要是方便发送日志，只需要把日志信息转为query放在url后面就可以发送，后面会出具体的教程。

• 支持post请求是因为可以支持sendBeacon的post请求，可以优先采用，该api可以在会话结束后发送打点日志，降低打点丢失率。

在发送和接收日志的时候有几点要注意的

1. 若此网站的用户访问量很大，频繁地发送日志会造成server端的压力很大，可以参考一下以下两个解决方法。

• 前端发送日志时抽样发送。

const randomNum = Math.random();
if(randomNum < 0.1) {  // 设置10%的抽样
  send()  // 发送日志
}

• 前端可以将数据临时保存在Storage中并合并起来，隔一段时间发送一次日志（类似节流）。

1. 受网络和设备老化的影响，有一些数据并不能反映网站的性能，这时候可以过滤极值来保证数据的可靠性。

2. 即使抽样检测，日志数据依旧十分庞大，server端可以暴露一个delete的接口，服务器自动删除老数据。

监控平台

监控平台主要包括可视化和异常报警两个方面。

img

可视化

1. 我们收集数据的一大目的就是为了方便地观察数据的趋势变化，可以结合表格、柱状图、饼图、折线图来展示。通过选择分组和维度、日期来观察不同状态下的数据。这点和普通的管理系统并无两样。

2. 为了观察数据随时间的变化，我们可以以小时、天、周来定义时间颗粒度，设置一个对比模式来比较不同时间颗粒度的数据，包括环比和上升下降值。

3. 自定义设置时间间隔区间，观察指定区域内的数据。

异常报警

顾名思义，异常报警就是当项目中某些异常的数量跟用户设置的模式一致时，就会自动触发报警，异常报警可以从以下几个方面考虑。

1. 支持小时级、天级选项，在小时级里面支持前后小时、上一天和当前天的同一小时、上一周和当前周的同一小时内的数据的对比；在天级里面支持上一天和当前天、上一周的同一天和当前天的数据的对比。

2. 数据对比时支持环比（百分比）、数量的增减，支持大于、大于等于、小于、小于等于等比较方式，可以根据部门的业务情况来定义。

3. 可以设置当前报警人的手机号或邮箱，还可以设置邮箱组，触发报警时发送短信或邮件。

4. 暴露一个触发报警的接口，服务器按时请求该接口。

img

维度

在前端监控系统中维度是一个重要的概念，而自定义维度更能体现系统的自由度，他可以针对不同的业务自定义一套专属的维度划分，并且可以通过比较不同的维度情况去理解项目。自定义维度可以让这套系统覆盖绝大部分的业务统计需求。

怎么设计维度

img

比如说B站的首页，性能指标可以有“顶部banner的视频加载时间”、“首屏加载时间”、“后端数据加载时间”，当我们查看这几个指标时，我们可能想对比一下未登录状态和已登录状态的指标，又或者想区分一下进入点是哪里（是从搜索结果页点进来的还是从其他地方进来），还可能想看一下有缓存状态和无缓存状态的指标区别。

这样就确定了三个维度，登录状态、进入点、缓存状态。

确定维度后就可以确定维度的取值，进入点可以取三个值：直接输入url、搜索结果页点进、其他，登录状态和缓存状态都是两个值，每个维度的每个取值可以组成一个组合，这样的话总共有12种组合，也就是说可以看到这个页面12种情况下的指标情况。如果你发现此页面有一些性能问题，但是又排查不出来，可以试着尝试不同的维度组合，最后发现在已登录和未登录两种状态之间的数值相差很大，那么就可以定点排查登录模块的问题。

但是维度的组合太多不一定是好事，比如12个组合，发送一次打点，数据库就会存入12条数据，如果是小时级的一天就会存入12×24条数据，若是维度组合数太多，就会非常浪费数据库资源，所以在自定义维度时需要按需设置。

img

所以避免打点的时候维度组合太多将系统搞崩溃，发送打点日志之前需要先配置维度信息，发送日志时会将维度和配置好的维度进行diff，如果有diff，则视为攻击，放弃这个日志数据。

维度提取

像操作系统os、浏览器类型这种取值太多了，一般不会直接作为维度，但是像移动端的操作系统只有ios、Android、other就可以直接作为默认维度，在解析日志时可以自动解析出当前站点、移动os、cookie、http类型等数据，并与自定义的维度进行合并。

当我们用英文或者url等复杂的字符串来作为维度的取值时，那么长一串确实不太合适，我们可以在设置维度时增加正则匹配，比如针对url就默认匹配它的站点值当维度的取值，针对如os这种可能需要翻译成英文的维度，可以定义一个map来将英文转为中文显示在可视化界面中。

如何快速打点

关于快速打点，内容有点多，之后会再出一篇文章详细介绍。

总结

看完这篇文章，相信你心里对前端监控系统的搭建也有自己的理解，希望能给你带来一些启示。

此文章只是简单地概括一下搭建前端监控系统的步骤，并不涉及具体的代码，更多具体的解决方案未来会在更多文章中体现，可以关注一下呀！

原文链接：https://juejin.cn/post/7151590970889338893，欢迎关注掘金账号~！

Node 社群


我组建了一个氛围特别好的 Node.js 社群，里面有很多 Node.js小伙伴，如果你对Node.js学习感兴趣的话（后续有计划也可以），我们可以一起进行Node.js相关的交流、学习、共建。下方加 考拉 好友回复「Node」即可。

如果你觉得这篇内容对你有帮助，我想请你帮我2个小忙：

1. 点个「在看」，让更多人也能看到这篇文章2. 订阅官方博客 www.inode.club 让我们一起成长

点赞和在看就是最大的支持❤️