CloudWatch Logs を使用してナレッジベースをモニタリングする - Amazon Bedrock

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

CloudWatch Logs を使用してナレッジベースをモニタリングする

Amazon Bedrock は、ナレッジベースのデータ取り込みジョブの実行を理解するのに役立つモニタリングシステムをサポートしています。以下のセクションでは、 の両方を使用して Amazon Bedrock ナレッジベースのログ記録システムを有効にして設定する方法について説明します。 AWS Management Console および CloudWatch API。このログ記録システムでは、ナレッジベースリソースのデータ取り込みを可視化できます。

コンソールを使用したナレッジベースのログ記録

を使用して Amazon Bedrock ナレッジベースのログ記録を有効にするには AWS Management Console:

  1. ナレッジベースを作成する: を使用する AWS Management Console Amazon Bedrock が新しいナレッジベース を作成するための

  2. ログ配信オプションを追加する: ナレッジベースを作成したら、ナレッジベースを編集または更新してログ配信オプションを追加します。

    ログ配信の詳細を設定する: ログ配信の詳細を入力します。これには、以下が含まれます。

    • ログ記録先 ( CloudWatch ログ、Amazon S3、Amazon Data Firehose のいずれか)

    • (ログ記録先として CloudWatch ログを使用する場合) ロググループ名

    • (Amazon S3 をログ記録先として使用している場合) バケット名

    • (Amazon Data Firehose をログ記録先として使用している場合) Firehose ストリーム

  3. アクセス許可を含める: コンソールにサインインしているユーザーは、収集されたログを選択した宛先に書き込むために必要なアクセス許可を持っている必要があります。

    次のIAMポリシー例は、 コンソールにサインインしたユーザーにアタッチして、 CloudWatch ログの使用時に必要なアクセス許可を付与できます。

    { "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Action": "logs:CreateDelivery", "Resource": [ "arn:aws:logs:your-region:your-account-id:delivery-source:*", "arn:aws:logs:your-region:your-account-id:delivery:*", "arn:aws:logs:your-region:your-account-id:delivery-destination:*" ] }] }
  4. 配信ステータスの確認: コンソールでログ配信ステータスが「配信アクティブ」であることを確認します。

を使用したナレッジベースのログ記録 CloudWatch API

を使用して Amazon Bedrock ナレッジベースのログ記録を有効にするには CloudWatch API:

  1. ナレッジベース ARNの を取得する: Amazon Bedrock APIまたは Amazon Bedrock コンソールを使用してナレッジベースを作成したら、ナレッジベースの Amazon リソースネームを取得します。Amazon リソースネームは、 GetKnowledgeBase を呼び出すことで取得できますAPI。ナレッジベースの Amazon リソースネームは次の形式に従います。arn:aws:bedrock:your-region:your-account-id:knowledge-base/knowledge-base-id

  2. 呼びPutDeliverySource出す: Amazon PutDeliverySourceAPIが提供する CloudWatch を使用して、ナレッジベースの配信ソースを作成します。ナレッジベースの Amazon リソースネームを として渡しますresourceArn。 は、収集されるログのタイプAPPLICATION_LOGSとして logTypeを指定します。 は、取り込みジョブ中のファイルの現在のステータスAPPLICATION_LOGSを追跡します。

    { "logType": "APPLICATION_LOGS", "name": "my-knowledge-base-delivery-source", "resourceArn": "arn:aws:bedrock:your-region:your-account-id:knowledge-base/knowledge_base_id" }
  3. 呼びPutDeliveryDestination出す: Amazon PutDeliveryDestinationAPIが提供する CloudWatch を使用して、ログの保存先を設定します。ログの保存先として、 CloudWatch ログ、Amazon S3、または Amazon Data Firehose のいずれかを選択できます。ログの保存先オプションのいずれかの Amazon リソースネームを指定する必要があります。ログoutputFormatの は、、jsonplain、、 のいずれかに選択できますw3crawparquet。以下は、ログを Amazon S3 バケットおよび JSON形式で保存するように設定する例です。

    { "deliveryDestinationConfiguration": { "destinationResourceArn": "arn:aws:s3:::bucket-name" }, "name": "string", "outputFormat": "json", "tags": { "key" : "value" } }

    クロスアカウントでログPutDeliveryDestinationPolicyAPIを配信する場合は、 を使用して を割り当てる必要があることに注意してください。 AWS Identity and Access Management (IAM) ポリシーを送信先アカウントに送信します。このIAMポリシーは、あるアカウントから別のアカウントへの配信を許可します。

  4. を呼び出すCreateDelivery: CreateDeliveryAPI呼び出しを使用して、配信元を前のステップで作成した送信先にリンクします。このAPIオペレーションは、配信元を最終送信先と関連付けます。

    { "deliveryDestinationArn": "string", "deliverySourceName": "string", "tags": { "string" : "string" } }
注記

を使用する場合 AWS CloudFormationでは、以下を使用できます。

ResourceArn は でありKnowledgeBaseARN、サポートされているログタイプAPPLICATION_LOGSとして LogTypeである必要があります。

サポートされているログタイプ

Amazon Bedrock ナレッジベースは、次のログタイプをサポートしています。

  • APPLICATION_LOGS: データインジェストジョブ中の特定のファイルの現在のステータスを追跡するログ。

ユーザーアクセス許可と制限

Amazon Bedrock ナレッジベースのログ記録を有効にするには、コンソールにサインインしたユーザーアカウントに次のアクセス許可が必要です。

  1. bedrock:AllowVendedLogDeliveryForResource – ナレッジベースリソースのログの配信を許可するために必要です。

    特定のログ記録先に必要なすべてのアクセス許可を持つIAMロール/アクセス許可ポリシーの例を表示できます。「さまざまな配信先 で提供されるログのアクセス許可」を参照し、特定のログ記録先リソース ( CloudWatch ログ、Amazon S3、Amazon Data Firehose のいずれか) の更新を許可するなど、ログ記録先 のIAMロール/アクセス許可ポリシーの例に従ってください。

Logs サービスクォータドキュメント で CloudWatch 、ログ配信関連のAPI呼び出しを行うためのクォータ制限があるかどうかを確認することもできます。 CloudWatch クォータ制限は、 を呼び出すか、リソースAPIを作成できる最大回数を設定します。制限を超えると、ServiceQuotaExceededExceptionエラーが発生します。

ナレッジベースログの例

Amazon Bedrock ナレッジベースのデータ取り込みレベルのログとリソースレベルのログがあります。

データ取り込みジョブログの例を次に示します。

{ "event_timestamp": 1718683433639, "event": { "ingestion_job_id": "<IngestionJobId>", "data_source_id": "<IngestionJobId>", "ingestion_job_status": "INGESTION_JOB_STARTED" | "COMPLETE" | "FAILED" | "CRAWLING_COMPLETED" "knowledge_base_arn": "arn:aws:bedrock:<region>:<accountId>:knowledge-base/<KnowledgeBaseId>", "resource_statistics": { "number_of_resources_updated": int, "number_of_resources_ingested": int, "number_of_resources_scheduled_for_update": int, "number_of_resources_scheduled_for_ingestion": int, "number_of_resources_scheduled_for_metadata_update": int, "number_of_resources_deleted": int, "number_of_resources_with_metadata_updated": int, "number_of_resources_failed": int, "number_of_resources_scheduled_for_deletion": int } }, "event_version": "1.0", "event_type": "StartIngestionJob.StatusChanged", "level": "INFO" }

リソースレベルのログの例を次に示します。

{ "event_timestamp": 1718677342332, "event": { "ingestion_job_id": "<IngestionJobId>", "data_source_id": "<IngestionJobId>", "knowledge_base_arn": "arn:aws:bedrock:<region>:<accountId>:knowledge-base/<KnowledgeBaseId>", "document_location": { "type": "S3", "s3_location": { "uri": "s3:/<BucketName>/<ObjectKey>" } }, "status": "<ResourceStatus>" "status_reasons": String[], "chunk_statistics": { "ignored": int, "created": int, "deleted": int, "metadata_updated": int, "failed_to_create": int, "failed_to_delete": int, "failed_to_update_metadata": int }, }, "event_version": "1.0", "event_type": "StartIngestionJob.ResourceStatusChanged", "level": "INFO" | "WARN" | "ERROR" }

リソースstatusの は、次のいずれかになります。

  • SCHEDULED_FOR_INGESTIONSCHEDULED_FOR_DELETIONSCHEDULED_FOR_UPDATESCHEDULED_FOR_METADATA_UPDATE: これらのステータス値は、ナレッジベースの現在の状態とデータソースで行われた変更の差を計算した後、リソースの処理がスケジュールされていることを示します。

  • RESOURCE_IGNORED: このステータス値は、処理のためにリソースが無視されたことを示し、その理由は status_reasonsプロパティ内で詳細に説明されています。

  • EMBEDDING_STARTED および EMBEDDING_COMPLETED: これらのステータス値は、リソースのベクトル埋め込みがいつ開始および完了したかを示します。

  • INDEXING_STARTED および INDEXING_COMPLETED: これらのステータス値は、リソースのインデックス作成がいつ開始および完了したかを示します。

  • DELETION_STARTED および DELETION_COMPLETED: これらのステータス値は、リソースの削除がいつ開始および完了したかを示します。

  • METADATA_UPDATE_STARTED および METADATA_UPDATE_COMPLETED: これらのステータス値は、リソースのメタデータ更新がいつ開始および完了したかを示します。

  • EMBEDDING_FAILEDINDEXING_FAILEDDELETION_FAILED、および METADATA_UPDATE_FAILED: これらのステータス値は、リソースの処理が失敗したことを示し、その理由は status_reasonsプロパティ内で詳しく説明されています。

  • INDEXEDDELETEDPARTIALLY_INDEXEDMETADATA_PARTIALLY_INDEXEDFAILED: ドキュメントの処理が確定すると、ドキュメントの最終ステータスとプロパティ内の処理の概要を含むログが発行されますchunk_statistics

ナレッジベースログをデバッグするための一般的なクエリの例

クエリを使用してログを操作できます。例えば、ドキュメントまたはデータの取り込みRESOURCE_IGNORED中にイベントステータスを持つすべてのドキュメントをクエリできます。

以下は、 CloudWatch Logs Insights を使用して生成されたログのデバッグに使用できる一般的なクエリです。

  • 特定の S3 ドキュメントに対して生成されたすべてのログをクエリします。

    filter event.document_location.s3_location.uri = "s3://<bucketName>/<objectKey>"

  • データインジェストジョブ中に無視されたすべてのドキュメントをクエリします。

    filter event.status = "RESOURCE_IGNORED"

  • ベクトル埋め込みドキュメント中に発生したすべての例外をクエリします。

    filter event.status = "EMBEDDING_FAILED"

  • ベクトルデータベースへのドキュメントのインデックス作成中に発生したすべての例外をクエリします。

    filter event.status = "INDEXING_FAILED"

  • ベクトルデータベースからのドキュメントの削除中に発生したすべての例外をクエリします。

    filter event.status = "DELETION_FAILED"

  • ベクトルデータベース内のドキュメントのメタデータの更新中に発生したすべての例外をクエリします。

    filter event.status = "DELETION_FAILED"

  • データインジェストジョブの実行中に発生したすべての例外をクエリします。

    filter level = "ERROR" or level = "WARN"