使用 AWS X-Ray 实现的分布式追踪 - 微服务的性能分析

通过服务地图可视化微服务请求的完整路径,并借助过滤表达式筛选出有问题的追踪。同时介绍与 OpenTelemetry 的集成模式。

X-Ray 概述

X-Ray 是一项追踪分布式应用程序的请求并定位性能瓶颈的服务。在 API Gateway → Lambda → DynamoDB 这样的服务链中,它会可视化每个步骤的耗时和错误。通过服务地图可以直观地掌握微服务之间的依赖关系,并立即定位延迟高的服务和错误率高的服务。

追踪与采样

将插桩库集成到应用程序后,HTTP 请求、AWS SDK 调用、SQL 查询等会被自动追踪。新实现时的首选方式是使用 AWS Distro for OpenTelemetry(ADOT)进行插桩。传统的 X-Ray SDK 和 X-Ray 守护进程已于 2026 年 2 月 25 日进入维护模式,不再添加新功能,因此今后构建的应用程序不选择它们。Lambda 只需启用主动追踪,API Gateway 只需在 REST API 的阶段设置中启用追踪,无需插桩即可开始追踪。通过采样规则控制追踪的收集率。默认情况下,每秒 1 个请求 + 额外请求的 5% 会被采样。对高流量的服务降低采样率以控制成本,对低流量的服务则以 100% 采样追踪所有请求。

服务地图与性能分析

X-Ray 的服务地图根据追踪数据自动生成,直观地显示微服务之间的依赖关系、各服务的延迟和错误率。由于节点的颜色会根据延迟和错误率变化,可以一眼定位有问题的服务。点击特定节点后,会显示该服务的响应时间分布(直方图),可以查看 P50、P95、P99 的延迟。通过使用过滤表达式筛选到特定条件(发生错误的追踪、延迟超过 3 秒的追踪等),可以高效地调查问题的根本原因。Insights 功能通过统计模型监控服务的故障率,将超出预期范围的波动检测为异常,并提供受影响请求的示例追踪。它不会自动对整体生效,需要按追踪组启用 Insights。

与 OpenTelemetry 的集成和实现模式

X-Ray 支持与 OpenTelemetry(OTel)的集成。可以使用 AWS Distro for OpenTelemetry(ADOT)将通过 OTel SDK 插桩的应用程序的追踪发送到 X-Ray。由于 OTel SDK 提供供应商中立的插桩 API,即使将来把后端更换为 Jaeger 或 Zipkin,也无需修改应用程序代码。对于 Lambda 函数,只需启用 X-Ray 的主动追踪即可自动插桩,无需集成额外的库。在 ECS 和 EKS 中,将 ADOT Collector 部署为边车容器(在 EKS 中为 DaemonSet),由它接收应用程序容器发送的追踪数据并转发到 X-Ray。过去承担这一角色的 X-Ray 守护进程如前所述已进入维护模式,因此新的配置使用 ADOT Collector。也可以创建自定义子分段,测量外部 API 调用和数据库查询各自的延迟。如果也在 Datadog 中处理 X-Ray 的追踪,AWS X-Ray 集成会将其转换为 Datadog APM 的追踪,并显示在 Lambda 函数的详情界面中。通过 OTel SDK 插桩的应用程序的数据也可以发送到 Datadog。截至 2026 年 10 月,推荐使用 Datadog Agent 中包含的 DDOT Collector 的方式。在 Datadog APM 中可以将追踪与日志和指标关联起来查看,Datadog 也为过去需要 X-Ray 的用途提供了自有的插桩。具体步骤见 Datadog 关于 AWS X-Ray 集成的官方文档。

X-Ray 的定价

X-Ray 的费用由追踪的记录数、检索(扫描)数,以及 Insights 处理的追踪数这 3 部分组成。以下是截至 2026 年 8 月 / 东京区域的单价。追踪的记录每月前 100,000 条免费,之后每 100 万条 5.00 美元。追踪的检索(扫描)每月前 1,000,000 条免费,之后每 100 万条 0.50 美元。在启用了 Insights 的组中,每处理 100 万条追踪会在记录费用之外另行收取 1.00 美元。由于这不是一项无需额外费用即可使用的功能,基本做法是只对想要监控的组启用。调整采样率来控制追踪量是最有效的成本优化措施。推荐区别对待,将高流量服务的采样率降低到 1%,将低流量服务的采样率设为 100%。此外,如果想在不通过采样进行削减的情况下搜索大范围的跨度,也可以选择启用 CloudWatch 的 Transaction Search。不过,计费依据会从追踪条数变为摄取的跨度的数据量(GB)和已建立索引的跨度数。单价因区域而异,请在官方定价表中确认。

定位瓶颈与根本原因分析

在微服务中,一个请求会经过众多服务,因此很难掌握延迟或故障发生在哪里。X-Ray 会可视化请求经过的每个服务的耗时,可以定位哪个区段慢。通过将处理细分并进行测量,可以将范围缩小到数据库查询、外部 API 调用等成为瓶颈的位置。发生错误时,也可以从追踪中查明错误发生在哪个服务的哪个处理中。将分布式的处理作为一个连续的流程进行可视化,使快速定位根本原因成为可能。

在运维中的利用

X-Ray 不仅有助于故障处理,也有助于平时的持续监控。查看显示服务之间依赖关系的服务地图,可以一眼掌握整个系统的组成和健康状况。跟踪延迟和错误率的趋势,监控性能是否在逐渐下降。如果与指标和日志结合使用,就可以按照在检测到数值异常时用追踪深入挖掘具体原因的流程推进调查。也可以设定性能目标,并用追踪数据确认达成情况。日常地利用可视化的追踪,是稳定的服务运维的支撑。

总结

X-Ray 是一项可视化微服务架构中请求完整路径的分布式追踪服务。其主要特点是通过服务地图掌握依赖关系、借助过滤表达式筛选有问题的追踪,以及基于与 OpenTelemetry 的集成的供应商中立插桩。可以根据部署形态选择插桩方法,例如 Lambda 的主动追踪或 ADOT 边车。

参考资料(AWS 官方)

本页的第一手信息来源是 AWS 官方网站及官方文档。最新的规格与价格请以下列官方页面为准。

如本页内容与官方文档不一致,请以官方文档为准。

分享