背景
今年年初，我进入一个基于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异常等；另一方面是结合业务场景的监控项（在我的这个项目里面，有图片加载耗时、活动环节的监控等）。
在有了清晰的监控需求，明确监控指标之后，基本都可以通过岳鹰快速实现，真正做到事半功倍，对线上业务的运行情况了然于胸。
访问岳鹰全景监控平台
