百亿业务流量-如何做好稳定性监控
NO.1
前言
监控 -- 安全生产的第一战线,报警的有效覆盖率、线上问题的发现能力以及如何快速定位问题是监控的核心能力。
安全生产整体目标1-5-10,1 分钟发现问题、5 分钟定位问题、10 分钟修复问题。
JSTracker平台 — 打造端到端的前端监控与数据分析平台,提供实时监控、多端覆盖、数据分析、智能化的核心能力,并基于 JSTracker平台 来完成淘系双11的稳定性保障。
本篇文章将通过介绍我们是如何基于 JSTracker平台 建设 1-5-10整体解决方案以及如何保障淘宝直播、会场、店铺、互动、交易等多个核心业务的双11大促稳定性。
NO.2
现状
前端跨端方案不断在演进,在前端框架上,覆盖了web、weex、小程序等多种跨端方案场景,工程的基础设施逐渐成熟,但业务整体的故障发现率依然偏低。对FY18-FY20淘系前端故障做了统计分析,监控发现率均值低于30%, 整体平均修复时长远超过1个小时。现从问题发现、快速恢复来分析下具体原因:
问题发现
多数故障未及时发现,核心问题不是报警有效性的问题,大部分来自于被动通知,线上反馈、舆情或者客诉等,从问题分析来看存在以下几个问题:
业务未接入监控,安全意识缺乏以及基础设施并不完备,页面需要手动引入监控SDK,很多业务在线上完全处于裸奔状态
核心指标未订阅,多数页面引入了监控但是没有订阅报警或者指标订阅不完整,导致线上问题没有第一时间发现
监控指标不完整,从传统前端视角,可能只会关注页面运行时的异常,比如jserror、接口报错运行等,但是从页面整个运行过程来看,很多监控指标是缺失的,比如cdn节点异常、页面加载白屏、页面执行crash等问题
快速恢复
从故障平均恢复统计时长来看离目标10分钟快速恢复存在很大差距。一个完整的开发流程包含 :开发 -> 发布 -> 线上验证回归流程。流程如图所示:
如果问题已经发布上线,按照发布流程很难做到10分钟恢复,对于问题的核心解法,需要聚焦到页面发布之前的开发阶段和发布阶段,主要涉及两点:
发布之前:完整的自动化测试流程,例如在发布之前对资源异常、JSError等做检测拦截
发布过程:页面发布过程具有可灰度、可监控、可回滚的完整过程
NO.3
整体方案
围绕着 1-5-10 安全生产整体目标,针对“问题发现、快速恢复”的问题解决方案如下:
监控覆盖
从故障问题来看,问题发现的核心问题是需要先解决监控覆盖率的问题,解决接入覆盖、订阅覆盖、指标覆盖的问题,保障业务100%接入和订阅以及页面的监控指标完整性,具体解决方案如下:
接入覆盖
我们需从两个维度来解决接入覆盖率的问题,完善基础设施和业务治理推动的角度
完善基础设施,前端页面主要分为两部分,源码和搭建(斑马、方舟)。在搭建层,我们在solution做了统一默认接入, 在源码层,目前 集团监控采集规范和数据规范标准还未统一,正在标准化统一的路上
业务治理推动,通过团队维度统计覆盖分布和指标情况,度量页面安全分, 引导和推动业务快速完成接入
在业务治理层,需要建立指标统计和业务度量方式,方案如下
指标统计
在度量开发过程当中,需要各种维度来统计指标数据,比如团队、时间等。如何高效的按汇报关系将数据进行汇总,是统计分析的核心问题,整体思路如下
构造人员工号的全路径字段(工号路径),可以通过path节点找到层级关系
获取某个主管下的列表,可以通过like快速查询,比如获取a3的所有员工, 如:工号路径 like '%a3%'
度量&红黑榜
度量目标帮助业务、团队做辅助决策,基于页面的原始数据,从原始数据 -> 数据分析 -> 指标度量 -> 业务决策 ,可建立一套指标度量模型,帮助业务快速发现问题
订阅覆盖
从统计数据可以看出, 很多页面主要是指标订阅不完整,比如只订阅了jserror,忽略白屏、crash等指标的订阅。在业务现状下,需要对未订阅的页面补齐订阅指标以及保障后续核心指标订阅,整体流程如下:
订阅指标补齐:通过治理流程,统计页面未订阅关系分布,走一键订阅指标补齐
完善发布流程:页面发布后,订阅发布消息,对核心指标做增量订阅
NO.3
指标覆盖
跨端页面,从整体的页面周期来看主要划分为三个过程,从容器启动 -> air渲染 -> 页面加载执行
容器层,比如weex、webview容器等,加载运行过程可以检测页面加载是否白屏、crash等
源站层,如果在cdn就出现异常,从前端的视角是无法感知的
页面层,依赖本身SDK的能力,全局捕捉过程异常点作为监控指标点
从安全视角来看,整个链路的稳定性都需要做到可监控。全链路保障过程,在数据链路层对数据指标过程做了统一接入,通过页面地址对齐指标
灰度监控
快速恢复的核心是需要更快发现问题,更快的对变更进行回滚。历史故障数据,80%左右的线上问题是由变更导致的。但很多故障不是缺少监控导致的,而是新的版本变更引起的问题在整体的错误量不明显,在整体日志层没有区分,导致看到的表面现像是正常的,而忽略了问题。
对于变更的过程的监控 【灰度监控】,需要标识异常的日志是新的版本带来的,用来对比线上版本的监控区分出新版本的错误比例增长以及新引发的问题,解决方案如下:
指标采集:采集脚本通过读取模板全局变量获取,容器层通过response header拿到灰度标识
监控指标:采集脚本和容器层需要统一和标准化灰度字段规范,在日志上报过程中携带,小程序通过版本号区分
灰度应用:主要表现在指标灰度实时日志呈现和报警
采集标准
主要分为两部分:字段规范和集成规范。字段规范主要针对不同的日志源,在数据链路上处理字段统一;集成规范是对于不同的跨端场景,用于页面识别灰度状态
字段规范
集成规范
<meta name="page-tag" content="env=spe,grey=true,version=0.0.1" />
采集方式
通过采集方式解决页面监控SDK以及跨端容器(weex、windvane等)获取发布版本的信息的问题,主要存在以下两个问题
监控SDK:受浏览器的限制,只能通过全局的方式读取,比如通过meta标签或者全局变量的方式
跨端容器:获取不到模板的内容,只能通过响应头的信息来获取到版本信息
基于上面问题,和前端发布约定下面两种标准的方式来通知端当前发布状态
集成到response headers内容里,headers里面写入版本号、灰度状态
直接在渲染层注入到页面模板内容,模板渲染的时候可以写入到全局参数中
具体方式
web sdk, 考虑全局变量存在一定污染,目前标准集成是通过meta标签的方式
<meta name="" content="{{$page.isGreyPage}}" />
容器侧,直接读取到response内容,但是也存在弊端,依赖客户端发版迭代
灰度应用
从监控视角来看,一个新的版本迭代主要担心两点,会不会带来新的问题或错误率比例会不会变大。对于应用侧,需要让用户清晰的感知指标的变化情况,具体如下:
灰度监控报警
灰度报警链路如下图:
1、订阅页面的发布消息,存储或者删除页面发布的信息,比如页面地址、灰度比例、发布人等配置信息
2、灰度报警目前是通过5分钟进行一次轮询,灰度版本日志可以拉取最新30分钟,线上可以拉取12个小时日志,避免新增的日志误差比较大造成误差,在对日志进行diff比较,相似度 < 50% 判断为新增日志,效果如下:
灰度实时监控
指标采集完整之后,在指标日志增加grey字段对灰度版本以及线上版本做日志区分,可以通过对比以下几点来判断灰度版本是否异常
灰度版本错误率和线上版本错误率的比例值
错误日志的趋势比例以及状态
结果
目前淘系C端的页面监控覆盖率是98%, 包含源码页面、搭建页面以及小程序。以主会场监控为例,在预售、预热、正式阶段,直接定位到 10+ 处模块开发问题。
监控大屏
基于页面监控、指标覆盖率的完整前提下,通过datav搭建了淘系整体的监控大盘,可以全局观察核心页面的异常情况。
案例: 双11晚上,整体的weex错误日志上涨,通过日志排查是有个页面js执行错误的逻辑
指标覆盖
Crash日志 整体上涨,xx号客户端推送配置,Crash日志大量上涨,业务第一时间收到报警,及时止血
灰度监控
互动业务,新增功能迭代发布后,灰度报错异常比例增加,及时回滚避免了线上问题扩大
NO.4
总结
在监控覆盖、灰度监控等能力建设之下,我们有了更好规避问题和感知问题的能力,才能让业务走的更远、走的更快。目前在报警订阅、准确性、指标分析上仍然存在不少问题,后续我们会持续完善监控的能力,欢迎一起讨论交流。
关注我
大家也可以关注我的公众号《脑洞前端》获取更多更新鲜的前端硬核文章,带你认识你不知道的前端。
喜欢就点这里
百亿业务流量-如何做好稳定性监控相关推荐
- java时序图工具_基于时序数据库,实现百亿级话单实时全景监控分析
背景 随着流量业务的高速发展以及已经到来的5G时代,业务支撑系统的规模不断增大.服务不断增多,业务.应用和系统运行性能指标数据持续以指数级的速度增长,每日计费话单量已突破百亿.系统监控的实时性.准确性 ...
- api网关选型_如何轻松打造百亿流量API网关?看这一篇就够了(下)
如何轻松打造百亿流量API网关?看这一篇就够了(上) 上篇整体描述了网关的背景,涉及职能.分类.定位环节,本篇进入本文的重点,将会具体谈下百亿级流量API网关的演进过程. 准备好瓜子花生小板凳开始积累 ...
- 神州数码云业务:奔向下一个新百亿
在2018年,神州数码云业务获得了近200%左右的增长. 之前,我看到来自第三方分析机构的报告显示,到2020年,全球云计算市场规模年复合增长率也就超过20%左右,中国云计算整体市场规模年复合增长率也 ...
- 亿级流量背后战场,京东11.11大促全方位技术揭秘
作为一名开发者,你经历过最可怕的流量是怎样的呢?对京东的这群架构师而言,京东11.11大促无疑是一场巨大的流量考验.摆在擂台上的是2715亿元的成交额,而在擂台背后,是一场关乎亿级.十亿级.百亿级流量 ...
- 抖音春晚红包百亿互动量级背后,火山引擎浮出水面
电商大促和春晚互动是中国互联网的两个流量巅峰,新的应用与玩法层出不穷,同时,也考验和显示了巨头的技术进阶与运维保障的实力. 刚刚过去的2021年春晚的互联网巨头主角是抖音,借着与2021年央视春晚独家 ...
- java hbase流量日志,Spark+Hbase 亿级流量分析实战(日志存储设计)
接着上篇文章 百亿级流量实时分析统计 - 数据结构设计 我们已经设计好了日志的结构,接下来我们就准备要开始撸代码了,我最喜欢这部分的环节了,可是一个上来连就撸代码的程序肯定不是好程序员,要不先设计设计 ...
- clickhouse 物化视图_再谈clickHouse:微博基于 ClickHouse 监控百亿流量下的指标
一.前言 广告业务监控中,我们经常碰到多维度的数据储存和查询分析需求,比如,我们可能需要基于秒级粒度去统计某个接口 TP999 耗时,或者需要基于秒级粒度去统计微博广告在各个场景下的请求量,再或者我们 ...
- 菜鸟积分系统稳定性建设 - 分库分表百亿级数据迁移
点击上方"服务端思维",选择"设为星标" 回复"669"获取独家整理的精选资料集 回复"加群"加入全国服务端高端社群「后 ...
- 百亿流量微服务网关的设计与实现
百亿流量微服务网关的设计与实现 本文从百亿流量交易系统微服务网关(API Gateway)的现状和面临的问题出发,阐述微服务架构与 API 网关的关系,理顺流量网关与业务网关的脉络,分享 API 网关 ...
最新文章
- 关于Android 隐藏 API 和内部 API的查看与使用
- Mac OS—苹果搭建Android开发环境
- 成长的路上,痛并快乐着
- 前端切换视图_前端架构 101(五):从 Flux 进化到 Model-View-Presenter
- 分段线性插值c语言程序_【短道速滑】OpenCV中cvResize函数使用双线性插值缩小图像长宽大小一半时速度飞快(比最近邻还快)之异象解析和自我实现。...
- Ubuntu下安装visual studio code
- 曾经很火但消失了的软件,你还记得几个?
- python 词云_python词云-数据产品岗位描述的词云
- php fpm 日志记录,使用Nginx在PHP-FPM 7上启用错误日志记录?
- cannot import name ‘Imputer‘ from ‘sklearn.preprocessing‘
- 8月份全国省会城市快递上门签收分析-谁是剁手王城?
- 高通apq8096连接外网
- linux内核audit,linux下的audit服务
- 情商 智商 逆商,哪个最重要?
- android自定义拨号键盘,Android拨号键盘增加魔力爱心数字
- [armv9]-PAC:Pointer authentication和BTI:Branch target instructions介绍
- Excel2010重复打印标题行
- 看电影适合什么蓝牙耳机?四款主动降噪高品质蓝牙耳机测评
- java故事之一年又一年
- SQL Server的优点与缺点
热门文章
- 【无标题】阿里云天池机器学习task3
- 用c语言编写:从健盘输入一个两位数的正整数 a,将其转换形成一个整数b并输出b。 转换的方式是:将a中较大的数码作为b的十位,剩余的数码作为上的个位。例如,当输入a =49,则结果 b=94...
- 五种网络IO模型:阻塞式IO 非阻塞式IO IO复用(IO multiplexing) 信号驱动式IO 异步IO
- IDEA 超全优化设置
- Python tkintertools 模块介绍(新版)
- C语言 scpi命令解释器,基于Python的SCPI命令解释器的设计
- WIFI模块——ESP8266
- 【研究】刘知远:如何写一篇合格的NLP论文
- Java中的Comparable接口和Comparator接口
- OVS流表精确匹配TCP/IP报头五元组