如何提升前端线上问题发现率？我们是这样做的

最新推荐文章于 2024-08-15 09:35:48 发布

winty~~

最新推荐文章于 2024-08-15 09:35:48 发布

阅读量442

点赞数

文章标签：大数据编程语言人工智能数据分析 java

原文链接：https://mp.weixin.qq.com/s?__biz=MzI0MzIyMDM5Ng==&mid=2649841704&idx=2&sn=4b6defe0af566c31575fd2eef82042de&chksm=f175aaebc60223fd39f057d87b19c02819694e72c08eb435c319bc399841be38e4d2594efc79&scene=126&&sessionid=0

版权

过去一年，淘系前端对监控做了统一接入和覆盖，但是前端的故障发现率和问题发现率还是较低。FY21 归属淘系前端或与之相关的故障均为人工发现。如何提升线上问题发现率，是当前最优先需要解决的问题。

首先介绍下问题发现率的衡量方式。

什么是问题？

造成实际线上影响以及影响较小不够成故障定义，统称为问题。

问题发现率怎么统计？

对线上录入的问题、灰度回滚发现的问题以及紧急发布出现的问题作为问题的集合。

本篇文章将介绍对问题发现率的一些思考以及 JSTracker 平台 在前端监控的一些演进。【JSTracker平台，是端到端的前端监控与数据分析平台，主要专注在安全生产和体验度量方向】

背景

为了更好的分析当前问题，对线上录入的问题进行分类，可监控的问题主要划分为下面三类：

检测问题：页面白屏、空坑或者 undefined 等问题；
业务问题：需要业务在业务流程增加埋点才能发现的问题；
报警问题：流量下跌、新增错误日志等不支持报警订阅；
根据当前的问题分类，对线上典型的问题罗列了一些实际案例，具体如下：

通过当前的问题分类，我们对 2020 - 2021 年淘系录入的线上问题进行了统计分析，检测类未发现问题占比 7%，业务埋点缺监控占比 15%，报警能力未覆盖占比 7%，详细数据分布参考下图：

统计结果可以看出，当前问题发现率较低的原因主要包含三点：

检测能力覆盖不全
报警能力不足
业务监控点缺失

分析&思考

和业务开发对接过程发现，在监控的认知上和目标上还存在比较大的差距，大部分业务只是接入了监控 SDK ，订阅了一些基础指标，但是实际上大部分【前端问题】都很难通过常规的技术指标发现。

基于会引发线上问题的一些场景，我们在前端链路和前端监控指标做了下简单的分析。

链路分析

通常一个页面加载要经过下面五个节点，每个节点都可能会造成线上问题，具体如下：

入口配置下发：运营配置下发预发地址等问题
容器加载：小程序或者 WindVane 容器启动异常
源站资源：JS 资源、图片资源等加载异常
JS 执行：阻塞页面渲染或者功能执行失败
接口：数据不符合预期或者接口报错导致页面内容展示问题
上面的节点更多是造成问题的原因，但是用户只会在页面渲染和交互感知到问题：
页面渲染阶段：页面白屏、空坑、样式错乱等问题
页面交互阶段：功能不可用、页面抖动等一些问题

指标分析

从当前的监控视角来看，业务侧关注更多是一些技术指标，比如 JSError、Crash、接口等指标。通过技术指标的异常去分析异常原因。但是实际上技术指标可能和实际用户感知的问题没有指标关系，比如某个 JS 类型大量报错，但是实际上对业务没有影响，这就导致了当前的指标并不能真实反馈线上的情况。

基于页面链路分析和监控指标分析可以看出，业务侧需要关注【用户感知】出现的问题，这些问题关联的指标才可以真实反馈线上问题。因此在监控视角上，需要更加关注影响页面的【体验指标】。

通过【体验指标】的异常在去关联技术指标的异常，才是合理的问题发现和解决路径。因此我们需要从【体验指标】监控到【体验指标】监控的视角转化。

技术方案

通过上面问题背景分析可以看出，对于监控平台需要加强体验指标的检测能力、日志上报以及报警检测能力。因此我们将整体方案分为非预期渲染（白屏检测）、业务监控升级和报警监控升级三部分。

非预期渲染

JSTracker平台已经对接了 UC 内核采集的白屏数据，但是对于端外以及 iOS 场景等检测能力缺失。因此需要基于前端 SDK 发现页面无内容、错误页、首屏内模块丢失等问题，具体问题如下：

因此需要不依赖端的能力，通过在 SDK 采集页面信息，云上进行建模和统计计算，基于大数据分析来判断页面渲染是否符合预期，具体如下：

通过页面在不同阶段采集的页面的 DOM 节点数，不同的节点数量可对应到不同的页面渲染阶段，并在服务端统计收集到样本的分布情况，最后通过 DOM 的落点分布来判断页面渲染是否符合预期。

根据大数据统计分析结果，按照 DOM 节点数将采集日志划分为在预期和非预期节点，产品效果如下：

渲染状态发布：提供最近一小时的分布情况，红色代表非预期渲染分布，横坐标轴显示 DOM 节点数，纵坐标表示样本数
非预期异常率：按照 5 分钟的周期，对渲染的 DOM 的节点进行统计，计算非预期渲染异常率

业务监控

业务监控的目的是为了更好真实反馈和衡量业务的监控情况。以下单业务为例，不管是页面下单功能不可用还是服务端接口调用失败，最终影响的是下单成功率。

当前自定义埋点在业务场景支持上存在很多缺陷，比如日志上报规范缺失、字段扩展性缺失以及平台能力较弱，导致业务场景的监控诉求覆盖不全，针对这些问题做了能力升级，具体方案如下：

SDK 层，将核心逻辑提取封装成 jstracker-core 库，并对 sdk-assests 和 universal-tracker 进行兼容，对外提供统一上报接口
平台侧，增加指标维度扩展、自定义属性能力以及自定义错误率（成功率）能力。并新增业务监控管理页，对原有的业务监控信息展示页进行了优化
基于当前业务监控能力，以H5首页为例，我们做了业务监控的最佳实践。具体效果如下：

从 H5 的业务视角来看，核心要保障的区块是广告焦点图、轮播组件和导航组件，对于监控需要关注的指标是：
焦点图：广告图片曝光异常的数据比例
轮播组件坑位：核心指标是点击数据，坑位点击日志数和点击率的数据
导航组件坑位：和轮播组件一样，关注的是导航坑位点击日志数和点击率的数据
为了更好支撑业务监控的诉求，在产品侧做了能力升级：
业务扩展能力：自定义维度字段，可以自定义多维筛选能力以及自定义扩展字段，按照扩展字段聚合统计日志分布占比
自定义指标能力：支持业务自定义错误率、耗时等能力，比如错误率可以按照页面采集的 PV 计算或者自定义 PV 指标

报警监控

非预期渲染和业务监控，都是在解决【体验指标】采集以及检测的问题。报警监控需要提供合理的报警方案来提升指标报警的有效性。

当前前端存在很多碎片化的环境，比如系统不同版本、客户端多个版本以及上下游依赖关系复杂，比如运营配置了预发地址，导致页面流量下跌等。在复杂环境背景前提下，不同的业务场景需要设置不同的报警方案。具体方案如下：

报警维度: 碎片化的场景出现的问题，可以对监控指标在前端版本、客户端版本、浏览器版本等做细分维度监控
报警策略: 应对不同的业务监控诉求，需要丰富报警规则能力，可以对阈值、错误率、同比、环比等配置报警规则
报警方案: 不同的监控场景可以按照不同的报警方案订阅。在灰度发布的业务，关注的是新增的错误日志的报警；业务场景非常复杂，推荐根据自己的业务场景设定符合自己业务需要的报警规则，增加报警有效率