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

本文涉及的产品
日志服务 SLS,月写入数据量 50GB 1个月
简介: 监控,安全生产的第一战线,是如何发现线上问题以及快速定位问题的核心能力。

作者 | 墨辉

点击查看视频

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

监控,安全生产的第一战线,线上问题的发现能力以及如何快速定位问题是监控的核心能力。前端跨端方案不断在演进,覆盖了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

相关实践学习
日志服务之使用Nginx模式采集日志
本文介绍如何通过日志服务控制台创建Nginx模式的Logtail配置快速采集Nginx日志并进行多维度分析。
相关文章
|
4月前
|
Kubernetes 监控 测试技术
运维.云技术学习.基于应用服务网格的灰度发布(上:理论基础篇)
运维.云技术学习.基于应用服务网格的灰度发布(上:理论基础篇)
80 0
|
存储 数据采集 监控
阿里云故障洞察提效 50%,全栈可观测建设有哪些技术要点
本文分享了阿里云可观测平台服务作为全球分布的超大业务系统,同时也作为服务全球企业用户的可观测平台提供方,在故障洞察提效中遇到的业务挑战,以及 6 个关键技术点和 2 个应用案例。
21573 61
阿里云故障洞察提效 50%,全栈可观测建设有哪些技术要点
|
Kubernetes 安全 机器人
Lyft 微服务研发效能提升实践 | 3. 利用覆盖机制在预发环境中扩展服务网格
Lyft 微服务研发效能提升实践 | 3. 利用覆盖机制在预发环境中扩展服务网格
1240 0
Lyft 微服务研发效能提升实践 | 3. 利用覆盖机制在预发环境中扩展服务网格
|
存储 运维 监控
业务全链路追踪最佳实践|学习笔记
快速学习业务全链路追踪最佳实践
业务全链路追踪最佳实践|学习笔记
|
Kubernetes Dubbo Cloud Native
如何用20分钟就能获得同款企业级全链路灰度能力?
MSE 微服务引擎将推出服务治理专业版,提供开箱即用且完整专业的微服务治理解决方案,帮助企业更好地实现微服务治理能力。如果您的系统也可以像本文描述的那样,快速具备完整的全链路灰度能力,并基于该能力进行进一步的微服务治理实践,不仅可以节省客观的人力与成本,还可以让您的企业在微服务领域的探索更加有底气。
如何用20分钟就能获得同款企业级全链路灰度能力?
|
监控 NoSQL 新能源
全链路压测体系建设方案的思考与实践
全链路压测体系建设方案的思考与实践
全链路压测体系建设方案的思考与实践
|
存储 运维 监控
企业如何从 0 到 1 构建整套全链路追踪体系
今天,我来跟大家分享 ARMS 在全链路追踪领域的最佳实践,分享主要分为四部分。首先,是对分布式链路追踪的整体简介。其次,是对 ARMS 在分布式链路追踪领域的核心能力进行介绍。然后,介绍如何从 0 到 1 构建整套全链路追踪体系。最后,介绍一些最佳实践案例。
企业如何从 0 到 1 构建整套全链路追踪体系
|
移动开发 自然语言处理 监控
前后端、多语言、跨云部署,全链路追踪到底有多难?
链路追踪能覆盖全部关联 IT 系统,能够完整记录用户行为在系统间调用路径与状态的最佳实践方案。完整的全链路追踪可以为业务带来三大核心价值:端到端问题诊断,系统间依赖梳理,自定义标记透传。
前后端、多语言、跨云部署,全链路追踪到底有多难?
|
Kubernetes 监控 Cloud Native
企业深入使用微服务后会面临哪些问题?云原生全链路灰度给了新思路
如何落地可灰度、可观测、可回滚的安全生产三板斧能力,满足业务高速发展情况下快速迭代和小心验证的诉求,是企业在微服务化深入过程中必须要面对的问题。在云原生流行的当下,这个问题又有了一些新的思路与解法。
企业深入使用微服务后会面临哪些问题?云原生全链路灰度给了新思路
|
前端开发 安全 NoSQL
搭建具备灰度发布能力的技术架构
随着微服务架构的普及,服务数量激增,版本更新频繁,如果缺少灰度的能力,容易对现有的生产运行业务造成影响,并且新上线的系统和功能也需要灰度的能力来验证可行性和效果,简而言之,无论是对于系统运行稳定安全还是对于验证业务效果,灰度发布/验证的能力都是现代软件架构所必须的。 本文讨论并建议了几种灰度发布的实现机制。
1383 0
搭建具备灰度发布能力的技术架构