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

·  阅读 25749
呀!原来这就是前端监控系统

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

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

了解业务需求

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

  • 如果是一个小团队,可能只需要简单的几个数据即可,业务也只有一两种,这样的话整个系统会简单很多,不用划分很多模块
  • 如果是中厂或者大厂,很多个前端部门都需要用到这个平台,那么就需要划分成很多模块,而且需要很多通用的特性(比如说维度,下面会讲到)

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

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

  1. 性能统计
a.  基础数值(首次渲染时间、白屏时间等)
b.  可交互(首次加载时页面卡顿、操作时的js加载情况等)
c.  资源(包括资源大小和资源的加载时间)
复制代码

2. 异常统计

a.  JS异常
b.  ajax异常
c.  资源文件
复制代码

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

确定日志格式

  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可以分为“异常信息”、“异常时间”、“异常类型”、“具体的异常位置(行数)”。还包括一些诸如操作系统和浏览器类型的公共信息。

数据结构如下

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

打造日志接收平台

  • 接收日志的接口可以设置在前端监控平台的server端,暴露一个接口即可,通过type来调用不同的处理函数。
  • 可以同时接收get请求和post请求。
  • 支持get请求主要是方便发送日志,只需要把日志信息转为query放在url后面就可以发送,后面会出具体的教程。
  • 支持post请求是因为可以支持sendBeaconpost请求,可以优先采用,该api可以在会话结束后发送打点日志,降低打点丢失率。

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

  1. 若此网站的用户访问量很大,频繁地发送日志会造成server端的压力很大,可以参考一下以下两个解决方法。
  • 前端发送日志时抽样发送。
const randomNum = Math.random();
if(randomNum < 0.1) {  // 设置10%的抽样
  send()  // 发送日志
}
复制代码
  • 前端可以将数据临时保存在Storage中并合并起来,隔一段时间发送一次日志(类似节流)。
  1. 受网络和设备老化的影响,有一些数据并不能反映网站的性能,这时候可以过滤极值来保证数据的可靠性。
  2. 即使抽样检测,日志数据依旧十分庞大,server端可以暴露一个delete的接口,服务器自动删除老数据。

监控平台

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

可视化

  1. 我们收集数据的一大目的就是为了方便地观察数据的趋势变化,可以结合表格、柱状图、饼图、折线图来展示。通过选择分组和维度、日期来观察不同状态下的数据。这点和普通的管理系统并无两样。
  2. 为了观察数据随时间的变化,我们可以以小时、天、周来定义时间颗粒度,设置一个对比模式来比较不同时间颗粒度的数据,包括环比和上升下降值。
  3. 自定义设置时间间隔区间,观察指定区域内的数据。

异常报警

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

  1. 支持小时级、天级选项,在小时级里面支持前后小时上一天和当前天的同一小时上一周和当前周的同一小时内的数据的对比;在天级里面支持上一天和当前天上一周的同一天和当前天的数据的对比。
  2. 数据对比时支持环比(百分比)、数量的增减,支持大于大于等于小于小于等于等比较方式,可以根据部门的业务情况来定义。
  3. 可以设置当前报警人的手机号或邮箱,还可以设置邮箱组,触发报警时发送短信或邮件。
  4. 暴露一个触发报警的接口,服务器按时请求该接口。

维度

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

怎么设计维度

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

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

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

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

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

维度提取

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

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

如何快速打点

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

总结

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

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

分类:
前端
标签:
收藏成功!
已添加到「」, 点击更改