汽车|核桃编程:前端可观测性建设之路( 二 )


相对于成熟的服务端监控技术 , 整个业界在客户端监控领域的技术方案一直比较欠缺 。 在互联网上 , 海量的用户使用不同厂家、不同操作系统、不同屏幕分辨率的终端设备 , 分布在不同的地域 , 又通过不同的网络运营商进行接入 , 甚至存在复杂的第三方依赖 , 包括 CDN、第三方统计脚本、页面嵌套等方面 。 当用户体验遇到问题的时候 , 如果仅仅拥有服务端监控手段 , 很难第一时间确认问题的根源到底在于前端还是后端 。 即便能够排除服务端的问题 , 前端用户体验也受到页面渲染、JavaScript 执行、网络质量、第三方接口服务质量等方面的影响 , 为进一步排查问题留下了非常多的挑战 。
一个简单的思路是通过前端 JavaScript 做自定义的埋点 , 将最终用户的各种行为实时上报给服务端进行统计 , 以第一时间了解到用户体验 。 这个思路本身是合理的 , 但业务埋点、数据采集、聚合分析、视图展现等层面都有非常多的工作需要做 , 是一个浩大的工程 。 绝大多数技术团队而言 , 投入如此多的精力来建设这样一套前端监控方案都是不现实的 。
建设前端可观测体系 , 最好的捷径是参考互联网领域头部企业的案例 , 选择云计算厂商提供的完整方案 。 阿里巴巴多年实战积累了一套全集团统一的前端监控方案 , 并开放给各个事业部接入 。 对于以 HTML 页面形式呈现的前端应用 , 不管是 PC 端/移动端网站 , 嵌入到移动端 App 的 HTML5 页面 , 都可以通过无侵入的方式接入到这套前端监控方案中 。

这套监控方案也同时通过阿里云对外输出 , 成为阿里云可观测性整体方案的重要组成部分 , 服务于广大的外部用户 。
在客户端监控领域 , 包括 ARMS 前端监控和 APP 监控两个产品 , 其中 ARMS 前端监控专注于 Web 端体验数据监控 , 从页面打开速度、页面稳定性和外部服务调用成功率这三个方面监测 Web 页面的健康度 , 帮助使用者降低页面加载时间、减少 JS 错误 , 有效提升用户体验 。

这套方案正好能补齐核桃编程在客户端监控领域的能力缺失 , 所以核桃技术团队尝试在一些业务线接入阿里云 ARMS 前端监控 。 很快 , 他们就感受到了这套方案对于提升用户体验所带来的价值 。
ARMS 前端监控方案之所以能被核桃编程采纳 , 有一个很重要的原因是方案的接入是非常简单的 , 唯一要做的事情是在客户端 HTML 页面的 Body 元素中加入一段由 ARMS 提供的统计接入脚本(一段 Java Script 代码) , 就能完成监控数据的自动上报 。 这其中不涉及到任何跟业务层主动埋点的工作 , 在核桃编程的多条业务线之间推广起来是非常顺利的 。 基于之前的经验 , 凡是需要在业务层主动埋点的监控方案 , 都需要通过行政手段来保证多个研发团队在编写代码的时候遵守既定的规则 , 这样的方式从长期来看都是很难落地的 。 包括在服务端全链路监控方面 , 核桃编程也始终遵循业务无侵入的思路 , 避免主动埋点行为 。
接下来 , 研发人员就能从前端监控控制台全面了解应用端到端的健康程度 , 包括 PV/UV 情况统计、页面加载速度情况、JavaScript 执行情况 , API 请求成功率等多个方面 。 以页面加载速度为例 , ARMS 可以基于客户端自动上报的监控数据 , 实时展示每一个页面的加载情况 。

其中 , 首次渲染时间、首屏时间、Dom Ready 等指标都是 HTML 页面独有的性能指标 , 遵循业务标准的指标定义 。 这些指标数据和前端页面健康程度息息相关 , 影响着最终用户每一次交互行为的实际体验 。

通过页面加载瀑布图 , 能够按照页面加载的顺序 , 直观地展示各阶段的耗时情况 。 这些指标参数涵盖了网络层面的性能指标 , 当网络层面出现性能瓶颈 , 比如应用系统的接入带宽不能支撑用户访问流量的时候 , 仅仅通过服务端的监控手段 , 是无法洞察到的 , 必须依赖于客户端的实时监控数据上报 。 通过 ARMS 前端监控 , 核桃编程能从页面生产时(服务器端状态)、页面加载时和页面运行时这三个方面 , 全面了解到每一个应用系统端到端的健康程度 。