Amazon Web Services ブログ

新しい Amazon EventBridge のログ記録を使用して、イベントドリブンのアプリケーションをモニタリングおよびデバッグする

7 月 15 日より、Amazon EventBridge の拡張ログ記録機能を使用して、包括的なログでイベントドリブンのアプリケーションをモニタリングおよびデバッグできます。これらの新しい機能強化は、イベントフローのモニタリングとトラブルシューティングの方法を改善するのに役立ちます。

Amazon EventBridge コンソールでこの新しい機能を見つける方法は次のとおりです:

新しいオブザーバビリティ機能は、包括的なイベントライフサイクル追跡を提供することで、マイクロサービスとイベントドリブンのアーキテクチャのモニタリングの課題に対処します。EventBridge は、ルールに一致したイベントが発行されたり、サブスクライバーに配信されたり、失敗して再試行されたりするたびに、詳細なログエントリを生成するようになりました。

成功、失敗、ステータスコードに関する詳細情報により、イベントの進行状況全体を可視化できるため、問題の特定と診断が容易になります。以前は何時間もかかっていた試行錯誤によるデバッグが、詳細なイベントライフサイクル追跡と組み込みのクエリツールにより、数分で完了するようになりました。

Amazon EventBridge の拡張オブザーバビリティの使用
Amazon EventBridge のログ記録機能をご紹介するデモをご覧ください。

既存のイベントバス、または新しいカスタムイベントバスを作成する際に、ログ記録を有効にすることができます。まず、EventBridge コンソールに移動し、左側のナビゲーションペインで [イベントバス] を選択します。[カスタムイベントバス] で、[イベントバスを作成] を選択します。

この新しい機能は、[ログ] セクションに表示されます。[ログの保存先] を設定するには、Amazon CloudWatch Logs、Amazon Data Firehose ストリーム、Amazon Simple Storage Service (Amazon S3) の 3 つのオプションがあります。ログをデータレイクにストリーミングする場合は、Amazon Kinesis Data Firehose ストリームを選択します。イベントバスにカスタマーマネージドキー (CMK) が指定されている場合、ログは転送中に TLS で、および保管中に暗号化されます。CloudWatch Logs はカスタマーマネージドキーをサポートし、Data Firehose はダウンストリームの宛先のためにサーバー側の暗号化を提供します。

このデモでは、[CloudWatch ログ] と [S3 ログ] を選択します。

また、[ログレベル] を [エラー]、[情報]、[トレース] から選択することもできます。ペイロードを確認する必要があるため、[トレース] を選択し、[実行データを含める] を選択します。ペイロードデータのログ記録には機密情報が含まれる場合があり、この設定は選択したすべてのログの保存先に適用されるため、注意が必要です。その後、[CloudWatch ロググループ] と [S3 ログ] のそれぞれに 1 つずつ、合計で 2 つの保存先を設定します。そして、[作成] を選択します。

ログ記録が有効になったら、テストイベントの発行を開始して、ログ記録の動作を観察できます。

最初のシナリオでは、AWS Lambda 関数を構築し、この Lambda 関数をターゲットとして設定しました。

[イベントを送信] を選択して、イベントバスに移動し、サンプルイベントを送信します。

使用するペイロードを次に示します:

{
  "Source": "ecommerce.orders",
  "DetailType": "Order Placed",
  "Detail": {
    "orderId": "12345",
    "customerId": "cust-789",
    "amount": 99.99,
    "items": [
      {
        "productId": "prod-456",
        "quantity": 2,
        "price": 49.99
      }
    ]
  }
}

サンプルイベントを送信すると、S3 バケットでログが使用可能になっていることがわかります。

また、Amazon CloudWatch ログにログエントリが表示されているのがわかります。ログには、EVENT_RECEIPT から SUCCESS までのイベントライフサイクルが表示されます。イベントのライフサイクル全体の詳細については、TBD:DOC_PAGE をご覧ください。

それでは、これらのログを評価してみましょう。簡潔にするために、いくつかのログのみを含めることとし、読みやすくするために編集しています。イベントをトリガーした際のログを次に示します:

{
    "resource_arn": "arn:aws:events:us-east-1:123:event-bus/demo-logging",
    "message_timestamp_ms": 1751608776896,
    "event_bus_name": "demo-logging",
// REDACTED FOR BREVITY //
    "message_type": "EVENT_RECEIPT",
    "log_level": "TRACE",
    "details": {
        "caller_account_id": "123",
        "source_time_ms": 1751608775000,
        "source": "ecommerce.orders",
        "detail_type": "Order Placed",
        "resources": [],
        "event_detail": "REDACTED FOR BREVITY"
    }
}

イベントが正常に呼び出された際のログを次に示します:

{
    "resource_arn": "arn:aws:events:us-east-1:123:event-bus/demo-logging",
    "message_timestamp_ms": 1751608777091,
    "event_bus_name": "demo-logging",
// REDACTED FOR BREVITY //
    "message_type": "INVOCATION_SUCCESS",
    "log_level": "INFO",
    "details": {
// REDACTED FOR BREVITY //
        "total_attempts": 1,
        "final_invocation_status": "SUCCESS",
        "ingestion_to_start_latency_ms": 105,
        "ingestion_to_complete_latency_ms": 183,
        "ingestion_to_success_latency_ms": 183,
        "target_duration_ms": 53,
        "target_response_body": "<REDACTED FOR BREVITY>",
        "http_status_code": 202
    }
}

追加のログエントリには、トラブルシューティングを容易にするリッチなメタデータが含まれています。例えば、イベントが成功した場合、イベントの開始から完了までのレイテンシータイミング、ターゲットが処理を完了するまでの期間、HTTP ステータスコードを確認できます。

完全なイベントライフサイクル追跡による失敗のデバッグ
EventBridge のログ記録の利点は、問題が発生したときに明らかになります。失敗のシナリオをテストするために、Lambda 関数の許可を意図的に誤って設定し、適切な許可のない別の Lambda 関数をポイントするようにルールを変更します。

許可が不足しているため、試行は永続的な失敗で終わりました。ログには、FIRST 試行が NO_PERMISSIONS ステータスで終わったことが示されています。

{
    "message_type": "INVOCATION_ATTEMPT_PERMANENT_FAILURE",
    "log_level": "ERROR",
    "details": {
        "rule_arn": "arn:aws:events:us-east-1:123:rule/demo-logging/demo-order-placed",
        "role_arn": "arn:aws:iam::123:role/service-role/Amazon_EventBridge_Invoke_Lambda_123",
        "target_arn": "arn:aws:lambda:us-east-1:123:function:demo-evb-fail",
        "attempt_type": "FIRST",
        "attempt_count": 1,
        "invocation_status": "NO_PERMISSIONS",
        "target_duration_ms": 25,
        "target_response_body": "{\"requestId\":\"a4bdfdc9-4806-4f3e-9961-31559cb2db62\",\"errorCode\":\"AccessDeniedException\",\"errorType\":\"Client\",\"errorMessage\":\"User: arn:aws:sts::123:assumed-role/Amazon_EventBridge_Invoke_Lambda_123/db4bff0a7e8539c4b12579ae111a3b0b is not authorized to perform: lambda:InvokeFunction on resource: arn:aws:lambda:us-east-1:123:function:demo-evb-fail because no identity-based policy allows the lambda:InvokeFunction action\",\"statusCode\":403}",
        "http_status_code": 403
    }
}

最後のログエントリには、タイミングメトリクスと正確なエラーメッセージとともに、完全な失敗の概要が示されています。

{
    "message_type": "INVOCATION_FAILURE",
    "log_level": "ERROR",
    "details": {
        "rule_arn": "arn:aws:events:us-east-1:123:rule/demo-logging/demo-order-placed",
        "role_arn": "arn:aws:iam::123:role/service-role/Amazon_EventBridge_Invoke_Lambda_123",
        "target_arn": "arn:aws:lambda:us-east-1:123:function:demo-evb-fail",
        "total_attempts": 1,
        "final_invocation_status": "NO_PERMISSIONS",
        "ingestion_to_start_latency_ms": 62,
        "ingestion_to_complete_latency_ms": 114,
        "target_duration_ms": 25,
        "http_status_code": 403
    },
    "error": {
        "http_status_code": 403,
        "error_message": "User: arn:aws:sts::123:assumed-role/Amazon_EventBridge_Invoke_Lambda_123/db4bff0a7e8539c4b12579ae111a3b0b is not authorized to perform: lambda:InvokeFunction on resource: arn:aws:lambda:us-east-1:123:function:demo-evb-fail because no identity-based policy allows the lambda:InvokeFunction action",
        "aws_service": "AWSLambda",
        "request_id": "a4bdfdc9-4806-4f3e-9961-31559cb2db62"
    }
}

ログは、ボトルネックを特定するのに役立つ詳細なパフォーマンスメトリクスを提供します。ingestion_to_start_latency_ms: 62 はイベントの取り込みから呼び出しを開始するまでの時間を示し、ingestion_to_complete_latency_ms: 114 は取り込みから完了までの合計時間を表します。さらに、target_duration_ms: 25 は、ターゲットサービスの応答にかかった時間を示しており、EventBridge の処理時間とターゲットサービスのパフォーマンスを区別するのに役立ちます。

エラーメッセージには、失敗したアクション (lambda:InvokeFunction アクション)、失敗した理由 (ID ベースのポリシーでアクションが許可されていない)、関係するロール (Amazon_EventBridge_Invoke_Lambda_1428392416)、影響を受けた特定のリソース (Lambda 関数の Amazon リソースネーム (ARN) で示されます) が明確に記載されています。

EventBridge のログ記録機能を使用した API の宛先のデバッグ
EventBridge のログ記録機能が特に役立つと思われるユースケースの 1 つは、API の宛先に関する問題のデバッグです。EventBridge API の宛先は、イベントバスルールまたはパイプのターゲットとして呼び出すことができる HTTPS エンドポイントです。HTTPS エンドポイントは、HTTPS 呼び出しを使用して、イベントバスから、外部システム、Software as a Service (SaaS) アプリケーション、またはサードパーティー API にイベントをルーティングするのに役立ちます。これらは接続を使用して認証と認証情報を処理します。これにより、イベントドリブンのアーキテクチャを HTTPS ベースのサービスと簡単に統合できます。

API の宛先は、外部の HTTPS エンドポイントにイベントを送信するためによく使用されますが、外部エンドポイントからのエラーのデバッグの失敗は課題となる場合があります。これらの問題は通常、エンドポイントの認証要件の変更や、変更された認証情報に起因します。

このデバッグ機能のデモを行うため、意図的に、接続リソースで誤った認証情報を使用して API の宛先を設定しました。

この誤って設定されたエンドポイントにイベントを送信すると、拡張ログ記録でこの失敗の根本原因が示されます。

{
    "resource_arn": "arn:aws:events:us-east-1:123:event-bus/demo-logging",
    "message_timestamp_ms": 1750344097251,
    "event_bus_name": "demo-logging",
    //REDACTED FOR BREVITY//,
    "message_type": "INVOCATION_FAILURE",
    "log_level": "ERROR",
    "details": {
        //REDACTED FOR BREVITY//,
        "total_attempts": 1,
        "final_invocation_status": "SDK_CLIENT_ERROR",
        "ingestion_to_start_latency_ms": 135,
        "ingestion_to_complete_latency_ms": 549,
        "target_duration_ms": 327,
        "target_response_body": "",
        "http_status_code": 400
    },
    "error": {
        "http_status_code": 400,
        "error_message": "Unable to invoke ApiDestination endpoint: The request failed because the credentials included for the connection are not authorized for the API destination."
    }
}

ログによって失敗の概要がすぐにわかります。target_arn はこれが API の宛先に関係していることを示し、final_invocation_status は SDK_CLIENT_ERROR を示していて、http_status_code は 400 です。これは、クライアント側の問題を示しています。最も重要なのは、error_message が次のように明示的に示しているということです: ApiDestination エンドポイントを呼び出すことができません: 接続のために含まれた認証情報が API の宛先について認可されていないため、リクエストは失敗しました。

この完全なログシーケンスは、デバッグに関する役立つインサイトを提供してくれます。なぜなら、イベントの受信から、取り込み、ルールのマッチング、呼び出しの試行まで、EventBridge を通じてイベントがどのように移動したのかを正確に把握できるからです。この詳細度により、推測作業が排除され、問題の根本原因を直接特定できます。

知っておくべき追加情報
いくつかの留意点を次に示します:

  • アーキテクチャサポート – ログ記録は、カスタムイベントバス、パートナーイベントソース、HTTPS エンドポイントの API の宛先など、すべての EventBridge 機能で機能します。
  • パフォーマンスへの影響 – ログ記録は非同期で実行されるため、イベント処理のレイテンシーやスループットに測定可能な影響はありません。
  • 料金 – ログの保存と配信には、Amazon S3、Amazon CloudWatch Logs、または Amazon Data Firehose の標準料金がかかります。EventBridge のログ記録自体には追加料金はかかりません。詳細については、Amazon EventBridge の料金ページにアクセスしてください。
  • 可用性 – Amazon EventBridge のログ記録機能は、EventBridge がサポートされているすべての AWS リージョンでご利用いただけます。
  • ドキュメント – 詳細については、Amazon EventBridge のモニタリングとデバッグに関するドキュメントをご覧ください。

Amazon EventBridge のログ記録機能の使用を開始するには、EventBridge コンソールにアクセスし、イベントバスでのログ記録を有効にしてください。

構築がうまくいきますように!
– Donnie

原文はこちらです。