形形色色Trace系统(1):AWS X-Ray-阿里云开发者社区

开发者社区> 阿里云存储服务> 正文
登录阅读全文

形形色色Trace系统(1):AWS X-Ray

简介: AWS 在2016 Re:Invent上推出了X-Ray,对如今微服务编程,以及ServerLess Architecture非常有前瞻性。另外近期一个比较大新闻是:Google Stack Driver开始支持Zipkin(Twitter 开源的Tracing系统)。

AWS 在2016 Re:Invent上推出了X-Ray,对如今微服务编程,以及ServerLess Architecture非常有前瞻性。另外近期一个比较大新闻是:Google Stack Driver开始支持Zipkin(Twitter 开源的Tracing系统)。Google是一家挺有意思的公司,无论是BigTable、还是Dapper,都是Hbase、Zipkin等开源软件的启蒙老师,但往往过了3-4年后,这些开源技术蒸蒸日上,老师反而要回头来学习并适配这些开源技术,究竟是Google产品化没有做好,还是开源生命力太强?这个问题很有意思,可以以后再聊。

这里主要花一些篇幅简单介绍下几个典型的Tracing系统,主要有:

  • Dapper(Google) : 各 tracer基础
  • StackDriver Trace (Google)
  • Zipkin(twitter)
  • Appdash(golang)
  • 鹰眼(taobao)
  • X-ray(aws)

这篇主要介绍下X-Ray,参考如下材料:

  1. Re:Invent 2016 Slides & Video:https://www.youtube.com/watch?v=s8tB3YhZd9U
  2. 主页:https://aws.amazon.com/cn/xray/

软件发展趋势(X-Ray诞生原因)

在开发与生产过程中,我们经常会遇到Debug问题,在单机时代一般如下:

  1. 开发环境(单机或线上)
  2. 查询日志重新啊问题
  3. 设置断点调试
  4. 增加更多日志或断点
  5. 重复过程并找到问题

这个过程在单机环境屡试不爽,但在如今软件架构(Serverless)体系下却成为了瓶颈,整个过程非常耗时,并且会花大量时间跨服务层定位问题,造成这个困难的主要原因其实和Serverless架构优势正相关:

单机版软件 Serverless 软件(Docker,Microservice,Lamdba等)
优势 开发简单,开发调试快,部署容易,可以通过硬件来Scale 迭代快,非常容易在规模扩展,可靠性高

从和单机版对比看,在Serverless环境下调试主要问题有:

  1. 需要跨多个服务(上下游)进行配合
  2. 需要统一上下游日志格式,既理解日志语义
  3. 实时收集、聚合上下游系统的日志信息

X-Ray主要就是用来解决这个问题的。

screenshot

X-Ray能覆盖什么?

  1. AWS SDK call AWS Service
  2. Non-AWS Services over HTTP and HTTPS
  3. Databases (MySQL, PG, and Dynamo DB)
  4. Queue (Amazon SQS)

X-Ray数据模型

  1. Trace:请求唯一RequestID
  2. Segments:Trace下不同方法(类似Span概念)
  3. Sub-Segements:各子方法
  4. Annotation:可以用来进行Trace筛选的,过滤(聚合)字段
  5. MetaData:和Annotation相同,唯一一点是只是静态文本,无法进行过滤
  6. Error:错误信息
  7. Sampling:采样率

Segments:分为同步和异步两种,同步会输出start-end 两组时间,而异步则只会输出start-time。

screenshot

Sampling配置:支持根据http request各种参数对进行配置:例如对/api/move 下URL访问设置5%采样率,其他为10%,对应用个性化配置非常方便

screenshot

X-Ray 提供如下API

  1. PutTraceSegments:写入Trace信息
  2. BatchGetTracers:传入一批TraceID,批量获得对应信息
  3. GetServiceGraph:对一个Trace进行查询
  4. GetTraceSummaries: 通过一些条件进行Trace信息聚合,例如某个时间段延时大于XX的Trace信息(或统计信息,例如有多少个,平均延时多少)

支持条件非常多:例如http code,user agent,duration(latency)等。一个例子是:

select error_code, avg(duration), count/count(*) where time within [begin, end]

screenshot

收费项

共有2个维度收费项,产生多少Trace Record,在查询过程中扫描了多少Trace Record。

免费额度(每个月)

  • 写入: 0.1 million record
  • 查询(扫描):1 million scaned

收费(超过免费额度部分):

  • 写入:1 million $5
  • 查询(扫描):1 million scan or record $0.5

一些感想

和Zipkin、Google StackDriver比,X-Ray目前提供功能、以及Trace中蕴含的语义不是最全的。但亮点在于和AWS 各存储、Queue等集成、与API Gateway、Lamdba等服务端无缝打通。在AWS这两年主推的Serverless Architecture背景下,这是必不可少的重要一环。

从未来趋势看:X-Ray应该只是AWS在分布式、无服务器编程的一小步,CloudWatch4 Logs、API Gateway、Trouble Shooting等应该会逐渐组成像 Azure App/Log Analytics、Google Stack Driver这样的闭环出来。

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

分享:

阿里云存储基于飞天盘古2.0分布式存储系统,产品多种多样,充分满足用户数据存储和迁移上云需求。

官方博客
存储产品
客户案例