目标

旨在在从 SQS 队列到 lambda 函数的消息超过最大重试次数时触发 CloudWatch 警报。

问题

我认为这很容易并且 NumberOfMessagesReceived 指标会反映这一点。熟悉这一点的人都知道，事实并非如此。

解决方案

“Limbo”解决方案

我对这个问题的快速简便的解决方案是引入一个“Limbo”，它充当第一个 DLQ，并在几秒钟内将消息推送到最终/实际 DLQ。在指标中，这会导致“Limbo”队列的可见消息指标出现峰值。因此，具有“ > 0 ”的警报阈值意味着每次该队列收到消息时都可以发出警报。

然而，每次我们想要这个功能时，我上面的权力都不满意有一个“Limbo”队列。

据我所知，有一些替代方法，但这些方法似乎比Limbo 解决方案更糟糕。

新的 Lambda 函数

第一个是拥有一个新的 lambda 函数，该函数使用 SQS DLQ 作为源并生成警报。

Lambda 运行时拦截

其次是让现有 lambdas 中的逻辑（处理 SQS 消息）读取消息重试的次数，并在最后一次生成警报。这种首先消除了使用队列和重新驱动策略的优势，并且是一种过度设计的解决方案。

公制数学

我能想到的最后一个选择是使用一些度量数学来查看 DLQ 并计算最后 X 分钟内是否有增加。

对于（我确信）必须具有简单实现的解决方案，这些似乎都是奇怪且过于复杂的解决方案。每次 DLQ 收到消息时如何创建警报？