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，参考如下材料：
- Re:Invent 2016 Slides & Video：https://www.youtube.com/watch?v=s8tB3YhZd9U
- 主页：https://aws.amazon.com/cn/xray/
软件发展趋势（X-Ray诞生原因）
在开发与生产过程中，我们经常会遇到Debug问题，在单机时代一般如下：
- 开发环境（单机或线上）
- 查询日志重新啊问题
- 设置断点调试
- 增加更多日志或断点
- 重复过程并找到问题
这个过程在单机环境屡试不爽，但在如今软件架构（Serverless）体系下却成为了瓶颈，整个过程非常耗时，并且会花大量时间跨服务层定位问题，造成这个困难的主要原因其实和Serverless架构优势正相关：
| 单机版软件 | Serverless 软件（Docker，Microservice，Lamdba等） | |
|---|---|---|
| 优势 | 开发简单，开发调试快，部署容易，可以通过硬件来Scale | 迭代快，非常容易在规模扩展，可靠性高 |
从和单机版对比看，在Serverless环境下调试主要问题有：
- 需要跨多个服务（上下游）进行配合
- 需要统一上下游日志格式，既理解日志语义
- 实时收集、聚合上下游系统的日志信息
X-Ray主要就是用来解决这个问题的。
X-Ray能覆盖什么？
- AWS SDK call AWS Service
- Non-AWS Services over HTTP and HTTPS
- Databases (MySQL, PG, and Dynamo DB)
- Queue (Amazon SQS)
X-Ray数据模型
- Trace：请求唯一RequestID
- Segments：Trace下不同方法(类似Span概念)
- Sub-Segements：各子方法
- Annotation：可以用来进行Trace筛选的，过滤（聚合）字段
- MetaData：和Annotation相同，唯一一点是只是静态文本，无法进行过滤
- Error：错误信息
- Sampling：采样率
Segments：分为同步和异步两种，同步会输出start-end 两组时间，而异步则只会输出start-time。
Sampling配置：支持根据http request各种参数对进行配置：例如对/api/move 下URL访问设置5%采样率，其他为10%，对应用个性化配置非常方便
X-Ray 提供如下API
- PutTraceSegments：写入Trace信息
- BatchGetTracers：传入一批TraceID，批量获得对应信息
- GetServiceGraph：对一个Trace进行查询
- GetTraceSummaries: 通过一些条件进行Trace信息聚合，例如某个时间段延时大于XX的Trace信息（或统计信息，例如有多少个，平均延时多少）
支持条件非常多：例如http code，user agent，duration（latency）等。一个例子是：
select error_code, avg(duration), count/count(*) where time within [begin, end]
AI 代码解读
收费项
共有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这样的闭环出来。
