为什么 SQS 中的 ApproximateAgeOfOldestMessage 不大于大约 5 分钟
Why is ApproximateAgeOfOldestMessage in SQS not bigger than approx 5 mins
我正在 java 中利用 spring 云 aws 消息传递 (2.0.1.RELEASE) 从 SQS 队列中使用。如果相关，我们使用默认设置，java 10 和 spring 云 Finchley.SR2，
我们最近遇到了一个问题，由于应用程序错误导致无法处理消息，导致异常并且消息没有被确认（删除）。稍后重试消息（这是可取的），大概是在可见性超时过后（再次使用默认值），我们没有在此处自定义设置。
我们几天都没有发现上述错误，这意味着消息接收计数非常高，并且消息在概念上已经在队列中等待了一段时间（到现在已有几天）。我们考虑创建一个云监视 SQS 警报，以提醒我们将来出现类似情况。唯一合适的指标似乎是 ApproximateAgeOfOldestMessage。
遗憾的是，在观察这个指标时我看到了这个：
最大年龄不会超过 5 分钟（尽管我知道它已经过了几天）。如果每次接收发生时消息都变老，假设没有收到确认并且消息没有被删除 - 而是在可见性超时结束后再次变得可用，这个图表应该不会高很多？
我不知道这是否是 spring 云 aws 消息传递使用消息的方式所特有的，或者它是否是一般的 SQS 怪癖，但我的预期是如果消息被放置在队列 5 天前，消费者没有成功消费消息，那么最大年龄将是 5 天？
事实上，如果消息被消费者接收，但最终没有被删除，那么最大年龄实际上是消费者调用之间的长度吗？
任何人都可以确认我的期望是否不正确，即这确实是 SQS 的预期行为方式（它不认为年龄是自消息首次放入队列以来的持续时间，而是认为这是接听电话之间的时间？
基于 similar question on AWS forums，这显然是常规 SQS 队列的错误，其中只有一条消息受到影响。
为了针对此问题设置一个有用的警报，我建议设置一个 dead-letter-queue（消息在达到可配置的无删除消耗次数后自动投递），并针对大小发出警报死信队列的数量 (ApproximateNumberOfMessagesVisible)。
我认为这可能与此指标的 poison pill 处理有关。尝试 3 次以上后，该消息将不会包含在指标中。来自 the AWS docs:
After a message is received three times (or more) and not processed,
the message is moved to the back of the queue and the
ApproximateAgeOfOldestMessage metric points at the second-oldest
message that hasn't been received more than three times. This action
occurs even if the queue has a redrive policy.
我正在 java 中利用 spring 云 aws 消息传递 (2.0.1.RELEASE) 从 SQS 队列中使用。如果相关，我们使用默认设置，java 10 和 spring 云 Finchley.SR2，
我们最近遇到了一个问题，由于应用程序错误导致无法处理消息，导致异常并且消息没有被确认（删除）。稍后重试消息（这是可取的），大概是在可见性超时过后（再次使用默认值），我们没有在此处自定义设置。
我们几天都没有发现上述错误，这意味着消息接收计数非常高，并且消息在概念上已经在队列中等待了一段时间（到现在已有几天）。我们考虑创建一个云监视 SQS 警报，以提醒我们将来出现类似情况。唯一合适的指标似乎是 ApproximateAgeOfOldestMessage。
遗憾的是，在观察这个指标时我看到了这个：
最大年龄不会超过 5 分钟（尽管我知道它已经过了几天）。如果每次接收发生时消息都变老，假设没有收到确认并且消息没有被删除 - 而是在可见性超时结束后再次变得可用，这个图表应该不会高很多？
我不知道这是否是 spring 云 aws 消息传递使用消息的方式所特有的，或者它是否是一般的 SQS 怪癖，但我的预期是如果消息被放置在队列 5 天前，消费者没有成功消费消息，那么最大年龄将是 5 天？
事实上，如果消息被消费者接收，但最终没有被删除，那么最大年龄实际上是消费者调用之间的长度吗？
任何人都可以确认我的期望是否不正确，即这确实是 SQS 的预期行为方式（它不认为年龄是自消息首次放入队列以来的持续时间，而是认为这是接听电话之间的时间？
基于 similar question on AWS forums，这显然是常规 SQS 队列的错误，其中只有一条消息受到影响。
为了针对此问题设置一个有用的警报，我建议设置一个 dead-letter-queue（消息在达到可配置的无删除消耗次数后自动投递），并针对大小发出警报死信队列的数量 (ApproximateNumberOfMessagesVisible)。
我认为这可能与此指标的 poison pill 处理有关。尝试 3 次以上后，该消息将不会包含在指标中。来自 the AWS docs:
After a message is received three times (or more) and not processed, the message is moved to the back of the queue and the ApproximateAgeOfOldestMessage metric points at the second-oldest message that hasn't been received more than three times. This action occurs even if the queue has a redrive policy.