呀!原来这就是前端监控系统_前端监控平台
原文来源于：IQ前端 ，作者：PlutoLam
原文：
https://juejin.cn/post/7151590970889338893如有侵权，联系删除
在刚开始学前端的时候，那时候开发的应用总是在用户的设备中出现一些报错，开发者只知道这个型号的设备出现这个问题，但对其他信息却全然不知，比如说其他操作系统、其他设备型号、其他页面会有这个报错吗，这个报错出现的频率又是多少。每次出问题只能等待用户反馈，不能第一时间去解决问题，甚至用户没反馈的话永远也无法发现某些报错。
后来了解到前端监控这个东西，才知道原来可以这样去监控用户设备上的应用。“前端监控”不单单包括web性能和JS异常的监听，还包括处理日志的平台。下面就来总结一下打造一个完整的前端监控系统的过程。
了解业务需求
首先要了解自己所在的团队或者公司的具体需求。
- 如果是一个小团队，可能只需要简单的几个数据即可，业务也只有一两种，这样的话整个系统会简单很多，不用划分很多模块
- 如果是中厂或者大厂，很多个前端部门都需要用到这个平台，那么就需要划分成很多模块，而且需要很多通用的特性（比如说维度，下面会讲到）
了解完这个产品覆盖的范围后，就要开始调查开发者们需要在用户手机中需要收集的数据，根据这些字段设计日志的数据结构和数据库的设计
这里提到的数据可以包含以下几个点和无数小点
- 性能统计
- 基础数值（首次渲染时间、白屏时间等）
- 可交互（首次加载时页面卡顿、操作时的js加载情况等）
- 资源（包括资源大小和资源的加载时间）
- 异常统计
- JS异常
- ajax异常
- 资源文件
其中大点需要一开始就确定，大点下面的小点我把他成为分组，分组可以被每个业务方根据自己的业务自定义，这样可以极大增加系统的灵活性。
确定日志格式
- type：首先要有一个type字段区分日志的类型，value比如performance（性能统计），abnormal（异常统计），除了这两种比较常见的type，自己也可以根据团队或公司业务来拓展value。
- module：然后我们需要根据module字段区分各业务方，如商业研发部、基础架构部，考虑到部门的名字用英文表示太长且容易误会，可以用数字（分为前标和后标）映射来表示，如"1_1"表示商业研发部，"1_2"表示商业技术研发部，"2_1"表示基础架构部，按申请的部的顺序顺延，相同的大部门可以使用相同的“前标”，“后标”也可以表示不同的项目，这些都可以根据自己的部门自定义。
- group：使用group表示分组，比如可以将一个项目中不同的落地页分成不同的组，将一个落地页中不同的组件分为不同组，还是根据自己的业务自行调整。
- dim：即dimension维度，这个比较重要，简单说就是将每个数据都分为多个模块来统计，常见的dim如操作系统（Android or iOS）、浏览器类型、是否落地页、网络类型等等。
- info：性能或异常的具体信息，一个“大点”中的info要求一样，这样方便统计，如异常统计的info可以分为“异常信息”、“异常时间”、“异常类型”、“具体的异常位置（行数）”。还包括一些诸如操作系统和浏览器类型的公共信息。
数据结构如下
{
type: String,
module: String,
group: String,
dim: {
// 各个维度的信息
},
info: {
// 具体信息
}
}打造日志接收平台
- 接收日志的接口可以设置在前端监控平台的server端，暴露一个接口即可，通过type来调用不同的处理函数。
- 可以同时接收get请求和post请求。
- 支持get请求主要是方便发送日志，只需要把日志信息转为query放在url后面就可以发送，后面会出具体的教程。
- 支持post请求是因为可以支持sendBeacon的post请求，可以优先采用，该api可以在会话结束后发送打点日志，降低打点丢失率。
在发送和接收日志的时候有几点要注意的
- 若此网站的用户访问量很大，频繁地发送日志会造成server端的压力很大，可以参考一下以下两个解决方法。
- 前端发送日志时抽样发送。
const randomNum = Math.random();
if(randomNum < 0.1) { // 设置10%的抽样
send() // 发送日志
}- 前端可以将数据临时保存在Storage中并合并起来，隔一段时间发送一次日志（类似节流）。
- 受网络和设备老化的影响，有一些数据并不能反映网站的性能，这时候可以过滤极值来保证数据的可靠性。
- 即使抽样检测，日志数据依旧十分庞大，server端可以暴露一个delete的接口，服务器自动删除老数据。
监控平台
监控平台主要包括可视化和异常报警两个方面。
可视化
- 我们收集数据的一大目的就是为了方便地观察数据的趋势变化，可以结合表格、柱状图、饼图、折线图来展示。通过选择分组和维度、日期来观察不同状态下的数据。这点和普通的管理系统并无两样。
- 为了观察数据随时间的变化，我们可以以小时、天、周来定义时间颗粒度，设置一个对比模式来比较不同时间颗粒度的数据，包括环比和上升下降值。
- 自定义设置时间间隔区间，观察指定区域内的数据。
异常报警
顾名思义，异常报警就是当项目中某些异常的数量跟用户设置的模式一致时，就会自动触发报警，异常报警可以从以下几个方面考虑。
- 支持小时级、天级选项，在小时级里面支持前后小时、上一天和当前天的同一小时、上一周和当前周的同一小时内的数据的对比；在天级里面支持上一天和当前天、上一周的同一天和当前天的数据的对比。
- 数据对比时支持环比（百分比）、数量的增减，支持大于、大于等于、小于、小于等于等比较方式，可以根据部门的业务情况来定义。
- 可以设置当前报警人的手机号或邮箱，还可以设置邮箱组，触发报警时发送短信或邮件。
- 暴露一个触发报警的接口，服务器按时请求该接口。
维度
在前端监控系统中维度是一个重要的概念，而自定义维度更能体现系统的自由度，他可以针对不同的业务自定义一套专属的维度划分，并且可以通过比较不同的维度情况去理解项目。自定义维度可以让这套系统覆盖绝大部分的业务统计需求。
怎么设计维度
比如说B站的首页，性能指标可以有“顶部banner的视频加载时间”、“首屏加载时间”、“后端数据加载时间”，当我们查看这几个指标时，我们可能想对比一下未登录状态和已登录状态的指标，又或者想区分一下进入点是哪里（是从搜索结果页点进来的还是从其他地方进来），还可能想看一下有缓存状态和无缓存状态的指标区别。
这样就确定了三个维度，登录状态、进入点、缓存状态。
确定维度后就可以确定维度的取值，进入点可以取三个值：直接输入url、搜索结果页点进、其他，登录状态和缓存状态都是两个值，每个维度的每个取值可以组成一个组合，这样的话总共有12种组合，也就是说可以看到这个页面12种情况下的指标情况。如果你发现此页面有一些性能问题，但是又排查不出来，可以试着尝试不同的维度组合，最后发现在已登录和未登录两种状态之间的数值相差很大，那么就可以定点排查登录模块的问题。
但是维度的组合太多不一定是好事，比如12个组合，发送一次打点，数据库就会存入12条数据，如果是小时级的一天就会存入12×24条数据，若是维度组合数太多，就会非常浪费数据库资源，所以在自定义维度时需要按需设置。
所以避免打点的时候维度组合太多将系统搞崩溃，发送打点日志之前需要先配置维度信息，发送日志时会将维度和配置好的维度进行diff，如果有diff，则视为攻击，放弃这个日志数据。
维度提取
像操作系统os、浏览器类型这种取值太多了，一般不会直接作为维度，但是像移动端的操作系统只有ios、Android、other就可以直接作为默认维度，在解析日志时可以自动解析出当前站点、移动os、cookie、http类型等数据，并与自定义的维度进行合并。
当我们用英文或者url等复杂的字符串来作为维度的取值时，那么长一串确实不太合适，我们可以在设置维度时增加正则匹配，比如针对url就默认匹配它的站点值当维度的取值，针对如os这种可能需要翻译成英文的维度，可以定义一个map来将英文转为中文显示在可视化界面中。
如何快速打点
关于快速打点，内容有点多，之后会再出一篇文章详细介绍。
总结
看完这篇文章，相信你心里对前端监控系统的搭建也有自己的理解，希望能给你带来一些启示。
此文章只是简单地概括一下搭建前端监控系统的步骤，并不涉及具体的代码，更多具体的解决方案未来会在更多文章中体现，可以关注一下呀！