2017双11技术揭秘—双十一海量数据下EagleEye的使命和挑战

作者:王华锋(水彧)

背景

双十一一直是阿里巴巴集团每年要打的一场大战役。要打赢这场战役,技术上,不仅仅是几个应用、几个系统的事,也不是多少个开发+多少个测试就能完成的事,而是需要各大系统协同作战、每个应用各司其职、技术人员通力合作才能取得最终的胜利。

EagleEye作为阿里集团老牌的链路跟踪系统,其自身业务虽不在交易链路上,但却监控着全集团的链路状态,特别是在中间件的远程调用上,覆盖了集团绝大部分的场景,在问题排查和定位上发挥着巨大的作用,保障了各个系统的稳定性,为整个技术团队打赢这场战役保驾护航。

图1 EagleEye系统整体情况

近两年集团业务和规模始终保持着高速的增长,纵深上,交易量屡攀新高,双十一零点的交易峰值也再一次刷新了历史;横向上,集团涉及的行业和领域也不断的拓展,各行各业在不断加入阿里(高德、优酷、友盟及大麦等等),共同前进。

面对数据规模持续增加,如何应对在业务高速发展的背景下系统采集的数据量级的持续增长,如何在越来越大的数据规模面前保障EagleEye自身业务的稳定,成为EagleEye今年双十一面临的巨大挑战。

图2 EagleEye支持的业务情况

全链路压测一直是阿里巴巴集团保障双十一的大杀器之一,通过在线上环境全真模拟双十一当天的流量来检验各个应用系统的负载能力。EagleEye在全链路压测中承担了重要的责任,透传压测标记实现流量的区分,压测数据的收集与展现用以帮助业务方的开发同学发现及定位系统的问题。所以,保障全链路压测也是EagleEye的重要使命之一。

今年的EagleEye

无论是常态、全链路压测或者是双十一当天,EagleEye面临的主要问题是如何保障自身系统在海量数据冲击下的稳定性,以及如何更快的展现各个系统的状态及更好的帮助开发同学发现及定位问题。今年,EagleEye通过了一系列改造升级提高了系统的稳定性,实现了更好更快的辅助业务方定位及排查问题。

图3 系统架构图

计算能力下沉

早期的EagleEye在链路跟踪以及数据统计都是基于明细日志完成,实时采集全量的明细日志并在流计算中做聚合,随着业务量的增长,日志的数据量也在急剧上升,计算量也随之线性增长,资源消耗较高。而且在全链路压测或者大促期间,日志量会有明显的峰值,极有可能造成计算集群系统过载或者数据延迟甚至有可能导致数据的丢失。

为解决这类问题,最初的做法是采样,通过采样降低收集的日志量,从而稳定计算集群的负载及水位,保障EagleEye自身业务的稳定性,尽量减少业务峰值对我们的影响。但是带来的问题也是显而易见的,统计数据在计算时需要考虑采样率估算出真实的数据,在采集数据量较小且采样率较高的场景下导致聚合后的数据不准确,无法展现业务真实的状态,从而也就失去了其价值。

为彻底解决业务峰值对EagleEye计算集群的冲击,将部分实时计算逻辑下沉到业务方的机器中,使得业务量和所需采集的日志量解耦,保证计算集群的稳定性。具体实现是在业务方的机器上先将数据按照指定维度做聚合(一般是以时间维度),计算集群采集该统计数据后再次聚合,极大的稳定了计算集群的负载。

图4 计算能力下沉

计算能力下沉,也可以理解成将计算分布式化,消耗了业务方极小的一部分资源,保证了EagleEye集群的稳定性。而且,集群的计算量不再随着业务量的增长而增长,只随应用规模(应用数量、机器数量)和统计维度的增长而增长,不会再出现由于业务量的瞬间峰值导致计算机群的负载过高的问题,最终使得EagleEye在全链路压测和大促期间都能保持稳定水位,并且产出精准的数据。

场景化链路

EagleEye一直专注于中间件层面的调用,而阿里巴巴的业务量庞大,系统也比较复杂,所以各部分的功能划分比较清晰,中间件层面的一些数据比较难与业务数据相关联,对于链路跟踪、问题定位及针对指定业务场景的容量规划等都有一些难度。

今年,EagleEye推出场景化链路的功能,开放了添加业务场景标的能力,类似于压测流量打压测标,对指定的业务打上对应的业务场景标签,并关联该标签下所有的中间件调用(包括服务、缓存、数据库和消息等),一是可以帮助业务方开发同学更好地区分某个RPC流量中的业务语义,二是可以清晰的梳理出某个业务场景标下对应的RPC流量,对分析一些关键指标,如缓存命中率,数据库RT等有较大的帮助。

图5 流量场景标

基于此数据,也可以更好的复盘全链路压测数据。在压测之前(也可以在常态下)对关键业务打上指定的标签,压测后通过各业务场景的流量得出对应的性能基线,更好的定位核心链路中的问题及性能拼劲,提高压测的效率和价值。

精细化监控

EagleEye的链路数据对于问题的发现和定位有着至关重要的作用,更加丰富的数据形式和展现对提高发现的效率有明显的提升。

在整个双十一备战过程中,遇到并解决了很多疑难杂症。其中,单机问题占了很大的比例。在分布式系统中,单机问题是比较常见的一类问题, 由于此类问题往往与业务代码不直接相关,与容器或者机器有一定的关联性,且出现的概率较小,有一定的随机性,导致该问题往往比较难排查。实际业务的表现可能是RT的抖动,也可能是小概率的错误等等。

EagleEye的调用链虽然可以很快定位此类问题,但是调用链是站在单次请求的视角上,在定位到某个IP之后很可能还需要再分析更多的数据才能做决策,针对此类的问题,EagleEye提供了错误TopN分布以及系统热点图等功能,帮助业务方开发同学快速定位问题。针对单机故障,往往对于整体的指标影响不大,通过应用级别的监控数据比较难定位,EagleEye在流计算中统计了应用各个机器的错误情况,汇总并排序出Top10的机器,一旦出现单机故障,可以很明显的定位到具体的IP,并且根据该IP对应的错误数量可以很快做出决策,缩短了开发同学排查问题的时间。系统热点图在压测和大促期间对系统健康度的表现非常清晰,一是可以清晰看到是否存在离群点的机器,二是可以验证流量的去向是否正确。

图6 系统热点图

更丰富的生态

在阿里巴巴,EagleEye是一款问题排查的利器,一直服务于业务方的同学帮助其快速发现并定位问题,降低故障的持续时间,提升开发及运维效率。其实,EagleEye底层还蕴含着一份海量的数据,在近一年中,我们不断地利用及挖掘这份数据的意义,希望发挥其更大的价值,同时也希望基于这些数据建立一套生态体系,帮助用户更好发展业务,期间也孕育出很多有价值的产品,为集团的技术发展打下了基础。

天秤项目:天秤基于EagleEye的场景数据及其中间件、系统指标等监控数据,结合其他多款监控产品构建一个系统稳定性解决方案,意在解决问题快速发现和精准定位、大促常态化、压测常态化等问题。

尖兵计划 – 更轻量化的全链路压测:尖兵计划基于EagleEye的中间件、系统指标及压测数据,实现常态化全链路压测和问题发现,是保障双十一及全链路压测顺利的大杀器之一,相比去年八次全链路压测,今年环境加倍复杂,但是只需要三次全链路压测就完成目标,为集团节省上千个人力,大幅提升交付上线质量和大促效率。

精准回归:依托EagleEye调用链采集与计算的能力,实现了测试用例精准推荐的效果,并在部分应用的精准测试中节约了50%~70%的测试时间。精准测试通过EagleEye采集,数据回流的方案的输出,在大规模应用上(千万链路)做到了测试用例与应用代码链路的准实时生成。

天图项目:天图依赖了部分EagleEye的链路数据,为用户提供面向复杂业务链路、高度分布式架构下的Application Performance Management (APM)方案,以全面、实时、可视化、智能的方式让你快速了解应用和业务链路的全貌。

结语

今年的双十一是一次完美的双十一,可以说是技术团队的大获全胜,EagleEye在这次大考中也交出了一份近乎完美的答卷,无论是在全链路压测中还是双十一当天,系统的稳定性和数据的实时性都达到了预期,为业务方的提供了强有力的支持,提高了问题排查的效率。

但是,未来的路还很长,智能化的发展脚步越来越快,业务方对EagleEye的数据质量的要求也越来越高,今后EagleEye会专注于架构的演进和智能化的推进,进一步提高问题定位的效率,更好的支撑起基于链路数据的一片生态。

时间: 2024-10-25 10:44:34

2017双11技术揭秘—双十一海量数据下EagleEye的使命和挑战的相关文章

2017双11技术揭秘—千亿级流量来袭,如何用硬件加速技术为CPU减负?

作者:王发康(毅松) 主站接入层是阿里2015年全站HTTPS项目诞生的产品,目前已经承载集团90%以上的入口流量.2016年主站接入层不仅在运维自动化.高可用领域取得重大突破,而且软件层面上也做过很多性能优化,促使2016年双11平稳度过.秉着软硬件结合的性能优化思想,2017年主站接入层在硬件加速领域迈出了第一步.在刚过去的2017年双11零点流量高峰的考验下,主站接入层Tengine Gzip硬件加速机器运行平稳.同等条件下相比于未开启QAT加速的机器性能提升21%左右. 背景介绍 众所周

2017双11技术揭秘—阿里巴巴数据库技术架构演进

作者:谌文涛(俞月) 每年电商双11大促对阿里技术人都是一次大考,对阿里数据库团队更是如此.经过9年的发展,双11单日交易额从2009年的0.5亿一路攀升到2017年的1682亿,秒级交易创建峰值达到了32.5万笔/秒.支撑这一切业务指标的背后,是底层技术体系的一次次迭代升级. 阿里巴巴数据库系统经历了10多年的发展,今年正式确定从 第三代大规模分库分表 向 第四代X-DB分布式数据库系统 演进的目标.X-DB分布式数据库的落地已经在2017年双11大促中获得了可行性验证,同时底层开始引入存储计

2017双11技术揭秘—TDDL/DRDS 的类 KV 查询优化实践

作者:励强(君瑜) 场景介绍 性能优化是企业级应用永恒的话题,关系型数据库查询优化更是如此.在前台核心业务场景中,类 KeyValue 查询(以下简称类 KV 查询)是非常常见的(例如,SELECT id, name FROM users WHERE id=1002),并且在应用总 SQL 流量占比很高,例如,天猫某核心业务的类 KV 查询占比近90%,商品某系统中占比近80%,交易订单系统中占比也有50%左右,菜鸟等其他核心业务场景中这个现象也是相当普遍. 这类 SQL 已经非常简单,如果仅在

2017双11技术揭秘—阿里数据库计算存储分离与离在线混布

作者:吕建枢(吕健) 背景 随着阿里集团电商.物流.大文娱等业务的蓬勃发展,数据库实例以及数据存储规模不断增长,在传统基于单机的运维以及管理模式下,遇到非常多的困难与挑战,主要归结为: 机型采购与预算问题在单机模式下计算资源(CPU和内存)与存储资源(主要为磁盘或者SSD)存在着不可调和的冲突:计算与存储资源绑定紧密,无法进行单独预算.数据库存储时,要么计算资源达到瓶颈,要么是存储单机存储容量不足.这种绑定模式下,注定了有一种资源必须是浪费的. 调度效率问题在计算与存储绑定的情况下,计算资源无法

2017双11技术揭秘—X-DB支撑双11进入分布式数据库时代

作者:章颖强(江疑).胡炜 X-DB 1.0(X-Cluster)是阿里自主研发的,100%兼容MySQL生态的,全球级分布式强一致的关系型数据库系统.今年双11是X-DB的第一次大考,本次双11X-DB服务于天猫/淘宝核心交易系统.核心物流系统.核心IM系统,经受了零点业务32.5万笔/秒峰值的性能考验(对应数据库峰值每秒破亿次的SQL调用):同时X-DB支撑起了新一代单元化架构,在分布式一致性算法Paxos的统一框架下,第一次提供了跨Region分布式强一致能力,实现高效的跨Region数据

2017双11技术揭秘—分布式缓存服务Tair的热点数据散列机制

作者:刘欢(浅奕) 1 问题背景 分布式缓存一般被定义为一个数据集合,它将数据分布(或分区)于任意数目的集群节点上.集群中的一个具体节点负责缓存中的一部分数据,整体对外提供统一的访问接口[1].分布式缓存一般基于冗余备份机制实现数据高可用,又被称为内存数据网格(IMDG, in-memory data grid).在云平台飞速发展的今天,作为提升应用性能的重要手段,分布式缓存技术在工业界得到了越来越广泛的关注和研发投入[2].弹性缓存平台[3]是分布式缓存集群在云计算场景下的新形态,其强调集群的

零点之战!探访阿里巴巴8大技术专家,提前揭秘2017双11关键技术

点击进入阿里云双11主会场 摘要:在距离双11已经不到10天的这个时刻,一场看不见硝烟的战争似乎已经打响.随着一年一度购物狂欢的即将到来,网上出现了很多阿里技术应对双11的段子."阿里工程师拜关公求服务器不宕机","技术人员围着被子敲代码"等传闻也被消费者们所津津乐道.那么,针对双11期间极为严苛的技术压力,阿里巴巴究竟是用怎样的方式进行解决的呢?在接下来的文段中,就让我们一起来对阿里巴巴在2017双11背后的技术进行一次细致的了解和探访.   阿里巴巴针对双11的

揭秘2017双11背后的网络-双11的网络产品和技术概览

引言 揭秘2017双11背后的网络-一张图读懂2017双11中的网络产品和技术 揭秘2017双11背后的网络-双11的网络产品和技术概览 揭秘2017双11背后的网络-直面双11洪峰的负载均衡SLB 揭秘2017双11背后的网络-全球最大混合云架构 注:如果对网络产品还不太了解的,推荐阅读 一张图看懂阿里云网络产品[一]网络产品概览 下面分别对双11中的主要网络产品-专有网络VPC,负载均衡SLB,NAT网关,高速通道以及混合云架构进行介绍 VPC-安全的网络容器 专有网络VPC(Virtual

2017双11交易系统TMF2.0技术揭秘,实现全链路管理

  阿里巴巴资深技术专家 毗卢 毗卢,阿里巴巴资深技术专家,主导设计了TMF2.0框架,并基于该框架完成交易平台架构升级改造,目前负责商品中心,专注电商领域业务建模与工程交付相结合的研究与平台推广. 交易平台遇到的挑战 在刚刚过去的2017双11,交易峰值达到了32.5万笔/秒,这给整个交易系统带来了非常大的挑战.一方面,系统需要支撑全集团几十个事业部的所有交易类需求:要考虑如何能更快响应需求.加快发布周期:如何能为新小业务提供快速支撑.降低准入门槛:是否足够开放使得业务方能做到自助式扩展:新需