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