Lambdaの処理で例外が発生した際に、Slackへメッセージを送信する方法について調べました。
方法はいろいろあると思いますが、私の場合は以下の二つが選択肢になりました。
ChatGPTにどちらもエラーが即時検知されSlackにメッセージが送られる認識で良いか尋ねたところ、以下の返答が返ってきました。
(以下ChatGPTの回答)
あなたの理解は概ね正しいですが、「即時検知」という点に関して少し補足が必要です。
1. エラーの検知とメトリクスの増加
- エラーの検知:
aws_cloudwatch_log_metric_filterのpatternで指定された[ERROR]が、Lambda関数のログに記録されると、このパターンに一致するログイベントが検出されます。 - メトリクスの増加: このエラーログが検出されると、
metric_transformationで指定されたメトリクス（ErrorCount）が増加します。このメトリクスは、value = “1”が指定されているので、エラーが発生するたびに1ずつ増加します。2. CloudWatch Metric Alarmの動作
- アラームの発動: メトリクスが指定された条件（ここでは「
GreaterThanThreshold」および「threshold = 1」）を満たすと、aws_cloudwatch_metric_alarmがアラームを発動します。この条件は、評価期間（evaluation_periods = 1）内にメトリクスの合計が1以上になった場合にアラームが発動するという意味です。 - SNSの呼び出し: アラームが発動すると、
alarm_actionsで指定されたSNSトピック（aws_sns_topic.lambda_error_notifications.arn）が呼び出され、通知が送信されます。3. メトリクスの集計とアラームの発動タイミング
- 集計間隔: CloudWatchメトリクスは通常、1分間隔で集計されます。したがって、エラーログが記録されてからメトリクスが増加し、それをもとにアラームが発動するまでには最大で1分の遅延が発生する可能性があります。
- 即時性: 「即時検知」という点では、メトリクスの集計はリアルタイムに近い形で行われますが、完全な即時性はありません。1分単位の遅延が発生する可能性があるため、完全なリアルタイム検知ではなく、ほぼリアルタイムでの検知と考えると良いでしょう。
まとめ
- エラーログが発生した場合:
aws_cloudwatch_log_metric_filterによって検知され、指定されたメトリクスが増加します。 - メトリクスの集計: メトリクスは通常1分間隔で集計され、条件を満たすとアラームが発動します。
- SNSの呼び出し: アラームが発動すると、SNSを介して通知が送信されます。
- 遅延の可能性: メトリクスの増加とアラームの発動には最大1分程度の遅延が発生する可能性があるため、完全な「即時検知」ではありません。
(ChatGPTの回答ここまで)
上記から、CloudWatch Metric Alarmを使うとLambdaのロジック内でエラー通知処理のコードは不要になる点がメリットではあるが、メトリクスの集計のタイミング次第で最大1分ほどの遅延が発生するらしいことがわかりました。
今回はリアルタイム性が問われないバッチ処理のエラー通知なのでCloudWatch Metric Alarmを使う実装にしました。
今後即時にエラー検知をする必要がある場面ではLambdaのロジック内でエラー通知を行う方法も試してみたいと思います。
