形形色色Trace系统（1）：AWS X-Ray

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主要就是用来解决这个问题的。

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。

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

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]

收费项

共有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这样的闭环出来。