gpt4 book ai didi

amazon-web-services - 如何在 SQS 消息发送到死信队列时生成警报?

转载 作者:行者123 更新时间:2023-12-03 14:32:22 24 4
gpt4 key购买 nike

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

最佳答案

我遇到了同样的问题,并使用 Metrics Math 成功实现了它。 Cloudwatch 有一个 RATE() 函数,它:
“返回指标每秒的变化率。计算方法为最新数据点值与前一个数据点值之间的差值除以两个值之间的时间差(以秒为单位)。”
https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/using-metric-math.html
所以我创建了一个警报,它查看 Deadletter 队列上 ApproximateNumberOfMessagesVisible 指标的变化率。当变化率大于 0 时进入报警状态。 以下是报警的 Cloudformation 模板示例:

DeadletterAlarm:
Type: AWS::CloudWatch::Alarm
Properties:
AlarmName: "DEADLETTER_ALARM"
ComparisonOperator: GreaterThanThreshold
EvaluationPeriods: 1
TreatMissingData: missing
Threshold: '0'
Metrics:
- Id: r1
Expression: RATE(FILL(m1, 0))
ReturnData: true
- Id: m1
Label: VisibleAverage
ReturnData: false
MetricStat:
Stat: Average
Period: '300'
Metric:
MetricName: ApproximateNumberOfMessagesVisible
Namespace: AWS/SQS
Dimensions:
- Name: QueueName
Value: "Deadletter_queue_name"

关于amazon-web-services - 如何在 SQS 消息发送到死信队列时生成警报?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/60770763/

24 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com