Amazon SQS 的可用 CloudWatch 指标

对于标准队列，如果一条消息被接收三次或以上但未删除，SQS 会将其移到队列的后面。然后，该指标会反映下一条未超过接收阈值的消息的期限。即使实施了重新驱动策略，也会发生这种重新排序。

毒丸消息（反复收到但从未删除的消息）在成功处理之前将排除在此指标之外。

当消息超过 maxReceiveCount 后被移到 DLQ 时，期限将重置。在这种情况下，DLQ 的指标反映的是消息被移动的时间，而不是最初发送的时间。

FIFO 队列不会为了保持顺序而对消息进行重新排序。失败的消息会阻止其消息组，直至被删除或到期。如果配置了 DLQ，则消息将在达到接收阈值后发送到 DLQ。

传输中消息是指已被使用者从队列中接收但尚未删除或到期的消息。

此指标可帮助您排除故障和优化 FIFO 队列吞吐量。值越高通常表示并发性越强。

如果队列中有大量积压消息并且该值很低，请考虑扩大使用者规模或增加活动消息组的数量。

有关吞吐量和传输中消息数量上限，请参阅 Amazon SQS 配额。

适用于配置了默认延迟的队列以及使用 DelaySeconds 参数发送的单条消息。

延迟消息在延迟期到期之前一直对使用者隐藏，这可能会影响感知到的队列积压情况或吞吐量。

消息通过 ReceiveMessage API 发送给使用者后即进入传输中状态。

这些消息在可见性超时窗口内会暂时向其他使用者隐藏。

使用此指标来跟踪消息处理延迟或卡住的使用者。

反映队列中当前的处理积压情况。

可以累积的消息数量没有硬性限制，但它们受队列配置的保留期的限制。

值持续较高可能表示使用者预置不足或处理逻辑卡滞。

此指标有助于识别轮询行为中的低效问题或未充分利用的使用者实例。

当队列为空、使用者使用短轮询或者消息处理速度快于生成速度时，可能会出现高值。

这并不能准确反映队列状态。它反映的是服务端行为，可能包括重试。

SQS 根据 MessageDeduplicationId 或基于内容的哈希（如果启用）对消息进行重复数据删除。

值较高可能表示创建者在 5 分钟的重复数据删除窗口内反复发送同一消息。

使用此指标排除冗余创建者逻辑问题或确认重复数据删除是否按预期运行。

此指标会计算所有成功的删除操作，即使同一条消息被删除多次也是如此。

值高于预期的常见原因包括：

使用此指标来跟踪消息处理成功率，但不要将其视为唯一已删除消息的确切计数。

这包括返回给使用者的所有消息，包括那些由于可见性超时到期而随后返回到队列的消息。

如果某条消息未被删除，则可能会被多次接收，这可能导致此指标超过发送的消息数量。

使用此指标来跟踪使用者活动，但不要将其视为唯一已处理消息的计数。

手动调用 SendMessage 或 SendMessageBatch 都会计算在内，包括那些直接定向 DLQ 的调用。

超过 maxReceiveCount 后自动移到 DLQ 的消息不包含在此指标中。

因此，NumberOfMessagesSent 可能低于 NumberOfMessagesReceived，尤其是在重新驱动策略在后台将许多消息移到 DLQ 的情况下。

在队列收到第一条消息之前，此指标不会显示在 CloudWatch 控制台中。

使用此指标来跟踪每条消息的大小（以字节为单位）。这对于分析有效载荷趋势或估算吞吐量成本非常有用。

SQS 的最大消息大小为 1 MiB。

通过跟踪使用过多资源的消息组，帮助识别多租户环境中潜在的嘈杂邻居问题。

使用此指标来设置警报，当嘈杂组的数量超过可接受的阈值时触发，表示可能存在队列公平性问题。

能够查看标准速率消息组的队列积压情况，不包括来自嘈杂邻居的消息。

通过筛除嘈杂邻居的影响，帮助确定典型消息组的真实处理积压情况。

跟踪来自行为良好的消息组的传输中消息（正在处理但尚未删除）。

使用此指标来监控常规消息组的处理吞吐量，并检测不是由嘈杂邻居引起的处理瓶颈。

帮助监控来自具有正常或预期吞吐模式的消息组（而不是高容量或嘈杂组）的延迟消息积压情况

有助于了解未来处理需求并为典型工作负载进行容量规划。

用于监控 SLA 合规性并检测具有正常或预期吞吐量模式的消息组（而不是高容量或嘈杂消息组，否则可能会歪曲指标）中的处理瓶颈。

使用此指标设置消息处理超时警报，忽略来自嘈杂邻居的人为旧消息。