如何建设灰度跨端监控 | D2分享视频+文章-阿里云开发者社区

开发者社区> AlibabaF2E> 正文
登录阅读全文

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

简介: 监控,安全生产的第一战线,是如何发现线上问题以及快速定位问题的核心能力。

作者 | 墨辉

点击查看视频

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

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

背景介绍

image.png
首先介绍下跨端的背景,打开一个H5或者pc的页面,从传统前端监控视角去看,我们一般只会关注页面运行过程的异常监控,比如 JSError、接口异常、性能等这些指标。
image.png
今天,我们业务运行在很多不同的跨端的方案,比如 weex、小程序、rn、flutter等。从跨端监控视角看,需要做到全链路的监控。比如容器启动异常、页面加载白屏、页面执行过程导致crash等问题的监控。
image.png
回到安全生产的背景,我们统计了淘系前端财年故障,我们发现线上问题 80% 是变更引起的以及故障平均修复时长超过了 300 分钟,我们来分析下具体原因:
image.png
线上变更引起故障,大部分是没有被监控发现,根据上图分析下监控没有被发现的原因。从趋势图看出,在10点左右有个发布节点,日志有个小幅度的增长,增长过程没有触发报警,原因主要包含两个:

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

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

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

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

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

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

image.png
灰度监控是要解决发布过程的监控,核心要解决三个问题:

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

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

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

技术方案

下面介绍下整体技术方案。
image.png
技术方案分为四个部分:

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

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

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

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

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

image.png
ZIP打包一般分为两种场景,具体如下:

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

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

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

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

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

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

image.png
端外采集,一般是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'
.....

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

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

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

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

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

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

image.png
灰度报警是在node层启动一个进程做轮询任务,拉取页面发布列表数据,对比页面的线上版本日志和灰度版本日志。基于新增日志和日志的增长比例的报警策略来触发报警。
image.png
灰度实时监控目标是帮助业务更快和直观的发现问题,需要将核心数据更直观的透出在数据图表上,核心指标数据包含:

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

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

image.png
实时监控效果如上图所示,通过两部分来看这个图表:

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

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

线上案例

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

总结

image.png
做下技术方案总结,灰度监控分为四个过程:

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

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

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

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


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

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

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
AlibabaF2E
使用钉钉扫一扫加入圈子
+ 订阅

阿里经济体前端技术最新内容汇聚在此,由阿里经济体前端委员会官方运营。我们的愿景是建立全球一流的前端团队,链接商业,让数字世界触手可及是我们的使命。阿里经济体前端委员会致力于加强技术前瞻性、推进集体成长、提升国际影响力。同时我们运营着阿里经济体前端的官方公众号:Alibaba F2E,欢迎关注。

官方博客