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

使用 Amazon CloudWatch 监控

可以使用 CloudWatch 监控 Amazon DynamoDB，此工具可从 DynamoDB 收集原始数据，近实时处理为可读取的指标。这些统计数据保留一段时间，这样可以访问历史信息，更好地了解您的 Web 应用程序或服务的执行情况。默认情况下，DynamoDB 指标数据自动发送到 CloudWatch。有关更多信息，请参阅《Amazon CloudWatch 用户指南》中的什么是 Amazon CloudWatch？和指标保留。

主题

如何使用 DynamoDB 指标？

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

我如何？

相关指标
How can I monitor the rate of TTL deletions on my table?

可以在指定时间段内监控 TimeToLiveDeletedItemCount，跟踪表上的 TTL 删除率。有关使用 TimeToLiveDeletedItemCount 指标的无服务器应用程序示例，请参阅将 DynamoDB 存活时间（TTL）与 Amazon Lambda 以及 Amazon Kinesis Data Firehose 结合使用，以将项目自动存档到 S3。
How can I determine how much of my provisioned throughput is being used?

可以在指定时间段内监控 ConsumedReadCapacityUnits 或 ConsumedWriteCapacityUnits，跟踪预置吞吐量的使用。
How can I determine which requests exceed the provisioned throughput quotas of a table?

如果请求中的任何事件超过预置吞吐量配额，ThrottledRequests 将递增 1。要了解限制请求的事件，为表及其索引比较 ThrottledRequests 与 ReadThrottleEvents 和 WriteThrottleEvents 指标。
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 调用步骤
注意

  • 对于大多数原子操作，例如 GetItem 和 PutItem，预期的平均延迟应该在几毫秒。Query 和 Scan 等非原子操作的延迟取决于许多因素，包括结果集的大小以及查询条件和筛选条件的复杂性。

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