Lambdaのエラーを1回でも検知するCloudWatchアラーム｜Sumと欠落データの設定

Lambdaが1回でもエラー終了したら通知したい場合、CloudWatchアラームの基本はErrorsの統計をSum（合計）にし、期間内の合計が1以上かを評価する構成です。

Minimum（最小）でも同じ結果になるとは限りません。また、「正常終了の0」と「実行されずデータがない期間」は別の状態です。この2点を分けると、検知漏れや不要な通知を防ぎやすくなります。

1回のエラーを拾うなら、MinimumではなくSum

LambdaのErrorsは、呼び出し結果を表すメトリクスです。正常終了では0、関数エラーでは1のデータポイントが記録されます。1分間に4回実行し、そのうち1回だけエラーだった例を考えます。

この期間のSumは1ですが、Minimumは0です。そのため、Sumが1以上という条件は満たしても、Minimumが1以上という条件は満たしません。Minimumでは、同じ期間に正常実行が混ざるとエラーを見逃すことになります。

1分ごとのエラー件数を見る場合にSumを使うことは、Lambdaメトリクスの公式資料にも記載されています。

最初に検討する設定例

「直近1分のどこかで関数エラーが発生したら検知する」ことを目的とする場合の例です。機械学習による異常検出ではなく、静的なしきい値を使います。

この設定は1回のエラーも通知対象にするため、想定内のエラーが多い処理では通知が増えます。エラー件数や継続時間で通知したい場合は、しきい値・期間・評価データポイント数を要件に合わせて変更します。メトリクス反映やアラーム評価に時間がかかるため、例外発生と同時に即座に通知されることを保証する設定ではありません。

正常実行の0と、欠落データを区別する

正常終了が報告されれば、Errorsには0のデータポイントがあります。一方、関数が呼び出されていない期間などではデータが欠落することがあります。「Errorsはエラーのときだけ出る」と考えて設定しないことが大切です。

実行されていない期間をエラー扱いしたくない、という目的なら、欠落をしきい値違反なしとして扱う notBreaching が選択肢になります。ただし、これは欠落を評価上どう扱うかの設定です。関数や業務全体が正常であることを証明するものではありません。

notBreachingとignoreは、復旧の考え方で選ぶ

エラー発生後に長く呼び出しがない処理では、ignoreを選ぶと、欠落の間はALARM状態を保持する構成にできます。ただし、運用担当者が確認するまで永久にALARMを固定する機能ではありません。後で正常なデータが届き、アラームの復旧条件を満たせば状態は変わります。

また、通常のスライディング評価では、CloudWatchが設定期間数より広い範囲から実データを取得して評価する場合があります。十分な実データがあれば欠落処理の設定は使われません。「1分実行がなかったら必ず即座にOKへ戻る」とは考えず、評価の仕組みを確認してください。詳細はCloudWatchの欠落データ処理に記載されています。

未実行やスロットリングは別に監視する

Errorsは、Lambdaコードやランタイムのエラーを数えます。呼び出しがスロットリングされた場合などは、Errorsだけでは検知できません。定期処理が実行されなかった、という問題も、エラー終了とは分けて考えます。

• 関数エラー：Errorsで確認する。
• スロットリング：Throttlesで確認する。
• 実行されるべき処理の未実行：Invocationsや完了記録、送信元の実行状況で確認する。
• コードが例外を捕捉して正常応答を返す業務エラー：ログやカスタムメトリクスで確認する。

エラー率を監視したい場合も、Errorsの平均をそのまま使うと決めず、ErrorsとInvocationsの合計から目的に合う比率を設計します。

通知先まで含めて検証する

アラームを作ったら、正常・エラー・しばらく未実行という各状態をテスト環境で確認します。対象関数、期間、統計、しきい値、状態遷移、通知の到達を順に確認してください。

一般的な通知アクションは状態の変化に伴って実行されるため、ALARMの間に起きるすべてのエラーへ1件ずつ通知する仕組みとは異なります。個別エラーの追跡にはログや別の通知設計も組み合わせます。アラームの動作はCloudWatchアラームの公式資料を参照できます。

関連する記事

• EventBridgeからLambdaが呼び出されるまでの確認手順
• CloudWatchメトリクスを長期保存する方法