翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# Amazon EventBridge でイベント配信をモニタリングするためのベストプラクティス
<a name="eb-monitoring-events-best-practices"></a>

イベント駆動型アプリケーションのビジネスロジックを確実に実行するためには、イベント配信動作をモニタリングすることが重要です。EventBridge には、問題を早い段階にモニタリング、検出、緩和して、信頼性の高いイベント配信を確実にするためのメトリクスが用意されています。これらのメトリクスには次のものが含まれます。
+ `InvocationAttempts`、`SuccessfulInvocationAttempts`、`RetryInvocationAttempts`、`FailedInvocations` などのカウンターベースのメトリクスにより、ターゲットのスロットリングを観察し、エラー率を計算できます。
+ `IngestionToInvocationSuccessLatency` などのレイテンシーベースのメトリクスは、イベントの配信と遅延に関するインサイトを提供します。

これらのメトリクスを使用すると、イベント駆動型アーキテクチャの正常性をモニタリングし、パフォーマンスの低いターゲット、サイズが小さいターゲット、または応答しないターゲットに起因するイベント配信の問題を理解して軽減できます。例えば、ターゲットのスケール不足やスロットリングが長期化すると、過剰な再試行、イベント配信の遅延、継続的な配信エラーが発生する可能性があります。

複数のメトリクスを組み合わせて全体的な概要を把握し、注意深くモニタリングすることをお勧めします。適切なアラームとダッシュボードを設定すると、永続的な問題に早い段階で対処できます。

特定のメトリクスの詳細については、「[EventBridge のメトリクス](eb-monitoring.md#eb-metrics)」を参照してください。

## イベント配信エラーの検出
<a name="eb-monitoring-events-best-practices-delivery-failures"></a>

EventBridge には、ルールごとにターゲット呼び出し、つまりイベント配信の試行をレポートするように設定できるメトリクスが含まれています。

ルールレベルで次のメトリクスをモニタリングすることをお勧めします。
+ `InvocationAttempts`: イベント配信の再試行を含む、EventBridge がターゲットを呼び出そうとした合計回数を監視。
+ `SuccessfulInvocationAttempts`: EventBridge がターゲットにイベントを正常に配信した呼び出し試行回数。
+ `RetryInvocationAttempts`: イベント配信の再試行を表す試行回数。

  `RetryInvocationAttempts` の増加は、サイズが小さいターゲットの早期の兆候である可能性があります。

さらに、再試行回数の増加は配信の問題の最初の兆候になる可能性があるため、すべてのターゲット呼び出しに対する成功したターゲット呼び出しの割合を追跡する単一のメトリクスを作成することをお勧めします。例えば、CloudWatch ではメトリクス数式を使用して、次の式を使って `SuccessfulInvocationRate` という名前のメトリクスを作成できます。

`SuccessfulInvocationRate` = `SuccessfulInvocationAttempts` / ` InvocationAttempts`

次に、要件に応じて、特定のしきい値に達したときに通知を作成するように CloudWatch アラームを設定できます。

一時的なトラフィックの急増や呼び出しエラーにより `SuccessfulInvocationRate` が時折減少することは正常と見なされる可能性がありますが、一定の不一致は、ターゲットの設定ミスを示すものであり、責任共有モデルの一部として対処する必要があります。

メトリクス数式の詳細については、「*Amazon CloudWatch ユーザーガイド*」の「[CloudWatch メトリクスでの数式の使用](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/using-metric-math.html)」を参照してください。

デフォルトでは、EventBridge は 24 時間、最大 185 回イベント配信を試行します。EventBridge がこれらの再試行回数を使い果たした後、EventBridge はイベントを削除するか、デッドレターキューが指定されている場合はそれをデッドレターキューに送信します。詳細については、「[イベント配信の再試行](eb-rule-retry-policy.md)」を参照してください。配信に失敗した場合にイベントが失われないように、ルールターゲットごとにデッドレターキューを設定することをお勧めします。詳細については、「[デッドレターキューの使用](eb-rule-dlq.md)」を参照してください。

EventBridge が指定されたターゲットに配信できなかったイベントは、ターゲットにデッドレターキューを設定している場合、`FailedInvocations` メトリクスと `InvocationsSentToDlq` メトリクスで報告されます。アプリケーションに多数の `FailedInvocations` または `InvocationsSentToDlq` レポートが発生している場合は、ターゲットが適切にスケーリングされ、特定のトラフィックを受信できるかどうかを調査することをお勧めします。

## イベント配信の遅延の検出
<a name="eb-monitoring-events-best-practices-delivery-latency"></a>

EventBridge には、イベント取り込みからターゲットへの正常な配信までにかかるエンドツーエンドのレイテンシーを観察できるメトリクスも用意されています。これは、`IngestionToInvocationSuccessLatency` メトリクスで実現できます。このメトリクスは、ターゲットからのタイムアウトや応答の遅延など、再試行や遅延配信の影響を示します。`IngestionToInvocationSuccessLatency` には、ターゲットがイベント配信に正常に応答するまでにかかる時間が含まれます。これにより、EventBridge とターゲット間のエンドツーエンドのレイテンシーをモニタリングし、ターゲットのスロットリングやエラーがない場合でも、ターゲットのパフォーマンスの変動や低下を検出できます。