亚马逊云科技 X-Ray 请求追踪与故障排查实践

­­­­

越来越多的亚马逊云科技用户采用微服务架构，并需要多业务模块的链路追踪以识别和排查导致性能问题和错误的原因。借助 X-Ray，我们可以获取关于应用程序的调用信息，追踪各个接口的调用路径，可用性与时延，并快速分析与定位调用失败/高延迟的根本原因。

在高SLA的应用服务，如直播，游戏，在线教育等场景中，用户对于链路追踪需求有以下几点：首先，客单价高，对于各服务的SLA要求高，应急措施要求准确快速；同时，应用涉及多业务模块，需要详细的调用关系图与智能监控指标聚合与自动预警功能；此外，终端用户服务请求有明显峰值，任何性能瓶颈对整体业务会产生较大影响。

针对以上需求，X-Ray作为亚马逊云科技的托管的分布式应用追踪服务，具有以下优势：首先，X-Ray为托管服务，可以快速进行测试验证，无需预置环境，使用过程按需付费，无需预估存储分析费用，在高并发场景中保证高可用性，最小化运维成本；其次，X-Ray与亚马逊云科技其他托管服务以及第三方开源服务对接便捷，支持OpenTelemetry规范，对于业务开发逻辑影响小；最后，X-Ray是亚马逊云科技 observability solution中的重要服务，X-Ray控制台中有详细的可视化，历史统计与异常检测功能，支持自定义过滤与统计维度，并可以与observability服务，如Cloudwatch ServiceLens 等服务一起进行全方位业务架构可用性洞察，并可以灵活设置通知出发机制，有效缩短MTTI（Mean Time to Identify）。

本文将就上述业务场景，讲解X-Ray的部署配置，故障排查与实战建议。

X-Ray的部署配置

首先，我们进行亚马逊云科技 X-Ray的部署与配置。用户有两种收集trace数据方式：通过X-RAY SDK 或 OpenTelemetry SDK。X-RAY SDK 为亚马逊云科技提供的官方 SDK，支持Java, Go, Nodejs, Python, .Net, Ruby语言，并可以以字节码注入的方式减少注入工作量。此外，对于不希望修改业务代码的用户可以采用OpenTelemetry协议与X-Ray agent进行通信，即使用亚马逊云科技 Distro for OpenTelemetry（ADOT）部署方式。

X-Ray 代理可从日志文件中收集数据，并将其发送到 X-Ray 服务，以便进行聚合、分析和存储，使您能够更轻松地将数据发送到 X-Ray 服务。X-Ray agent以独立进程的方式运行在实例（EC2）或者容器服务（EKS/ECS）上。在容器化部署亚马逊云科技 X-Ray agent时，用户可以选择DaemonSet或者SideCar两种方式，这两种部署方式差异见图1。在选择部署方式时，主要以集群规模，运维工作量，资源占用，以及定制场景等方面进行综合考虑。如果集群规模大，复杂度高，或者定制化与隔离需求高，推荐采用SideCar模式。相反，如果集群规模小，业务需求统一，可以考虑DaemonSet模式。

图1 DaemonSet与SideCar部署方式差异

在部署完成并确认请求数据记录返回agent后，我们可以进入X-Ray控制界面。

图2 X-Ray service map界面

X-Ray故障排查

X-Ray可以显著提升故障排查效率，并与亚马逊云科技其他监控服务联动与自动化故障通知，优化排查流程，在用户有明确感知之前快速发现，定位，解决问题，维护高级别SLA。为了演示X-Ray故障排查流程，我们假定某一天SRE平台接到了来自Amazon EventBridge的报警，该报警格式如下：

图3 Amazon EventBridge报警格式范例

可以看到，报警来自于X-Ray Insight，该服务特性是基于X-Ray链路追踪的返回数据建立后台异常检测模型，并提供业务侧的API可用性观察建议。在X-Ray控制台左侧Insight（洞察）页面下，我们可以看到对应信息：

­

图4 X-Ray Insight控制台

查看Service Map页面，我们发现某一个调用链路突然出现Fa­ult错误，报错是从API Gateway发起的，点击故障节点，看到历史响应分布情况。

图5 X-Ray Service Map节点信息

点击左侧—Traces, 可以看到segment的列表，以及对应的响应时长，返回值，url 和client ip 等信息。

图6 X-Ray Trace页面

在X-Ray控制台左侧分析页面，根据user，HTTP status code与时间范围等维度进行筛选，发现蓝色时间段业务侧出现了异常（无有效返回），我们明确了故障的准确起始时间。

图7 X-Ray 分析页面

这时我们明确了出现故障的调用链，接下来进入Amazon CloudWatch 进行metric和log的联动查询。Amazon CloudWatch 是一种面向开发运营工程师、开发人员、站点可靠性工程师 (SRE) 和 IT 经理的监控和可观测性服务，以监控应用程序、响应系统范围的性能变化、优化资源利用率，并在统一视图中查看运营状况。在Amazon CloudWatch 下的Service Map, 可以看到API Gateway后的2个lambda均有4xx metric警告

图8 Amazon CloudWatch Service Map页面

之后，我们点击View logs, 可以进行对应日志分析页面，运行查询条件

fields @message
| parse @message "[*] *" as loggingType, loggingMessage
| fields @message | filter @message like /Error/
| display loggingMessage

可以看到如下返回：

图9 CloudWatch Log Insights查询页面

因此我们确认问题根源为其中一个lambda。这次异常事件得以高效定位。

X-Ray实战建议

在API调用量较大时，我们可以进行采样策略。采样策略可以在不修改业务代码的前提下控制返回X-Ray的trace数据量。 采样可以基于自定义。如下图所示，在MyCustomRule规则中，X-Ray记录每秒第一个请求，以及任何额外请求的 5％。如果每秒实际有21个请求，X-Ray agent会返回控制台1+5%*20=2条记录。此外，也可以和CloudWatch与Lambda联合，根据用户请求并发数设置动态采样机制。

图10 X-Ray 自定义采样策略

针对多环境版本与多业务追踪模块需求下，我们可以通过设置筛选器表达式（Fault ==True OR responsetime>5）来创建组。然后，我们可以独立查看不同组的Service map，更快速定位故障。

图11 X-Ray分组

总结

在本篇blog中，我们以业务场景为例介绍亚马逊云科技分布式追踪系统X-Ray的部署配置，模拟故障排查与实战建议三大部分，并展示X-Ray如何与CloudWatch监控指标与日志分析功能结合, 通过自动化通知有效缩短MTTI。在使用过程中如有问题，欢迎联系我们。

本篇作者

本篇作者