Jay*_*ork 6 amazon-sqs amazon-web-services amazon-cloudwatch amazon-cloudwatch-metrics cloudwatch-alarms
旨在在从 SQS 队列到 lambda 函数的消息超过最大重试次数时触发 CloudWatch 警报。
我认为这很容易并且 NumberOfMessagesReceived 指标会反映这一点。熟悉这一点的人都知道,事实并非如此。
我对这个问题的快速简便的解决方案是引入一个“Limbo”,它充当第一个 DLQ,并在几秒钟内将消息推送到最终/实际 DLQ。在指标中,这会导致“Limbo”队列的可见消息指标出现峰值。因此,具有“ > 0 ”的警报阈值意味着每次该队列收到消息时都可以发出警报。
然而,每次我们想要这个功能时,我上面的权力都不满意有一个“Limbo”队列。
据我所知,有一些替代方法,但这些方法似乎比Limbo 解决方案更糟糕。
第一个是拥有一个新的 lambda 函数,该函数使用 SQS DLQ 作为源并生成警报。
其次是让现有 lambdas 中的逻辑(处理 SQS 消息)读取消息重试的次数,并在最后一次生成警报。这种首先消除了使用队列和重新驱动策略的优势,并且是一种过度设计的解决方案。
我能想到的最后一个选择是使用一些度量数学来查看 DLQ 并计算最后 X 分钟内是否有增加。
对于(我确信)必须具有简单实现的解决方案,这些似乎都是奇怪且过于复杂的解决方案。每次 DLQ 收到消息时如何创建警报?
我遇到了同样的问题,并使用 Metrics Math 成功实现了它。Cloudwatch 有一个 RATE() 函数,该函数:
“返回指标每秒的变化率。计算公式为最新数据点值与前一个数据点值之间的差值除以两个值之间的时间差(以秒为单位)。”
https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/using-metric-math.html
因此,我创建了一个警报,用于查看死信队列上 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"
Run Code Online (Sandbox Code Playgroud)
| 归档时间: |
|
| 查看次数: |
1672 次 |
| 最近记录: |