目标
旨在当从 SQS 队列到 lambda 函数的消息超过最大重试次数时触发 CloudWatch 警报。
问题
我认为这很容易,并且 NumberOfMessagesReceived 指标会反映这一点。熟悉这一点的人都知道,事实并非如此。
解决方案
'Limbo' 解决方案
我对这个问题的快速简单的解决方案是引入一个“Limbo”,它充当第一个 DLQ,并在几秒钟内将消息推送到最终/实际 DLQ。在指标中,这会导致“Limbo”队列的可见消息指标出现峰值。因此,具有“ > 0 ”的警报阈值意味着每次该队列收到消息时都会发出警报。
然而,我上面的权力对于每次我们想要这个功能时都有一个“Limbo”队列并不满意。
据我所知,有一些替代方法,但这些方法似乎比Limbo 解决方案更糟糕。
新的 Lambda 函数
第一个是有一个新的 lambda 函数,它使用 SQS DLQ 作为源并生成警报。
Lambda 运行时拦截
其次是让现有 lambdas(处理 SQS 消息)中的逻辑读取消息已重试的次数,并在最后一次生成警报。这种首先消除了使用队列和重新驱动策略的优势,并且是一种过度设计的解决方案。
度量数学
我能想到的最后一个选择是使用一些度量数学来查看 DLQ 并计算最后 X 分钟是否有增加。
对于什么(我确信)必须有一个简单的实现,这些似乎都是奇怪且过于复杂的解决方案。每次 DLQ 收到消息时如何创建警报?