前端监控体系搭建怎么做

标签: 前端 监控 体系 | 发表时间:2021-12-28 14:16 | 作者:被删
出处:https://juejin.cn/tag/%E6%9E%B6%E6%9E%84

本文已参与「新人创作礼」活动,一起开启掘金创作之路。

整理了下前端监控的一些项目经验,结合自己的想法输出了这篇文章,跟大家分享下。

前端监控体系搭建

通常前端建立搭建监控体系,主要是为了解决两个问题: 如何及时发现问题如何快速定位并解决问题

一般来说,结合开发和产品的角度来看,前端监控体系需要做的事情包括:

  1. 页面的整体访问情况,包括常见的 PV、UV、用户行为上报。
  2. 页面的性能情况,包括加载耗时、接口耗时统计。
  3. 灰度发布与有效的监控能力,方便及时发现问题。
  4. 用户反馈问题,需要足够的日志定位问题。

这些问题可以从两个角度来解决: 数据收集数据上报

数据收集

要进行有效地监控,首先我们需要将监控数据进行上报。传统的页面开发过程中,系统的质量通常从三方面来评估,针对页面的监控和数据采集也分别从这些方面来进行:

  • 页面访问速度
  • 页面稳定性/异常
  • 外部服务调用情况

异常收集

首先,我们需要收集项目运行过程中的一些错误,因为一般来说脚本执行异常很可能会直接导致功能不可用。当 HTML 文档执行异常时,我们可以通过 window.onerrordocument.addEventlistener(error)XMLHttpRequest status等方法拦截错误异常。例如,通过监听 window.onerror事件,我们可以获取项目中的错误和分析堆栈,将错误信息自动上报到后台服务中。

常见的前端异常包括:

  • 逻辑错误:开发实现功能的时候,逻辑梳理不符合预期
    • 业务逻辑判断条件错误
    • 事件绑定顺序错误
    • 调用栈时序错误
    • 错误的操作 js 对象
  • 代码健壮性:代码边界情况考虑不周,异常逻辑执行出错
    • 将 null 视作对象读取 property
    • 将 undefined 视作数组进行遍历
    • 将字符串形式的数字直接用于加运算
    • 函数参数未传
  • 网络错误:用户网络情况异常、后台服务异常等错误
    • 服务端未返回数据但仍 200,前端按正常进行数据遍历
    • 提交数据时网络中断
    • 服务端 500 错误时前端未做任何错误处理
  • 系统错误:代码运行环境兼容性问题、内存不够用等问题导致出错
  • 页面内容异常:缺少内容、绑定事件异常、样式异常

生命周期数据

生命周期包括页面加载的关键时间点,常常包括页面打开、更新、关闭等耗时数据。

一般来说,我们可以通过 PerformanceTiming 属性获取到一些生命周期相关的数据,包括:

  • PerformanceTiming.navigationStart:当前浏览器窗口的前一个网页关闭,发生 unload 事件时的时间戳
  • PerformanceTiming.domLoading:返回当前网页 DOM 结构开始解析时(即 Document.readyState属性变为“loading”、相应的 readystatechange事件触发时)的时间戳
  • PerformanceTiming.domInteractive:返回当前网页 DOM 结构结束解析、开始加载内嵌资源时(即 Document.readyState属性变为“interactive”、相应的 readystatechange事件触发时)的时间戳
  • PerformanceTiming.domComplete:返回当前文档解析完成(即 Document.readyState变为"complete"且相对应的 readystatechange)被触发时的时间戳
  • PerformanceTiming.loadEventStart:返回该文档下,load 事件被发送时的时间戳
  • PerformanceTiming.loadEventEnd:返回当 load 事件结束,即加载事件完成时的时间戳

除此之外,当初始的 HTML 文档被完全加载和解析完成之后, DOMContentLoaded事件被触发,而无需等待样式表、图像和子框架的完全加载。由于前端框架的出现,很多时候页面的渲染交给框架来控制,因此 DOMContentLoaded事件已经失去了原本的作用,很多时候我们会在框架本身提供的生命周期函数中进行数据的收集。

我们还可以使用 MutationObserver接口,该提供了监听页面 DOM 树变化的能力,结合 performance获取到具体的时间:

  // 注册监听函数
const observer = new MutationObserver((mutations) => {
  console.log(`时间:${performance.now()},DOM树发生了变化!有以下变化类型:`);
  for (let i = 0; i < mutations.length; i++) {
    console.log(mutations[0].type);
  }
});
// 开始监听document的节点变化
observer.observe(document, {
  childList: true,
  subtree: true,
});

HTTP 测速数据

请求相关的数据,我们同样可以通过 PerformanceTiming 属性获取:

  • PerformanceTiming.redirectStart:返回第一个 HTTP 跳转开始时的时间戳
  • PerformanceTiming.redirectEnd:返回最后一个 HTTP 跳转结束时(即跳转回应的最后一个字节接受完成时)的时间戳
  • PerformanceTiming.fetchStart:返回浏览器准备使用 HTTP 请求读取文档时的时间戳,该事件在网页查询本地缓存之前发生
  • PerformanceTiming.domainLookupStart/ PerformanceTiming.domainLookupEnd:返回域名查询开始/结束时的时间戳
  • PerformanceTiming.connectStart:返回 HTTP 请求开始向服务器发送时的时间戳
  • PerformanceTiming.connectEnd:返回浏览器与服务器之间的连接建立时的时间戳,连接建立指的是所有握手和认证过程全部结束
  • PerformanceTiming.secureConnectionStart:返回浏览器与服务器开始安全链接的握手时的时间戳
  • PerformanceTiming.requestStart:返回浏览器向服务器发出 HTTP 请求时(或开始读取本地缓存时)的时间戳
  • PerformanceTiming.responseStart:返回浏览器从服务器收到(或从本地缓存读取)第一个字节时的时间戳
  • PerformanceTiming.responseEnd:返回浏览器从服务器收到(或从本地缓存读取)最后一个字节时(如果在此之前 HTTP 连接已经关闭,则返回关闭时)的时间戳

通过这些数据,我们可以观察后端服务是否稳定、是否还有优化空间。

用户行为数据

除了常见的前端页面加载、请求耗时数据,我们还可以关注用户的一些行为数据,包括页面浏览量或点击量、用户在每一个页面的停留时间、用户通过什么入口来访问该页面、用户在相应的页面中触发的行为。用户行为数据可以通过一些 DOM 元素的操作事件来获取。

这些数据通常用来统计分析用户行为,来针对性调整页面功能、更好地发挥页面的作用。同时,我们还可以通过一些用户交互数据,来观测系统功能是否正常。

用户日志

系统出现异常的时候,通常使用日志进行定位。日志的存储通常包括两种方案:

  1. 上报到服务器。由于日志内容很多,如果全量上报到服务器会导致存储成本过大,同时频繁的上报也会增加接口的维护成本。除此之外,由于网络原因等还可能导致部分或全部的日志丢失等问题。
  2. 本地存储。该方案需要引导用户手动操作提交本地日志,才可以定位到具体异常出现的位置。如果无法联系到用户,则可能由于异常无法重现而无法修复。

日志通常用户定位用户问题的时候使用,但我们常常需要提前在代码中打印日志。否则,当我们需要定位问题的时候,才发现自己并没有输出相关的日志,有些问题由于复现困难,再补上日志发布后也未必能复现,这样就会比较被动。

可以通过全局挟持关键模块和函数等方式来进行日志的自动打印,举个例子:

在每个功能模块运行时,通过使用约定的格式来打印输入参数、执行信息、输出参数,则可以通过解析日志的方式,梳理本次操作的完整调用关系、功能模块执行信息:

埋点方案

前端常见的埋点方案包括三种:

- 代码埋点 可视化埋点 无痕埋点
使用方式 手动编码 可视化圈选 嵌入 SDK
自定义数据 可自定义 较难自定义 难以自定义
业界成熟产品 友盟、百度统计等第三方数据统计服务商 Mixpanel GrowingIO
更新代价 需要版本更新 需要下发配置 不需要
使用成本

无痕埋点一般是通过上述数据采集中使用的一些 API 来进行数据的采集,但由于无痕埋点的自定义能力很弱,通常我们可以配合代码埋点的方式进行。

标准化埋点数据

不管是哪种埋点方式,我们都需要对它们进行标准化处理。一般来说,通过和后台约定好具体的参数,然后前端在埋点采集的时候,自动转换成接口需要的一些数据格式进行本地存储。

通过这些行为信息,可以实时计算出每个用户在时间轴上的操作顺序,以及每个步骤的操作时间、操作内容等,通过可视化系统直观地展示用户的链路情况,包括系统的入口来源、打开或关闭的页面、每个功能点的点击和操作时间、功能异常的情况等。

使用标准化的方式获取用户点击流以及页面使用情况,将页面和每个功能的操作行为上报到服务器,实时对操作时间、操作名称等信息来分析得到用户的操作链路、每个页面和功能操作步骤间的耗时和转化率,并进行有效监控。通过该方式,可以高效直观地观察产品的使用情况、分析用户的行为习惯,然后确定产品方向、完善产品功能。

数据上报

数据采集完成后,我们需要将这些数据上报到后台服务:

如图,当页面打开、更新、关闭等生命周期、用户在页面中的操作行为、系统异常等触发时,系统底层通过埋点监听这些事件,获取相关数据数据并进行标准化处理后,进行本地收集然后上报到实时数据分析系统。

相关的数据信息包括时间、名称、会话标记、版本号等信息,通过这些数据,可以实时计算出每个埋点的使用数量、埋点间的执行时间、埋点间的转换率等,通过可视化系统直观地展示完整的页面使用情况,包括每个页面打开、更新、关闭情况、每个功能点的点击和加载情况、功能异常的情况等。

上报方式

一般来说,我们埋点的数据、运行的日志都需要通过上报发送到后台服务再进行转换、存储和监控。

批量上报

对于前端来说,过于频繁的请求可能会影响到用户其他正常请求的体验,因此通常我们需要将收集到的数据存储在本地。当收集到一定数量之后再打包一次性上报,或者按照一定的频率(时间间隔)打包上传,打包上传将多次数据合并为一次,可以减轻服务器的压力。

关键生命周期上报

由于用户可能在使用过程中遇到异常,或者在使用过程中退出,因此我们还需要在异常触发的时候、用户退出程序前进行上传,以避免问题没能及时发现和定位。

用户主动提交

一些异常和使用体验问题,我们会给用户提供主动上传的选项。当用户经过引导后进行上传的时候,我们则可以将本地的数据和日志一并进行提交。

数据监控

数据上报完成后,我们需要搭建管理端对这些数据进行有效的监控,主要包括三部分的数据:

  • 性能监控
    • 网页加载性能
    • 网络请求性能
  • 异常监控
    • JS Error
  • 数据监控
    • 页面 PV/UV
    • 页面来源

日常监控中,我们可以通过对这些监控数据配置告警阈值等方式,结合邮件、机器人等方式推送到相关的人员,来及时发现并解决问题。

发布过程监控

多人协作的项目,由于每次发版都会把好几个小伙伴开发的功能一起合并发布,人工保证功能的正确是很低效的,人工测试也不一定能覆盖到很完整的功能、自动化测试也常常因为性价比等问题无法做得很完善。所以除了自动化测试、改动相关的功能自测之外,我们上报过程会带上每次的版本号,同时可以根据版本来观察新版本的曲线情况,在灰度过程也需要小心注意观察:

  • 小程序错误告警是否有新增错误,可通过错误内容找到报错位置修复
  • 全版本监控观察:整体的功能点覆盖曲线是否正常,是否有异常涨跌
  • 分版本监控观察:功能是否覆盖完整、灰度占比是否正常、新旧版本的转化率是否一致

在灰度发布过程中,我们就能通过上报数据功能曲线是否正常、异常是否在预期范围、曲线突变跟灰度时间点是否吻合等,来确认是否有异常、哪里可能有异常。当出现数据异常的时候,可配合相应的告警渠道来及时通知相应的负责人,及时修复功能异常。

结束语

很多时候,前端项目中都会进行一些异常、耗时测速等监控,也会进行一些用户行为的数据上报。其实我们还可以思考将这些过程更加自动化地实现,同时数据在上报之后还可以进行筛选、统计、转换,计算出产品各种维度的使用情况,甚至还可以做全链路监控、或是给到一些实用的产品方向引导。

相关 [前端 监控 体系] 推荐:

前端监控体系搭建怎么做

- - 掘金 架构
本文已参与「新人创作礼」活动,一起开启掘金创作之路. 整理了下前端监控的一些项目经验,结合自己的想法输出了这篇文章,跟大家分享下. 通常前端建立搭建监控体系,主要是为了解决两个问题: 如何及时发现问题、 如何快速定位并解决问题. 一般来说,结合开发和产品的角度来看,前端监控体系需要做的事情包括:.

前端性能监控系统ShowSlow

- - CSDN博客Web前端推荐文章
作者:zhanhailiang 日期:2014-11-14. ShowSlow是开源的前端性能监控系统,提供了以下功能:. 前端性能指标数据收集功能:ShowSlow原生提供了数据收集工具. DOM Monster!,但也支持通过YSlow,PageSpeed等第三方工具将性能数据上报给服务端完成收集(其服务器端提供了针对多达8种不同工具上报的数据收集器dommonster,dynatrace,events,har,metric,pagespeed,webpagetest,yslow);.

搭建前端异常监控系统

- - 掘金 架构
收集前端错误(原生、React、Vue). 利用Egg.js编写一个错误日志采集服务. 编写webpack插件自动上传sourcemap. 利用sourcemap还原压缩代码源码位置. 代码上线打包将sourcemap文件上传至错误监控服务器. 发生错误时监控服务器接收错误并记录到日志中. 根据sourcemap和错误日志内容进行错误分析.

前端监控系统设计

- - 掘金 前端
前言: 创建一个可随意插拔的插件式前端监控系统. 使用window.addEventListener('error',cb). 由于这个方法会捕获到很多error,所以我们要从中筛选出静态资源文件加载错误情况,这里只监控了js、css、img. // 捕获静态资源加载失败错误 js css img window.addEventListener('error', e => {.

Web前端知识体系精简

- - IT瘾-geek
Web前端技术由html、css和javascript三大部分构成,是一个庞大而复杂的技术体系,其复杂程度不低于任何一门后端语言. 而我们在学习它的时候往往是先从某一个点切入,然后不断地接触和学习新的知识点,因此对于初学者很难理清楚整个体系的脉络结构. 本文将对Web前端知识体系进行简单的梳理,对应的每个知识点点到为止,不作详细介绍.

监控平台前端SDK开发实践

- - 美团点评技术团队
监控是提高故障处理能力和保障服务质量必需的一环,它需要负责的内容包括:及时上报错误、收集有效信息、提供故障排查依据. 及时上报错误:发生线上问题后,经由运营或者产品反馈到开发人员,其中流转过程可能是几分钟甚至几十分钟,这段时间可能直接导致公司的经济损失. 如果有一个监控系统,在线上出现问题时,监控系统能够第一时间报警,并且通知到开发人员,那开发人员就可以第一时间修复上线,使公司损失最小化.

前端异常监控解决方案研究

- - 腾讯CDC
前端监控包括行为监控、 异常监控、性能监控等,本文主要讨论异常监控. 对于前端而言,和后端处于同一个监控系统中,前端有自己的监控方案,后端也有自己等监控方案,但两者并不分离,因为一个用户在操作应用过程中如果出现异常,有可能是前端引起,也有可能是后端引起,需要有一个机制,将前后端串联起来,使监控本身统一于监控系统.

前端监控实践——FMP的智能获取算法

- - SegmentFault 最新的文章
今天来给大家介绍下前端监控中一个特定指标的获取算法,有人会问,为啥就单单讲一个指标. 这是因为,目前大部分的指标,比如白屏时间,dom加载时间等等,都能通过现代浏览器提供的各种api去进行较为精确的获取,而今天讲的这个指标,以往获取他的方式只能是通过逻辑埋点去获取它的值,因此在做一些前端监控时,需要根据业务需要去改变页面对这个值的埋点方式,会比较繁琐,恰巧最近刚刚好在做一些前端监控相关的项目,遇到这个问题时就在想,能不能通过一种无须埋点的方式,将这个值给获取到.

为什么前端监控要用 GIF 打点

- - IT瘾-tuicool
为什么前端监控要用GIF打点?. 我们知道,目前主流的前端监控(百度统计/友盟/谷歌统计)都在用GIF进行打点. 但是,为什么这些系统都会使用GIF,难道是因为没有其他的解决方案吗. 所谓的前端监控,其实是在满足一定条件后,由Web页面将用户信息(UA/鼠标点击位置/页面报错/停留时长/etc)上报给服务器的过程.

前端异常监控解决方案研究

- - IT瘾-dev
摘要:异常监控不复杂也不简单啊…. 作者:frustigor. 前端监控包括行为监控、 异常监控、性能监控等,本文主要讨论异常监控. 对于前端而言,和后端处于同一个监控系统中,前端有自己的监控方案,后端也有自己等监控方案,但两者并不分离,因为一个用户在操作应用过程中如果出现异常,有可能是前端引起,也有可能是后端引起,需要有一个机制,将前后端串联起来,使监控本身统一于监控系统.