如何建设灰度跨端监控 | D2分享视频+文章

作者 | 墨辉

点击查看视频

大家好，我是来自阿里巴巴淘系技术部的墨辉。今天分享主题是《如何建设灰度跨端监控》。

监控，安全生产的第一战线，线上问题的发现能力以及如何快速定位问题是监控的核心能力。前端跨端方案不断在演进，覆盖了web、weex、小程序等多种跨端方案场景。今天的主题从背景介绍、技术方案、线上案例、总结 4个维度来介绍灰度跨端监控。

背景介绍

首先介绍下跨端的背景，打开一个H5或者pc的页面，从传统前端监控视角去看，我们一般只会关注页面运行过程的异常监控，比如 JSError、接口异常、性能等这些指标。

今天，我们业务运行在很多不同的跨端的方案，比如 weex、小程序、rn、flutter等。从跨端监控视角看，需要做到全链路的监控。比如容器启动异常、页面加载白屏、页面执行过程导致crash等问题的监控。

回到安全生产的背景，我们统计了淘系前端财年故障，我们发现线上问题 80% 是变更引起的以及故障平均修复时长超过了 300 分钟，我们来分析下具体原因：

线上变更引起故障，大部分是没有被监控发现，根据上图分析下监控没有被发现的原因。从趋势图看出，在10点左右有个发布节点，日志有个小幅度的增长，增长过程没有触发报警，原因主要包含两个：

• 大盘日志的增长并不明显

• 缺少细分的维度来区分日志增长的来源

上面我们提到了，平均修复时间超过了300分钟，一个完整的流程流程包含两个阶段

• 开发阶段，从需求评审、需求开发以及测试验证

• 发布阶段，开发完成之后，发布过程会有个渐渐放量的过程，内部灰度 -> 外部灰度，最后完整上线

如果一个问题完整上线才发现，会带来问题修复周期长和影响范围广的问题。要解决这些问题，需要在灰度发布过程来提前发现问题。

灰度监控是要解决发布过程的监控，核心要解决三个问题：

• 不同的跨端容器（weex、小程序等）怎么建设灰度监控

• 灰度报警和普通报警的差异是什么

• 灰度发布过程的监控，如何帮助业务更好定位问题

技术方案

下面介绍下整体技术方案。

技术方案分为四个部分：

• 灰度发布：发布分为两种，一种是类似小程序这种，打包成zip包发布上线；一种是常规页面发布，静态资源发布到CDN

• 日志采集：页面运行过程需要采集监控的指标，比如js执行报错、接口异常等指标上报

• 数据处理：数据上报完成之后，需要对数据清洗和字段处理

• 灰度监控：基于处理后的数据结果，完成灰度监控的建设

上面提到，两种发布方式，首先看下静态资源发布，比如weex或者web这种场景，一般在cdn层做灰度控制。如果命中，访问的是灰度版本。未命中，访问的是线上版本。

ZIP打包一般分为两种场景，具体如下：

• 小程序场景，打包成ZIP包发布上线

• WEB离线场景，做资源加载的优化，会将静态资源打包成离线ZIP包做发布上线

对于ZIP还是非ZIP发布场景，当前版本和线上版本需要从三个字段维度来区分：

• 版本号，用来确认当前日志是在哪个版本发生的

• 是否命中灰度，用来区分当前版本是不是灰度中的版本

• 当前环境，用来区分日志的来源环境

端外采集，一般是web场景，受限于浏览器，需要通过全局变量的方式来获取。可以在脚手架初始化过程注入到模板并服务端渲染对变量赋值，通过采集SDK读取变量获取灰度标识信息，具体集成方式如下：

<meta name="page-tag" content="env=spe,grey=true,release=0.0.1" />

容器采集，通过扩展response header信息来获取。拉取资源的时候，可以直接读取资源的response信息来获取灰度标识信息，具体集成方式如下：

grey: 'true'
env: 'spe'
release: '0.0.1'
date: 'Fri, 11 Dec 2020 13:12:04 GMT'
content-type: 'text/html; charset=utf-8'
.....

数据处理过程，主要包含对脏日志清洗、数据字段规范、数据字段解析、数据分类存储等，具体如下：

• 获取原始日志，不同的跨端容器日志统一上报到TT平台。TT平台是流式数据处理平台，通过在TT平台订阅消息，拿到上报的原始日志

• 实时日志处理，基于Blink台完成，Blink是流式实时计算平台，主要是做日志清洗以及把日志转成规范格式日志

• 数据存储，将清洗后的日志存储到SLS，基于SLS日志存储服务，可以对日志进行实时查询和分析

• 数据应用，基于node层，做实时日志查询、轮询报警等应用能力

安全生产背景分析发现小幅度日志增长，缺少细分的维度来区分日志增长的来源。现在日志包含了版本号、环境、是否命中灰度维度信息，通过这些维度区分出新增错误日志和日志的增长比例，来打造灰度报警和灰度实时监控能力。

灰度报警是在node层启动一个进程做轮询任务，拉取页面发布列表数据，对比页面的线上版本日志和灰度版本日志。基于新增日志和日志的增长比例的报警策略来触发报警。

灰度实时监控目标是帮助业务更快和直观的发现问题，需要将核心数据更直观的透出在数据图表上，核心指标数据包含：

• 灰度比例，灰度命中占整体流量的比例。通过线上的采集pv和灰度版本的采集pv来计算出灰度比例

• 详细日志状态，比如JSError指标，通过灰度版本的日志和线上的日志做相似度算法比较，可以对日志聚合分类，计算出新增的错误类型和错误增长比例

实时监控效果如上图所示，通过两部分来看这个图表：

• 日志走势，绿色的线可以区分出灰度命中占整体流量的比例，红色和蓝色的线可以区分灰度版本和线上版本日志总量的比例

• 日志分布，对日志做了两种状态标识，新增日志状态和日志增长的比例。通过日志的变化趋势状态，可以直观的判断灰度版本是否符合预期

线上案例

介绍一个具体案例，一次新需求迭代，流量灰度5%左右的时候，发现一个报错日志增长了接近5倍，通过及时回滚避免的线上一次故障。

总结

做下技术方案总结，灰度监控分为四个过程：

• 灰度发布，对于WEB、小程序、WEEX等灰度发布能力的覆盖

• 指标采集，浏览器采集通过读取模板变量的方式，容器采集通过读取response header信息获取灰度标识

• 监控指标，覆盖全链路监控指标，日志上报过程中携带灰度版本信息并转成规范日志格式

• 灰度应用，通过灰度发布的信息维度做日志分析，来打造灰度报警和灰度实时监控能力

🔥第十五届 D2 前端技术论坛 PPT 集合已放出，马上获取

关注「Alibaba F2E」
回复 「PPT」一键获取大会完整PPT