翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
Amazon CloudWatch Logs を使用したワークフローのモニタリングとログ記録
AWS Entity Resolutionは、マッチングワークフローと ID マッピングワークフローのチェックと分析に役立つ包括的なログ記録機能を提供します。Amazon CloudWatch Logs との統合により、イベントタイプ、タイムスタンプ、処理統計、エラー数など、ワークフロー実行に関する詳細情報をキャプチャできます。これらのログを CloudWatch Logs、Amazon S3、または Amazon Data Firehose の送信先に配信することを選択できます。これらのログを分析することで、サービスのパフォーマンスの評価、問題のトラブルシューティング、顧客ベースのインサイトの取得、使用状況と請求の理解を深めるAWS Entity Resolutionことができます。ログ記録はデフォルトで無効になっていますが、コンソールまたは API を使用して、新規および既存のワークフローの両方で有効にできます。
標準の Amazon CloudWatch 販売料金は、ログの取り込み、ストレージ、分析に関連するコストなど、AWS Entity Resolutionワークフローのログ記録を有効にする場合に適用されます。料金の詳細については、CloudWatch の料金ページを参照してください。
ログ配信の設定
このセクションでは、AWS Entity Resolutionログ記録を使用するために必要なアクセス許可と、コンソールと APIs を使用してログ配信を有効にする方法について説明します。
権限
AWS Entity Resolutionは CloudWatch 提供のログを使用してワークフローログを配信します。ワークフローログを配信するには、指定したログ記録先へのアクセス許可が必要です。
各ログ記録先に必要なアクセス許可を確認するには、Amazon CloudWatch Logs ユーザーガイド」の次のAWSサービスから選択します。
でログ記録設定を作成、表示、または変更するにはAWS Entity Resolution、必要なアクセス許可が必要です。IAM ロールには、AWS Entity Resolutionコンソールでワークフローログを管理するための以下の最小限のアクセス許可が含まれている必要があります。
ワークフローログを管理するアクセス許可の詳細については、Amazon CloudWatch Logs ユーザーガイド」のAWS「サービスからのログ記録を有効にする」を参照してください。
新しいワークフローのログ記録の有効化 (コンソール)
ログ記録先へのアクセス許可を設定したら、 コンソールAWS Entity Resolutionを使用して で新しいワークフローのログ記録を有効にできます。
新しいワークフローのログ記録を有効にするには (コンソール)
-
https://console.aws.amazon.com/entityresolution/home
でAWS Entity Resolutionコンソールを開きます。 -
ワークフローで、一致するワークフローまたは ID マッピングワークフローを選択します。
-
ステップに従って、次のいずれかのワークフローを作成します。
-
ステップ 1 一致ワークフローの詳細を指定するには、ログ配信 – EntityResolution ワークフローログで、追加を選択します。
-
次のいずれかのログ記録先を選択します。
-
Amazon CloudWatch Logs へ
-
Amazon S3 へ
-
Amazon Data Firehose へ
ヒント
Amazon S3 または Firehose を選択した場合、クロスアカウントまたは現在のアカウントにログを配信できます。
クロスアカウント配信を有効にするには、両方に必要なアクセス許可AWS アカウントが必要です。詳細については、Amazon CloudWatch Logs ユーザーガイド」の「クロスアカウント配信の例」を参照してください。
-
-
-
送信先ロググループの場合、プレフィックスが '/aws/vendedlogs/' のロググループが自動的に作成されます。他のロググループを使用している場合は、ログ配信を設定する前にロググループを使用します。詳細については、「Amazon CloudWatch Logs ユーザーガイド」の「ロググループとログストリームの操作」を参照してください。
-
その他の設定 - オプションで、以下を選択します。
-
フィールド選択で、各ログレコードに含めるログフィールドを選択します。
-
(CloudWatch Logs) 出力形式で、ログの出力形式を選択します。
-
フィールド区切り記号で、各ログフィールドを区切る方法を選択します。
-
(Amazon S3) Suffix には、データをパーティション化するためのサフィックスパスを指定します。
-
(Amazon S3) Hive 互換の場合は、Hive 互換 S3 パスを使用する場合は Enable を選択します。
-
-
別のログ送信先を作成するには、「追加」を選択し、ステップ 4~6 を繰り返します。
-
ワークフローを設定して実行する残りのステップを完了します。
-
ワークフロージョブが完了したら、指定したログ配信先のワークフローログを確認します。
新しいワークフローのログ記録の有効化 (API)
ログ記録先へのアクセス許可を設定したら、Amazon CloudWatch Logs APIs AWS Entity Resolutionを使用して で新しいワークフローのログ記録を有効にできます。
新しいワークフローのログ記録を有効にするには (API)
-
AWS Entity Resolutionコンソールでワークフローを作成したら、ワークフローの Amazon リソースネーム (ARN) を取得します。
AWS Entity Resolutionコンソールのワークフローページから ARN を見つけるか、
GetMatchingWorkflowまたはGetIdMappingWorkflowAPI オペレーションを呼び出します。ワークフロー ARN は次の形式に従います。
arn:(aws|aws-us-gov|aws-cn):entityresolution:[a-z]{2}-[a-z]{1,10}-[0-9]:[0-9]{12}:(matchingworkflow/[a-zA-Z_0-9-]{1,255})ID マッピング ARN は次の形式に従います。
arn:(aws|aws-us-gov|aws-cn):entityresolution:[a-z]{2}-[a-z]{1,10}-[0-9]:[0-9]{12}:(idmappingworkflow/[a-zA-Z_0-9-]{1,255})詳細については、 AWS Entity Resolution API リファレンスのGetMatchingWorkflow」またはGetIdMappingWorkflow」を参照してください。
-
CloudWatch Logs
PutDeliverySourceAPI オペレーションを使用して、ワークフローログの配信ソースを作成します。詳細については、Amazon CloudWatch Logs API リファレンス」の「PutDeliverySource」を参照してください。
-
を渡します
resourceArn。 -
の場合
logType、収集されるログのタイプは ですWORKFLOW_LOGS。
例
PutDeliverySourceAPI オペレーションの例{ "logType": "WORKFLOW_LOGS", "name": "my-delivery-source", "resourceArn": "arn:aws:entityresolution:region:accoungId:matchingworkflow/XXXWorkflow" } -
-
PutDeliveryDestinationAPI オペレーションを使用して、ログの保存先を設定します。CloudWatch Logs、Amazon S3、または Firehose のいずれかを送信先として選択できます。ログの保存先オプションのいずれかの ARN を指定する必要があります。
詳細については、Amazon CloudWatch Logs API リファレンス」のPutDeliveryDestination」を参照してください。
例
PutDeliveryDestinationAPI オペレーションの例{ "delivery-destination-configuration": { "destinationResourceArn": "arn:aws:logs:region:accountId:log-group:my-log-group" }, "name": "my-delivery-destination", "outputFormat": "json", } }注記
ログをクロスアカウントで配信する場合は、PutDeliveryDestinationPolicy API を使用して、送信先アカウントに (IAM) ポリシーを割り当てるAWS Identity and Access Management必要があります。IAM ポリシーは、あるアカウントから別のアカウントへの配信を許可します。
-
CreateDeliveryAPI オペレーションを使用して、配信ソースを前のステップで作成した送信先にリンクします。この API オペレーションは、配信ソースを最終配信先と関連付けます。詳細については、Amazon CloudWatch Logs API リファレンス」の「PutDeliveryDestination」を参照してください。
例
CreateDeliveryAPI オペレーションの例{ "delivery-destination-arn": "arn:aws:logs:region:accountId:log-group:my-log-group", "delivery-source-name": "my-delivery-source", "tags": { "string" : "string" } } -
ワークフローを実行します。
-
ワークフロージョブが完了したら、指定したログ配信先のワークフローログを確認します。
既存のワークフローのログ記録の有効化 (コンソール)
ログ記録先へのアクセス許可を設定したら、 コンソールのログ配信タブAWS Entity Resolutionを使用して、 で既存のワークフローのログ記録を有効にできます。
ログ配信タブを使用して既存のワークフローのログ記録を有効にするには (コンソール)
-
https://console.aws.amazon.com/entityresolution/home
でAWS Entity Resolutionコンソールを開きます。 -
ワークフローで、一致するワークフローまたは ID マッピングワークフローを選択し、既存のワークフローを選択します。
-
「ログ配信」タブの「ログ配信」で、「追加」を選択し、次のいずれかのログ記録先を選択します。
-
Amazon CloudWatch Logs へ
-
Amazon S3 へ
-
クロスアカウント
-
現行のアカウント
-
-
Amazon Data Firehose へ
-
クロスアカウント
-
現行のアカウント
-
ヒント
Amazon S3 または Firehose を選択した場合は、クロスアカウントまたは現在のアカウントにログを配信できます。
クロスアカウント配信を有効にするには、両方に必要なアクセス許可AWS アカウントが必要です。詳細については、Amazon CloudWatch Logs ユーザーガイド」の「クロスアカウント配信の例」を参照してください。
-
-
モーダルで、選択したログ配信のタイプに応じて、次の操作を行います。
-
ログタイプを表示する: WORKFLOW_LOGS。
ログタイプは変更できません。
-
(CloudWatch Logs) 送信先ロググループの場合、'/aws/vendedlogs/' というプレフィックスが付いたロググループが自動的に作成されます。他のロググループを使用している場合は、ログ配信を設定する前にロググループを使用します。詳細については、「Amazon CloudWatch Logs ユーザーガイド」の「ロググループとログストリームの操作」を参照してください。
(現在のアカウントの Amazon S3) 送信先 S3 バケットの場合は、バケットを選択するか、ARN を入力します。
(Amazon S3 クロスアカウント) 配信先 ARN に配信先 ARN を入力します。
(現在のアカウントのファイアウォール) 送信先配信ストリームには、別のアカウントで作成された配信先リソースの ARN を入力します。
(Firehose クロスアカウント) 配信先 ARN に配信先 ARN を入力します。
-
-
その他の設定 - オプションで、以下を選択します。
-
フィールド選択で、各ログレコードに含めるログフィールドを選択します。
-
(CloudWatch Logs) 出力形式で、ログの出力形式を選択します。
-
フィールド区切り記号で、各ログフィールドを区切る方法を選択します。
-
(Amazon S3) Suffix には、データをパーティション化するためのサフィックスパスを指定します。
-
(Amazon S3) Hive 互換の場合は、Hive 互換 S3 パスを使用する場合は Enable を選択します。
-
-
[Add] (追加) を選択します。
-
ワークフローページで、実行 を選択します。
-
ワークフロージョブが完了したら、指定したログ配信先のワークフローログを確認します。
ログ記録の無効化 (コンソール)
ワークフローのログ記録は、 コンソールでAWS Entity Resolutionいつでも無効にできます。
ワークフローログ記録を無効にするには (コンソール)
-
https://console.aws.amazon.com/entityresolution/home
でAWS Entity Resolutionコンソールを開きます。 -
ワークフローで、一致するワークフローまたは ID マッピングワークフローを選択し、ワークフローを選択します。
-
「ログ配信」タブの「ログ配信」で、送信先を選択し、「削除」を選択します。
-
変更を確認し、次のステップに移動して変更を保存します。
ログの読み取り
Amazon CloudWatch Logs を読み取ると、効率的なAWS Entity Resolutionワークフローを維持できます。ログは、処理されたレコードの数や発生したエラーなどの重要なメトリクスなど、ワークフローの実行を詳細に可視化するため、データ処理がスムーズに実行されていることを確認できます。さらに、ログはタイムスタンプやイベントタイプを通じてワークフローの進行状況をリアルタイムで追跡できるため、データ処理パイプラインのボトルネックや問題をすばやく特定できます。包括的なエラー追跡とレコード数情報は、正常に処理されたレコードの数と、未処理のレコードがあるかどうかを正確に示すことで、データの品質と完全性を維持するのに役立ちます。
CloudWatch Logs を送信先として使用している場合は、CloudWatch Logs Insights を使用してワークフローログを読み取ることができます。CloudWatch Logs の一般料金が適用されます。詳細については、「Amazon CloudWatch Logs ユーザーガイド」の「CloudWatch Logs Insights でログデータを分析する」を参照してください。
注記
ワークフローログが送信先に表示されるまでに数分かかる場合があります。ログが表示されない場合は、数分待ってからページを更新します。
ワークフローログは、フォーマットされた一連のログレコードで構成され、各ログレコードは 1 つのワークフローを表します。ログ内のフィールドの順序は変わることがあります。
{ "resource_arn": "arn:aws:ses:us-east-1:1234567890:mailmanager-ingress-point/inp-xxxxx", "event_type": "JOB_START", "event_timestamp": 1728562395042, "job_id": "b01eea4678d4423a4b43eeada003f6", "workflow_name": "TestWorkflow", "workflow_start_time": "2025-03-11 10:19:56", "data_procesing_progression": "Matching Job Starts ...", "total_records_processed": 1500, "total_records_unprocessed": 0, "incremental_records_processed": 0, "error_message": "sample error that caused workflow failure" }
次のリストで、ログレコードのフィールドを順番に従い説明します。
resource_arn-
ワークフローで使用されているリソースを一意に識別する Amazon AWSリソースネーム (ARN)。
event_type-
ワークフローの実行中に発生したイベントのタイプ。AWS Entity Resolution現在、 は以下をサポートしています。
JOB_STARTDATA_PROCESSING_STEP_STARTDATA_PROCESSING_STEP_ENDJOB_SUCCESSJOB_FAILURE event_timestamp-
ワークフロー中にイベントが発生した時刻を示す Unix タイムスタンプ。
job_id-
特定のワークフロージョブ実行に割り当てられた一意の識別子。
workflow_name-
実行中のワークフローに付けられた名前。
workflow_start_time-
ワークフロー実行が開始された日時。
data_procesing_progression-
データ処理ワークフローの現在のステージの説明。例:
"Matching Job Starts"、"Loading Step Starts"、"ID_Mapping Job Ends Successfully"。 total_records_processed-
ワークフロー中に正常に処理されたレコードの合計数。
total_records_unprocessed-
ワークフローの実行中に処理されなかったレコードの数。
incremental_records_processed-
増分ワークフロー更新で処理された新しいレコードの数。
error_message-
ワークフロー障害の根本原因。