使用 亚马逊云科技 X-Ray 主动跟踪端到端监控基于 Amazon SNS 的应用程序

作者： 帕斯卡尔·沃格尔 | 2023 年 日

这篇文章由高级顾问丹尼尔·洛奇和高级解决方案架构师大卫·姆博努撰写。

Amazon 简单通知服务 (Amazon SNS) 是一项消息服务，在分布式系统、微服务和事件驱动的无服务器应用程序之间提供高吞吐量、基于推送的多对多消息，现在支持使用 亚马逊云科技 X-Ray 进行主动跟踪。

启用 SNS 的 亚马逊云科技 X-Ray 主动跟踪后，您可以通过查看 SNS 主题的分段详情（例如资源元数据、故障、错误和每个订阅者的消息传输延迟）来识别瓶颈并监控事件驱动型应用程序的运行状况。

这篇博文回顾了在 SNS 上启用 亚马逊云科技 X-Ray 主动跟踪功能的常见用例，在现实场景中可以一致地查看 亚马逊云科技 服务中的跟踪数据。我们介绍了两种架构模式，它们允许您准确了解您的端到端跟踪：从社交网络到 亚马逊简单队列服务 (Amazon SQS) 队列，以及从社交网络主题到亚马逊 Kin esis Data Firehose 流 。

示例无服务器应用程序入门

为了演示适用于 SNS 的 亚马逊云科技 X-Ray 主动跟踪，我们将使用 W ild Rydes 无服务器应用程序，如下图所示。该应用程序使用微服务架构，该架构实现异步消息传送以集成独立系统。

Wild Rydes serverless application architecture

示例无服务器应用程序的工作原理如下：

  1. 亚马逊 API Gateway 接收来自用户的乘车请求。
  2. A WS L am bda 函数处理乘车请求。
  3. 亚马逊 Dynam oDB 桌子可用作乘车存储。
  4. SNS 主题充当乘车请求的粉丝群。
  5. 单个 SQS 队列和 Lambda 函数设置为通过各种后台服务（客户通知、客户会计等）处理请求。
  6. SNS消息过滤器可用于订阅非凡的乘车服务。
  7. Kinesis Data Firehose 交付流将行程请求存档到 亚马逊 Simple Storage Service (Amazon S3) 存储桶 中。

部署示例无服务器应用程序

先决条件

  • 亚马逊云科技 命令行接口 (亚马逊云科技 CLI)
  • 亚马逊云科技 无服务器应用程序模型 (亚马逊云科技 SAM) CLI
  • Git

使用 亚马逊云科技 SAM 的部署步骤

示例应用程序作为 亚马逊云科技 SAM 基础设施作为代码模板提供。

此演示应用程序将在未经授权的情况下部署 API。请考虑控制和管理对您的 API 的访问权限。

  1. 克隆 GitHub 存储库 ：
    
git clone https://github.com/aws-samples/sns-xray-active-tracing-blog-source-code cd sns-xray-active-tracing-blog-sourc
  2. 从源代码构建实验室工件：
    
sam build

  3. 将示例解决方案部署到您的 亚马逊云科技 账户：

    
导出 AWS_REGION=$（aws--profile 默认配置获取区域）sam deploy\--stack-name wild-rydes-async-msg-2\--capability_IAM\--regied 确认 submitrideCompletionFunction 可能没有定义授权，这样可以吗
    ？ [y/n]： 是。

  4. 等到堆栈达到 “ 创建_ 完成” 状态。

有关详细的部署说明，请参阅示例应用程序 Readme.md。

测试应用程序

成功部署应用程序后，生成消息并验证 SNS 主题是否正在发布所有消息：

  1. 查找 API 网关终端节点：
    
导出 AWS_REGION=$（aws--profile 默认配置获取区域）aws cloudformation describe-stack-name wild-rydes-async-msg-2\--query 'Stacks [] .Outputs [？outputkey===`UnicornManagementServiceapiSubmitride CompletionEndpoint`].
    outputValue'\--out
  2. 将此 API 网关终端节点存储在环境变量中：
    
导出 ENDPOINT=$ (aws cloudformation describe-stacks\--stack-name wild-rydes-async-msg-2\--query 'Stacks [] .Outputs [？outputkey==`UnicornManagementServiceapiSubmitride CompletionEndpoint`].
    outputValue'\--output
  3. 使用不同的有效载荷执行以下命令五次或更多次 向提交行程完成端点 发送请求：
    
curl-XPOST-i-H “内容类型\: application/json”-d '{“来自”：“柏林”，“收件人”：“法兰克福”，“时长”：420，“距离”：600，“客户”：“cmr”，“票价”：
    256.50} '$ENDPOINT
  4. 使用 CloudWatch 服务映射 验证应用程序中是否正在传递消息：
    Messages being passed on the CloudWatch service map

有关详细的测试说明，请参阅示例应用程序 Readme.md。

示例应用程序显示了各种用例，这些用例将在以下各节中介绍。

亚马逊 SNS 到亚马逊 SQS fanout 场景

SNS 的常见 应用程序集成场景 是 Fanout 场景。在 Fanout 场景中，发布到 SNS 主题的消息会被复制并推送到多个端点，例如 SQS 队列。这允许进行并行异步处理，是事件驱动的应用程序架构中常用的应用程序集成模式。

当 SNS 主题扩展到 SQS 队列时，这种模式被称为主题队列链接。 这意味着您需要在 SNS 主题和每个订阅者服务之间添加一个队列，在本例中为 SQS 队列。由于消息在 SQS 队列中以持久的方式缓冲，因此如果订阅者进程遇到问题持续数小时或数天，或者遇到异常或崩溃，则不会丢失任何消息。

通过将 SQS 队列放在每项订阅服务之前，您可以利用队列可以充当 缓冲负载均衡器这一事实。 由于每条队列消息都被传送到可能为数众多的消费者进程中的一个，因此可以轻松地向外扩展和向内扩展订阅者服务，并且消息负载分布在可用的消费者进程上。如果突然有大量消息到达，则必须扩展消费者进程的数量以应对额外的负载。这需要时间，您需要等到其他流程开始运行。由于消息在队列中缓冲，因此您不会在此过程中丢失任何消息。

总而言之，在 Fanout 场景或 主题 队列链接模式中：

  • SNS 复制消息并将其推送到多个端点。
  • SQS 将发送端点和接收端点分离。

The fanout scenario is a common application integration scenario for SNS

在 SNS 主题上启用 亚马逊云科技 X-Ray 主动跟踪后，CloudWatch 服务地图向我们展示了完整的应用程序架构，如下所示。

Fanout scenario with an SNS topic that fans out to SQS queues in the CloudWatch service map

在引入有关 SNS 主题的 亚马逊云科技 X-Ray 主动跟踪之前，亚马逊云科技 X-Ray 服务将无法重建完整的服务地图，并且图表中将缺少 SQS 节点。

要查看未启用 AWS X-Ray 主动追踪的集成情况，请打开 t emplate.yaml 并导航到资源 RideCompletionTopic。 注释掉属性 TracingConfig：激活 、重新部署并测试解决方案。然后，服务映射应显示一个不完整的图表，其中 SNS 主题直接链接到使用者 Lambda 函数，省略了 SQS 节点。

对于此用例，假定 Fanout 场景，在 SNS 主题上启用 亚马逊云科技 X-Ray 主动跟踪可提供应用程序中可用的跟踪的完整端到端可观测性。

亚马逊 SNS 到亚马逊 Kinesis Data Firehose 的传输流，用于消息存档和分析

SNS 通常与 Kinesis Data Firehose 传输流一起使用，用于 消息存档 和分析用例。 您可以在 Kinesis Data Firehose 订阅中使用 SNS 主题来捕获、转换、缓冲、压缩数据，并将其上传到亚马逊 S3、亚马逊 Redshi ft、亚马逊 OpenSearch S er vice 、HTTP 端点和 第三方服务提供 商。

我们将按如下方式实现这种模式：

  • 一个 SNS 主题，用于复制消息并将其推送给其订阅者。
  • 用于捕获和缓冲消息的 Kinesis Data Firehose 传送流。
  • 一个 S3 存储桶，用于接收上传的存档消息。

Message archiving and analytics using Kinesis Data Firehose delivery streams consumer to the SNS topic

为了演示这种模式，在 SNS 主题中添加了额外的消费者。同样的 Fanout 模式也适用，Kinesis Data Firehose 传送流与现有消费者一起接收来自 SNS 主题的消息。

Kinesis Data Firehose 传输流可缓冲消息，并配置为将其传送到 S3 存储桶以用于存档目的。或者，可以将 SNS 消息过滤器添加到此订阅中，以选择相关消息进行存档。

在 SNS 主题上启用 亚马逊云科技 X-Ray 主动跟踪后，Kinesis Data Firehose 节点将作为单独的实体出现在 CloudWatch 服务地图上，如下图所示。值得注意的是，S3 存储桶并未出现在 CloudWatch 服务映射上，因为在撰写本博客文章时，Kinesis 尚不支持 亚马逊云科技 X-Ray 主动跟踪。

Kinesis Data Firehose delivery streams consumer to the SNS topic in the CloudWatch Service Map

在以 SNS 为主题引入 亚马逊云科技 X-Ray 主动追踪之前，亚马逊云科技 X-Ray 服务将无法重建完整的服务地图，图中将缺少 Kinesis Data Firehose 节点。要查看未启用 AWS X-Ray 主动追踪的集成情况，请打开 t emplate.yaml 并导航到资源 RideCompletionTopic。 注释掉属性 TracingConfig：激活 、重新部署并测试解决方案。然后，服务地图应显示一张不完整的图表，其中缺少 Kinesis Data Firehose 节点。

对于这个用例，假设使用 Kinesis Delivery Firehose 的数据存档场景，在 SNS 主题上启用 亚马逊云科技 X-Ray 主动跟踪可以在 CloudWatch 服务映射中进一步了解 Kinesis Data Firehose 节点。

在 亚马逊云科技 X-Ray 跟踪详情页面上查看故障、错误和消息传输延迟

亚马逊云科技 X-Ray 跟踪详情页面提供了一个时间表，其中包含每个分段的资源元数据、错误、错误和消息传输延迟。

在 SNS 上启用 亚马逊云科技 X-Ray 主动跟踪后，SNS 主题本身的更多分段以及下游使用者（ AWS:: SNS:: Topic 、AWS:: SQS:: Queue 和 AWS:: k inesisFireHose ）分段都可用，从而为这些分段提供额外的故障、错误和消息传输延迟。这使您可以分析消息及其后端服务中的延迟。例如，一条消息在某个主题中停留了多长时间，以及将消息发送到该主题的每个订阅所需的时间。

Additional faults, errors, and message delivery latency information on AWS X-Ray trace details page

为 SNS 启用 亚马逊云科技 X-Ray 主动跟踪

默认情况下，SNS 主题上不启用 亚马逊云科技 X-Ray 主动跟踪，需要明确启用。

本博客文章中使用的示例应用程序演示了如何使用 亚马逊云科技 SAM 启用主动跟踪。

你可以使用 SNS S etTopicAttributes API 、 SNS 管理控制台或 通过 亚马逊云科技 Cloud Formation 启用 亚马逊云科技 X-Ray 主动跟踪。有关更多选项，请参阅 Amazon SNS 开发者指南 中的 Amazon SNS 中的 主动跟踪 。

清理

要清理作为示例无服务器应用程序的一部分配置的资源，请按照示例应用程序 Readme.md 中概述的说明进行操作。

结论

适用于 SNS 的 亚马逊云科技 X-Ray 主动追踪可在现实场景中实现端到端可见性，这些场景涉及 SNS 到 SQS 和 SNS 到 Amazon Kinesis 等模式。

但它不仅对这些模式有用。启用 SNS 的 亚马逊云科技 X-Ray 主动跟踪后，您可以通过查看 SNS 主题和使用者的区段详情（例如资源元数据、故障、错误和每个订阅者的消息传输延迟）来识别瓶颈并监控事件驱动型应用程序的运行状况。

启用适用于 SNS 的 亚马逊云科技 X-Ray 主动跟踪 ，以准确了解您的端到端跟踪。

如需更多无服务器学习资源，请访问 无服务器世界 。