SQS Cloudwatch 理智

Question

我正在分析我的 SQS 消费者服务上的最近加载事件，但我遇到了一些对我来说没有意义的 SQS Cloudwatch 指标。从本质上讲，队列似乎因指标中未考虑的消息而过载。让我先总结一下选定的 5 分钟内的数据：

• ApproximateNumberOfMessagesVisible：215,686 -> 233,605（此期间增加 17,919）
• ApproximateNumberOfMessagesNotVisible：2,239 -> 2,129（此期间损失 110）
• NumberOfMessagesSent: 31,441
• NumberOfMessagesDeleted：24,665

令我困惑的是，ApproximateNumberOfMessagesVisible 的增益 (+17k) 是 未 处理的消息数量 (NumberOfMessagesSent - NumberOfMessagesDeleted = ~6k) 的许多倍。

我也包含了有关不可见消息数量的指标（以防有一堆突然变得可见的不可见消息），但情况似乎并非如此。

这怎么可能？

Answer 1

消息如何变得可见？

• 通过被发送到队列。

• 由于消息已收到但未删除而返回可见状态，因此由于在可见性超时到期之前未删除而再次可见。

这里没有提供足够的历史来最终说明 SQS 的计数器是对还是错，但请考虑一下我在 Why do SQS Messages Sometimes Remain In-Flight on a Queue 上的旧评论中的这个建议：

在 Cloudwatch 中，同时选择 NumberOfMessagesReceived 和 NumberOfMessagesDeleted 的图形。您应该会发现一张图完美地覆盖并完全掩盖了另一张图；如果在某种程度上他们不这样做，则强烈表明您正在使用的库或您的消费者中存在问题，这将导致您观察到的症状。

您只能从队列中删除一条消息一次，但如果您有一个进程意外或故意将消息丢弃在地板上，您可以在此之前多次收到一条消息。它们再次变得可见，并且 SQS 将在可见性超时到期后重新传递它们。如果发生这种情况，上述两个指标将不会随着时间的推移而完美排列。

否则，他们应该 - 正如您所看到的统计数据一样。

所以，你是对的，这是没有意义的，如果你的工人都表现完美，并在第一次尝试时处理和删除每条消息。

请注意，如果您使用 AWS 控制台检查消息，我提到的两个计数器不会整齐排列，因为控制台接收消息然后重置它们的可见性超时，就像普通消费者一样，所以这会人为膨胀接收计数器与删除计数器的比较。