阅读 56

为你的前端页面量身打造一套实时监控指标

背景

今年年初,我进入一个基于React开发的新项目,负责整个前端的开发工作。为了保证整体的质量和用户体验,我们需要在项目上线时对应用进行稳定性和性能监控,确保线上发现异常时能够被第一时间发现和解决。

工欲善其事,必先利其器,这时候我们需要一个好轮子。对于前端页面的监控,通常包括页面的访问性能、页面JS错误、资源加载错误,以及后端API的请求情况。

UC研发效能团队有一个叫做【岳鹰】的WEB高可用监控产品,支持H5、小程序、Flutter监控,监控指标比较齐全,而且支持线上海量访问的实时监控,于是决定试用一把。

下面我就讲讲我怎么在新项目里面设定业务的性能/体验指标,并且通过监控工具来分析、优化最终达成目标。

Step01,一行代码搞定前端监控

体验【岳鹰】的Demo项目,大概了解岳鹰提供的监控和分析功能,我比较关心的功能都具备:

  • 页面性能监控,而且支持性能趋势 + 性能数据样本分布,对于分析长尾的慢访问比较有帮助
  • JS错误监控,并且支持source map还原,查看线上混淆的错误代码很方便
  • API错误监控,很多时候接口错误也会导致前端报错,支持API错误码、响应内容很重要

并且,接入也很简单,一行代码就可以完成。 下面是岳鹰的前端监控功能截图,有兴趣可以看看。

Step02,发现线上性能问题

接入【岳鹰】之后,可以随时查看项目的线上访问性能,JS错误之类也会实时报警,真的是心中有数啊;心里只有一个字,【稳】。

但是项目上线一周之后,开始收到客服反馈的问题,有不少用户反馈页面打开页面比较慢、裂图(由于我这个项目是海外的活动运营业务,页面内容包含一些运营和动画图片,看不了图片是很致命的体验问题)。

收到问题反馈之后,第一时间就想要看看线上的实际情况,看能否找到问题根因。而从岳鹰平台展示的实际页面性能,页面的加载速度其实并不差,页面加载耗时均值在1S左右(做过海外应用的同学应该知道这个性能不差了)。

研究了【岳鹰】页面性能指标的采集算法,发现页面性能的统计是 loadEventStart - fetchStart ,对于我使用React的这个项目,页面主流程基本都是在 load 之前之后,因此并不能很好的反映真实性能情况。

自己动手丰衣足食,这时候就需要自己来做页面加载流程的耗时统计了。那岳鹰支持用户自己上报埋点吗?一看还真支持。

Step03,自定义监控解决问题

【自定义监控】按照自定义监控协议上报即可实现一个新的监控指标,可用于业务错误、业务关键节点等监控场景。

这是自定义监控的官方介绍,刚好满足我的监控需求。简单看下岳鹰自定义监控能力,支持以下几大类。

  • "次数"型监控

如:xx包下载失败次数、xxsdk初始化次数、xx按钮点击次数、xx签到异常次数...

  • "平均值"型的监控

如:xx文件加载耗时、xx业务页面初始化耗时、xx小程序启动耗时、xx组件包大小...

  • "率"型的监控

如:包下载成功\失败率、缓存命中率、页面唤起客户端成率...

  • 分组归类

如:监控多个包时,按包统计数据、小程序启动耗时、按小程序id统计数据...

  • 自定义区间分布

如:启动耗时在1-2s、2-5s的分布...

  • 业务自定义字段

上报一些用于辅助业务分析的字段,如:requestId、fileName...

支持上报,还要平台支持统计分析才行。和其他监控功能(如:JS异常、页面性能)一样,自定义监控也提供了趋势分析、维度分析、高级查询、报警等功能(内心一阵窃喜)。

监控项设计

这里结合我们的页面流程讲一下,对于用户访问页面有哪些关键的事件。

页面加载的第一步,会有一个过渡的 loading svg 动画,核心是首屏的3个模块,完成渲染即一个完整周期;也就是说,只有保证首屏3个模块成功加载,才能让用户体验到完整、流畅的页面。

页面流程示意如下。

基于这个页面流程,我设计了数据加载成功率、加载耗时这2个指标。利用岳鹰的自定义监控,我可以创建一个叫做「体感加载时长」的监控项,通过JS探针把这2个指标数据上报到平台去。 在确定数据采集时机之后,使用如下代码上报一条自定义数据。嗯,又是一行代码搞定,妥妥的。

  category: 100,
  msg: '体感加载时长',
  w_succ: 1,// 初始化数据成功,不成功是为0
  wl_avg1: 94 // end - start (ms)
})
复制代码

监控效果

每次版本迭代后,都可以在平台观察实时数据与汇总情况,实时了解用户对当前页面的直观等待感受及作为页面优化依据。对比上线第一版的页面性能数据,我通过自定义监控项把用户的真实访问耗时统计出来了,发现用户体感耗时3S+(我滴神。。)。

基于线上真实数据,才得以进一步优化把用户体感耗时降到1S左右。具体做的事情包括把一些不属于主流程的module放到首屏之后加载、大图片优化、JS裁剪等等(具体内容这里不展开了,有兴趣以后再发文介绍)。

  • 体感耗时趋势

  • 数据成功率趋势

除了上述监控指标,我们还利用自定义打点来记录script with module、vw css unit、intersectionObserver等特性的支持度(app是使用系统webview),以及一些其他的业务打点。

例如,在监控一段时间后发现 IntersectionObserver 实际支持程度达到 96%,根据这个线上结论,终于可以放心的把 100k 的 polyfill 重整为降级的替代方案。 类似的case还有很多,这里就不赘述了。总之,监控whatever you want!

总结:怎么为你的业务量身打造线上监控

在这个项目摸索的过程中,沉淀了一些经验,跟大家分享下我设计自定义监控的心得,大致有以下几种场景,以及结合岳鹰的使用技巧。

场景1:纯次数监控

如:监控某个(些)sdk初始化错误次数 如图5所示,创建监控项时,只需要填写监控项名称、得到监控项代码就可以了进行如下所示的打点监控了

wpk.report({
  category: 103, //平台创建时,生成的code
  msg: 'sdk1'
})
复制代码
 如果同时想监控多个sdk初始化项目,那么也无需创建多个监控项,直接把sdk的名称作为msg的值进行上报即可满足你的需求
复制代码

场景2:次数 + 耗时监控

如:某个重要的页面访问次数和从路由从创建到绘制完成耗时情况监控。 如图5所示,相比场景1,需要 打开计算均值的开关 ,并给它取个别名叫页面绘制耗时,打点代码则如下所示。

wpk.report({
  category: 103, //平台创建时,生成的code
  msg: '领取红包页',
  wl_avg1: 43// 页面绘制耗时;如vue中mounted的时间减去beforeCreate的时间得到耗时
})
复制代码
使用wl_avg1上报页面绘制耗时
复制代码

场景3:次数 + 耗时 + 成功率监控

如:领取红包的次数、领取成功率、领取红包耗时的监控。

如图5所示,比起场景2,创建监控项时,需要 打开计算(成功)率的开关,并为其起个别名比如就叫做领取成功率,打点代码如下所示。

// 领取红包成功
wpk.report({
  category: 103, //平台创建时,生成的code
  msg: '领取5元红包',
  wl_avg1: 43,// 领取红包接口耗时
  w_succ: 1
})
// 领取红包失败
wpk.report({
  category: 103, //平台创建时,生成的code
  msg: '领取5元红包',
  wl_avg1: 43,// 领取红包接口耗时
  w_succ: 0
})
复制代码

如果还有 ”10元红包“、”15元红包“等多种分类,msg的值直接填写红包分类即可;如果想监控的是失败率,把监控项中 ”领取成功率“改为”领取失败率“,上报日志时领取成功w_succ的值设为0,而领取失败w_succ的值设为1即可

场景4:次数 + 耗时 + 成功率 + 自定义字段

还是以领取红包为例,当领取失败时,不一定是接口错误,可能是业务上的错误,比如:已经领取过、没有资格、已被送到小黑屋等。

如图5所示,相对于场景3,需要在c1~c5中(按需)填上相应的别名,打点代码如下所示。

// 领取红包成功
wpk.report({
  category: 103, //平台创建时,生成的code
  msg: '领取5元红包',
  wl_avg1: 43,// 领取红包接口耗时
  w_succ: 1,
  c1: 'success'
})
// 领取红包失败
wpk.report({
  category: 103, //平台创建时,生成的code
  msg: '领取5元红包',
  wl_avg1: 43,// 领取红包接口耗时
  w_succ: 0,
  c1: '您已经领取过'
})
复制代码

在自定义字段中上报了你的业务信息后,需要时,既可以作为高级查询的查询条件,又可以按照自定义字段的值进行聚合(groupBy)

总结

经过一轮项目实践,总结通常应用会有两方面的监控诉求(技术),一方面是通用的技术指标,例如性能、JS异常等;另一方面是结合业务场景的监控项(在我的这个项目里面,有图片加载耗时、活动环节的监控等)。 在有了清晰的监控需求,明确监控指标之后,基本都可以通过岳鹰快速实现,真正做到事半功倍,对线上业务的运行情况了然于胸。

访问岳鹰全景监控平台