在刚开始学前端的时候,那时候开发的应用总是在用户的设备中出现一些报错,开发者只知道这个型号的设备出现这个问题,但对其他信息却全然不知,比如说其他操作系统、其他设备型号、其他页面会有这个报错吗,这个报错出现的频率又是多少。每次出问题只能等待用户反馈,不能第一时间去解决问题,甚至用户没反馈的话永远也无法发现某些报错。
后来了解到前端监控这个东西,才知道原来可以这样去监控用户设备上的应用。“前端监控”不单单包括web
性能和JS异常的监听,还包括处理日志的平台。下面就来总结一下打造一个完整的前端监控系统的过程。
了解业务需求
首先要了解自己所在的团队或者公司的具体需求。
- 如果是一个小团队,可能只需要简单的几个数据即可,业务也只有一两种,这样的话整个系统会简单很多,不用划分很多模块
- 如果是中厂或者大厂,很多个前端部门都需要用到这个平台,那么就需要划分成很多模块,而且需要很多通用的特性(比如说维度,下面会讲到)
了解完这个产品覆盖的范围后,就要开始调查开发者们需要在用户手机中需要收集的数据,根据这些字段设计日志的数据结构和数据库的设计
这里提到的数据可以包含以下几个点和无数小点
- 性能统计
a. 基础数值(首次渲染时间、白屏时间等)
b. 可交互(首次加载时页面卡顿、操作时的js加载情况等)
c. 资源(包括资源大小和资源的加载时间)
2. 异常统计
a. JS异常
b. ajax异常
c. 资源文件
其中大点需要一开始就确定,大点下面的小点我把他成为分组,分组可以被每个业务方根据自己的业务自定义,这样可以极大增加系统的灵活性。
确定日志格式
- 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
来将英文转为中文显示在可视化界面中。
如何快速打点
关于快速打点,内容有点多,之后会再出一篇文章详细介绍。
总结
看完这篇文章,相信你心里对前端监控系统的搭建也有自己的理解,希望能给你带来一些启示。
此文章只是简单地概括一下搭建前端监控系统的步骤,并不涉及具体的代码,更多具体的解决方案未来会在更多文章中体现,可以关注一下呀!
今天的文章呀!原来这就是前端监控系统分享到此就结束了,感谢您的阅读。
版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。
如需转载请保留出处:https://bianchenghao.cn/21665.html