翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
CloudWatch Logs を使用したナレッジベースのモニタリング
Amazon Bedrock は、ナレッジベースのデータインジェストジョブの実行を理解するのに役立つモニタリングシステムをサポートしています。以下のセクションでは、 と CloudWatch API の両方を使用して Amazon Bedrock ナレッジベースのログ記録システムを有効に AWS Management Console して設定する方法について説明します。このログ記録システムでは、ナレッジベースリソースのデータインジェストを可視化できます。
コンソールを使用したナレッジベースのログ記録
AWS Management Consoleを使用して Amazon Bedrock ナレッジベースのログ記録を有効にするには:
-
ナレッジベースを作成する: Amazon Bedrock AWS Management Console の を使用して新しいナレッジベースを作成します。
-
ログ配信オプションを追加する: ナレッジベースを作成したら、ナレッジベースを編集または更新してログ配信オプションを追加します。
ログ配信の詳細を設定する: ログ配信の詳細を入力します。
-
ログ記録先 (CloudWatch Logs、Amazon S3、Amazon Data Firehose のいずれか)
-
(CloudWatch Logs をログ記録先として使用する場合) ロググループ名
-
(Amazon S3 をログ記録先として使用する場合) バケット名
-
(Amazon Data Firehose をログ記録先として使用する場合) Firehose ストリーム
-
-
アクセス許可を含める: コンソールにサインインするユーザーは、収集されたログを選択した送信先に書き込むために必要なアクセス許可を持っている必要があります。
次の IAM ポリシーの例は、CloudWatch Logs を使用する際に必要なアクセス許可を付与するため、コンソールにサインインしたユーザーにアタッチできます。
{ "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:*" ] }] }
-
配信ステータスの確認: コンソールでログ配信ステータスが「配信が有効」であることを確認します。
CloudWatch API を使用したナレッジベースのログ記録
CloudWatch API を使用して Amazon Bedrock ナレッジベースのログ記録を有効にするには:
-
ナレッジベースの ARN を取得する: Amazon Bedrock API または Amazon Bedrock コンソールを使用してナレッジベースを作成したら、ナレッジベースの Amazon リソースネームを取得します。Amazon リソースネームを取得するには、GetKnowledgeBase API を呼び出します。ナレッジベースの Amazon リソースネームは、次の形式に従います:
arn:aws:bedrock:your-region:your-account-id:knowledge-base/knowledge-base-id
-
PutDeliverySource
を呼び出す: Amazon CloudWatch が提供する PutDeliverySource API を使用して、ナレッジベースの配信ソースを作成します。ナレッジベースの Amazon リソースネームをresourceArn
として渡します。logType
は、収集されるログのタイプとしてAPPLICATION_LOGS
を指定します。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" }
-
PutDeliveryDestination
を呼び出す: Amazon CloudWatch が提供する PutDeliveryDestination API を使用して、ログの保存先を設定します。ログの保存先として、CloudWatch Logs、Amazon S3、または Amazon Data Firehose のいずれかを選択できます。ログの保存先として、保存先オプションの 1 つの Amazon リソースネームを指定する必要があります。ログのoutputFormat
は以下のいずれかを選択できます:json
、plain
、w3c
、raw
、parquet
。以下は、Amazon S3 バケットおよび JSON 形式で保存されるログを設定する例です。{ "deliveryDestinationConfiguration": { "destinationResourceArn": "arn:aws:s3:::bucket-name" }, "name": "string", "outputFormat": "json", "tags": { "key" : "value" } }
クロスアカウントでログを配信する場合は、
PutDeliveryDestinationPolicy
API を使用して AWS Identity and Access Management (IAM) ポリシーを送信先アカウントに割り当てる必要があります。IAM ポリシーは、あるアカウントから別のアカウントへの配信を許可します。 -
CreateDelivery
を呼び出す: CreateDelivery API コールを使用して、配信ソースを、前のステップで作成した送信先にリンクします。この API オペレーションは、配信ソースを最終配信先と関連付けます。{ "deliveryDestinationArn": "string", "deliverySourceName": "string", "tags": { "string" : "string" } }
注記
を使用する場合は AWS CloudFormation、以下を使用できます。
ResourceArn
は KnowledgeBaseARN
であり、APPLICATION_LOGS
はサポートされているログタイプとして LogType
にする必要があります。
サポートされているログのタイプ
Amazon Bedrock ナレッジベースでは、次のログタイプがサポートされています。
-
APPLICATION_LOGS
: データインジェストジョブ中に特定のファイルの現在のステータスを追跡するログ。
ユーザーアクセス許可と制限
Amazon Bedrock ナレッジベースのログ記録を有効にするには、コンソールにサインインしたユーザーアカウントが次のアクセス許可を持っている必要があります。
-
bedrock:AllowVendedLogDeliveryForResource
– ナレッジベースリソースのログの配信を許可するのに必要です。特定のログ記録先に必要なすべてのアクセス許可を持つ IAM ロール/アクセス許可ポリシーの例を表示できます。「Vended logs permissions for different delivery destinations」を参照し、特定のログ記録先リソース (CloudWatch Logs、Amazon S3、Amazon Data Firehose のいずれでも) の更新を許可するなど、ログ記録先の IAM ロール/アクセス許可ポリシーの例に従います。
CloudWatch Logs のサービスクォータドキュメントで、CloudWatch Logs の配信関連の API コールを行うためのクォータ制限があるかどうかを確認することもできます。クォータ制限は、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_INGESTION
、SCHEDULED_FOR_DELETION
、SCHEDULED_FOR_UPDATE
、SCHEDULED_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_FAILED
、INDEXING_FAILED
、DELETION_FAILED
、およびMETADATA_UPDATE_FAILED
: これらのステータス値は、リソースの処理が失敗したことを示し、その理由はstatus_reasons
プロパティ内で詳細に説明されています。 -
INDEXED
、DELETED
、PARTIALLY_INDEXED
、METADATA_PARTIALLY_INDEXED
、FAILED
: ドキュメントの処理が確定すると、ドキュメントの最終ステータスと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"