使用 Amazon 进行监控 CloudWatch - Amazon DynamoDB
Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异,请参阅 中国的 Amazon Web Services 服务入门 (PDF)

本文属于机器翻译版本。若本译文内容与英语原文存在差异,则一律以英文原文为准。

使用 Amazon 进行监控 CloudWatch

您可以使用监控 Amazon DynamoDB,它会收集 CloudWatch来自 DynamoDB 的原始数据并将其处理为可读的、近乎实时的指标。这些统计数据保留一段时间,这样可以访问历史信息,更好地了解您的 Web 应用程序或服务的执行情况。默认情况下,DynamoDB 指标数据会自动发送到。 CloudWatch 有关更多信息,请参阅什么是亚马逊 CloudWatch? 以及《亚马逊 CloudWatch 用户指南》中的指标保留率

如何使用 DynamoDB 指标?

DynamoDB 报告的指标提供可通过不同方式分析的信息。下面的列表显示这些指标的一些常见用途。这些是入门建议,并不全面。

我如何?

相关指标

How can I monitor the rate of TTL deletions on my table?

可以在指定时间段内监控 TimeToLiveDeletedItemCount,跟踪表上的 TTL 删除率。有关使用该TimeToLiveDeletedItemCount指标的无服务器应用程序的示例,请参阅使用 Dynamo DB 存活时间 (TTL) Amazon Lambda 和 Amazon Data Firehose 自动将项目存档到 S3。

How can I determine how much of my provisioned throughput is being used?

可以在指定时间段内监控 ConsumedReadCapacityUnitsConsumedWriteCapacityUnits,跟踪预置吞吐量的使用。

How can I determine which requests exceed the provisioned throughput quotas of a table?

如果请求中的任何事件超过预置吞吐量配额,ThrottledRequests 将递增 1。要了解限制请求的事件,为表及其索引比较 ThrottledRequestsReadThrottleEventsWriteThrottleEvents 指标。

How can I determine if any system errors occurred?

可以监控 SystemErrors 以确定是否有任何请求导致 HTTP 500(服务器错误)代码。通常,此指标应等于零。如果不是,可能需要调查。

注意

处理项目时可能遇到内部服务器错误。这些是表的生命周期中的预期错误。可立即重试所有失败的请求。

了解和分析 DynamoDB 响应时间

在分析延迟时,通常最好检查平均值。偶尔的延迟高峰并不需要担忧。但是,如果平均延迟较高,则可能是潜在问题造成的。

延迟分为两类:API 延迟和服务端延迟。DynamoDB 的 API 延迟是从以下过程的步骤 1 到步骤 11 之间测量的。服务端延迟是从 API 到达请求路由器(步骤 4)的时刻,到 RR 向应用程序用户发回结果(步骤 11)所花的时间测量的。您可以使用 Amazon CloudWatch 指标分析服务端延迟SuccessfulRequestLatency

当任何应用程序对 DynamoDB 进行任何 DynamoDB API 调用时,例如向 DynamoDB 表发出 GetItem 操作,将执行以下步骤。

  1. 应用程序使用本地 DNS 服务器解析 DynamoDB 公有端点。

  2. 应用程序连接到步骤 1 中解析出的 IP 地址,并发出 API 调用。

  3. DynamoDB 公有端点接受请求,并将其转发到称为请求路由器(RR)的组件。

  4. 一旦 API 请求到达请求路由器(RR),RR 就会对 API 调用进行身份验证和授权。RR 还会在这个阶段进行节流检查。

  5. 完成所有检查后,请求路由器(RR)创建它从 API 请求中获得的分区键值的哈希。根据哈希值,请求路由器(RR)查找分区信息(存储节点)的详细信息。

  6. 存储节点代表存储着客户表数据的服务器。单个分区(不要与主键或分区键混淆)由一组 3 个存储节点组成。在这三个存储节点中,一个节点充当该分区的领导节点,其余两个节点充当跟随节点。

  7. 如果这个 API 调用是写入请求或者是强一致性读取请求,则请求路由器(RR)会找到该分区的领导节点并将 API 请求转发到该特定节点。如果是最终一致读取请求,请求路由器(RR)会将请求随机转发到该分区的领导节点或任何跟随节点。

  8. 在正常情况下,请求路由器会在第一次尝试时就能够到达存储节点。如果此尝试失败,RR 会多次重试以到达存储节点。在尝试连接到存储节点时,RR 始终会为现有尝试留出足够的时间,然后尝试连接到不同的 SN。这是内部微服务重试,而不是可配置的 SDK 重试。

  9. 在此阶段,API 请求到达存储节点(SN)层,SN 开始处理该请求,根据 API 调用读取或写入数据。

  10. 成功处理 API 请求后,存储节点(SN)将结果或响应代码返回给发起请求的 RR。

  11. 最后,请求路由器将结果转发给客户应用程序。


                    DynamoDB API 调用步骤
注意
  • 对于大多数原子操作,例如 GetItemPutItem,预期的平均延迟应该在几毫秒。QueryScan 等非原子操作的延迟取决于许多因素,包括结果集的大小以及查询条件和筛选条件的复杂性。

  • DynamoDB 不测量应用程序连接到 DynamoDB 公有端点所花的时间量,也不测量应用程序从公有端点下载结果所花的时间量。