阿里巴巴鹰眼系统简介

简介: 微服务框架带来的好处十分多,比如说它提高了开发的效率,它具备更好的扩展性。可是微服务其实是一把双刃剑,微服务同时也带来了一些问题,比如:

1、微服务带来的问题


     

微服务框架带来的好处十分多,比如说它提高了开发的效率,它具备更好的扩展性。可是微服务其实是一把双刃剑,微服务同时也带来了一些问题,比如:

  • 故障定位难
  • 容量预估难
  • 资源浪费多
  • 链路梳理难


而这些问题也就是我们的鹰眼系统需要解决的问题。


2、鹰眼是什么


       

鹰眼是一个以链路追踪技术为核心的监控系统,它主要的手段是通过收集、存储、分析分布式系统中的调用事件数据,协助开发运营人员进行故障诊断、容量预估、性能瓶颈定位以及调用链路梳理。


EagleEye(鹰眼):是分布式调用跟踪系统,就是对一次前端请求产生的分布式调用都汇总起来作分析。


TraceId: 是标明一次前端请求的全局唯一的调用链ID。在前端请求到达到服务器时,应用容器在执行实际业务处理之前,会先根据EagleEye的埋点逻辑,生成TraceId。


3、实现原理



3.1 TranceID

43588e0fc9f14417aa2b00b845756872.png

在一套中间件里做统一埋点,在分布式调用框架、分布式消息系统、缓存系统、统一接入层、Web 框架层的发送与接收请求的地方做统一埋点,埋点的数据能够被一套中间件在系统之间进行无缝透传。


当用户的请求进来的时候,鹰眼在第一个接收到这个请求的服务器的中间件会生成唯一的 TraceID,这个 TraceID 会随着每一次分布式调用透传到下游的系统当中,所有透传的事件会存储在 RPC log 文件当中。随后鹰眼会有一个中心化的处理集群把所有机器上的日志增量地收集到集群当中进行处理,处理的逻辑比较简单,就是做了简单清洗后再倒排索引。只要系统中报错,然后把 TraceID 作为异常日志当中的关键字打出来,就可以看到这次调用在系统里面经历了哪些事情,我们通过 TraceID 其实可以很容易地看到这次调用是卡在 B 到 C 的数据库调用,它超时了,通过这样的方式我们可以很容易追溯到这次分布式调用链路中问题到底出在哪里。其实通过 TraceId 我们只能够得到上面这张按时间排列的调用事件序列,我们希望得到的是有嵌套关系的调用堆栈。


3.2 TraceID + RPCID

491ca1df056c4473ba84c511f7fd897f.png


要想还原调用堆栈,我们还需要另外一个东西叫做 RPCId(在 OpenTracing 中有类似的概念,叫做 SpanID),RPCId 是一个多维序列。它经过第一次链路的时候初始值是 0,它每进行一次深入调用的时候就变成 0.1,然后再升就是 0.1.1,它每进行一次同深度的调用,就是说 A 调完 B 以后又调了 D 就会变成 0.2,RPCId 也随着本次调用被打印至同一份 RPC Log 中,连同调用事件本身和 TraceId 一起被采集到中心处理集群中一起处理。

90048a1eafbf4a3aa8ab4393cb773aaa.png


收集完了以后,鹰眼对所有调用事件按照 RPCId 进行一个深度遍历,就可以获得这样的一个调用堆栈,上图中的调用堆栈实际上就是真实的淘宝交易系统里面进行下单的交易调用堆栈,可以看到这次调用经历了很多系统。但我们在鹰眼的视角上面来看,就好像是在本地发生的一样,可以很容易地去看到如果一次调用出现了问题,那问题的现象是出现在哪里,最后问题的根因又是发生在了哪里。除了调用异常的返回码之外,在右边其实还可以看到每次调用的耗时是多少,我们也可以看到每一次调用是慢在哪里。这张图中解释了鹰眼是如何解决微服务四大问题中的故障定位难的问题,它可以通过倒排索引,让用户反查出每一次调用的全貌是怎样的。


3.3 根据指定Tag统计调用次数


如果我们对万亿级别的调用链数据进行聚合,是否能够获得更有价值的信息?我们可以看一下,每一次调用除了它唯一标识 TraceID 和 RPCID 之外,还包含了一些标签信息 (Tag),什么是标签呢?就是具备共性的, 大家都会有的这么一些信息。比如说这次调用它分别经历了哪些系统,这些系统它每次调用的 IP 是什么,经过哪个机房,服务名是什么?有一些标签是可以通过链路透传下去的,比如入口 url,它透传下去以后我就知道这次请求在下去之后发生的每一次事件都是由通过这个入口去发起的,那么如果把这些标签进行聚合计算,我们可以得到调用链统计的数据,例如按某机房标签统计调用链,我们就可以得到每个机房的调用次数的趋势图。


这样做有什么好处呢?实际上在容量预估当中这样做的好处是非常明显的。我们来看一个例子,假如我们有一个交易下单入口标签,我们对这样的标签做了聚合以后,不光能看到单次调用它的情况是如何,还能看到将这些调用链数据聚合以后,它的总调用次数是多少,平均耗时是多少,我可以发现系统当中热点瓶颈在哪里,同时我们可以发现一些非法流量,也就是说我之前不知道的事。


3.4 小结

     

鹰眼分为两部分的功能:第一个是通过 TraceId 和 RPCId 对分布式调用链的堆栈进行还原,从而实现故障定位的功能;第二个是通过调用链数据分析,将这些入口、链路特征、应用、机房等的tag 进行聚合统计,可以做到容量预估、性能瓶颈的定位以及调用链的梳理。


相关文章
|
SQL 运维 监控
阿里巴巴DevOps实践指南(二十一)| 全景监控
随着云原生技术的发展与演进,微服务和容器化技术成为大型分布式 IT 架构的必然选择。新技术在让 IT 系统变得更敏捷、健壮、高性能的同时,也带来了更高的技术架构复杂度,给应用监控带来了前所未有的挑战。
阿里巴巴DevOps实践指南(二十一)| 全景监控
|
25天前
|
Web App开发 存储 监控
iLogtail 开源两周年:UC 工程师分享日志查询服务建设实践案例
本文为 iLogtail 开源两周年的实践案例分享,讨论了 iLogtail 作为日志采集工具的优势,包括它在性能上超越 Filebeat 的能力,并通过一系列优化解决了在生产环境中替换 Filebeat 和 Logstash 时遇到的挑战。
|
6月前
|
消息中间件 Docker 索引
【一文解读】阿里自研开源核心搜索引擎 Havenask简介及发展历史
本次分享内容为Havenask的简介及发展历史,由下面五个部分组成(Havenask整体介绍、名词解释、架构、代码结构、编译与部署),希望可以帮助大家更好了解和使用Havenask。
71964 0
【一文解读】阿里自研开源核心搜索引擎 Havenask简介及发展历史
化繁为简!阿里新产亿级流量系统设计核心原理高级笔记(终极版)
不管是初入职场的小菜鸟还是有一些工作年限的老司机,系统设计问题对他们来说都是一大困扰。前者主要是在于面试;面试官来一个如何从零到一设计一个完整的系统?大多数人都会直接懵了,因为系统设计覆盖面广,而网上资料又不能面面俱到,单独背背文章肯定是不行的;后者主要在于晋升;想要从程序员进阶到架构师,系统设计是必须要踏入的一道坎,他对你的技术广度跟深度都会有一定程度的考察。
|
应用服务中间件 nginx 索引
《2021 阿里云可观测技术峰会演讲实录合辑(下)》——一、基于OPLG从0到1构建统一可观测平台实践——场景实践3:基于Loki的日志查询分析
《2021 阿里云可观测技术峰会演讲实录合辑(下)》——一、基于OPLG从0到1构建统一可观测平台实践——场景实践3:基于Loki的日志查询分析
280 0
|
人工智能 算法 数据可视化
国内首发可视化智能调优平台,小龙带你玩转KeenTune UI
KeenTune 再次带来开源重磅特性——新增第五大组件:keentune-ui。
国内首发可视化智能调优平台,小龙带你玩转KeenTune UI
|
移动开发 缓存 运维
技术实践第四期|解读移动开发者日常-性能监控平台应用
应用性能监控平台是用来帮助客户提升应用性能质量和稳定性的重要环节,本人作为一名移动端开发者有着丰富的使用和运维经验,希望通过本文分享过往的心得和使用经验,让我参与开发的U-APM这款产品中,作为借鉴可以在中长期规划中帮助更多的开发者。
技术实践第四期|解读移动开发者日常-性能监控平台应用
|
运维 监控 测试技术
巧用友盟+U-APM 实现移动端性能优化—启动速度
移动端性能对用户体验、留存有着至关重要的影响,一个体验良好的应用,只有功能健全还不够,以下是我在性能优化上总结的几点:启动速度优化、流畅度优化、资源优化、内存优化、APK 体积优化。今天先聊聊,启动速度的那些事。
巧用友盟+U-APM 实现移动端性能优化—启动速度
|
移动开发 分布式计算 中间件
【沉淀】从网络中间件到搜索,从移动开发到分布式计算平台,阿里高级专家李睿博谈自己的折腾路
整个过程我觉得还是爱最重要。有爱才有勇气才有希望。我是真的爱写代码。从小学就开始爱,到现在快三十年了也还爱。
30400 8
|
监控 Android开发
阿里巴巴淘票票专家分享:如何利用阿里云ARMS,搭建国际化在线售票的业务监控系统
淘票票为了开拓国际业务,需要做国际化的在线售票,并选择了阿里云新加坡节点作为技术方案,项目上线后急需一套自动化的监控系统代替人肉维护监控。看了ARMS的功能说明,发现其刚好以很低的接入成本来满足我们业务实时监控的需求。
4934 0