前提条件 Amazon Bedrock ナレッジベースのログ記録の有効化 (コンソール)Amazon Bedrock ナレッジベースのログ記録の有効化 (CloudWatch API)ナレッジベースログの例ナレッジベースログをデバッグするための一般的なクエリの例

CloudWatch Logs を使用したナレッジベースのモニタリング

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

前提条件

Amazon Bedrock ナレッジベースのログ記録を有効にする前に、以下を確認してください。

コンソールにサインインしたユーザーアカウントにはアクセスbedrock:AllowVendedLogDeliveryForResource許可があります。このアクセス許可により、ナレッジベースリソースのログを配信できます。必要なすべてのアクセス許可を持つ IAM ポリシーの例については、「Vended logs permissions for different delivery destinations」を参照してください。特定のログ記録送信先リソース (CloudWatch Logs、Amazon S3、Amazon Data Firehose のいずれでも) の更新を許可するなど、ログ記録送信先の IAM ロール/アクセス許可ポリシーの例に従います。
CloudWatch Logs 配信関連の API コールにクォータ制限があるかどうかを確認します。詳細については、CloudWatch Logs サービスクォータのドキュメントを参照してください。制限を超えると、ServiceQuotaExceededExceptionエラーが発生します。

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

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

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

Amazon Bedrock ナレッジベースのログ記録の有効化 (コンソール)

コンソールを使用してログ記録を有効にするには

ナレッジベースを作成します。手順については、「ナレッジベースの作成」を参照してください。
ナレッジベースを編集して、ログ配信オプションを追加します。

注記
構造化データストアを使用してナレッジベースを作成する場合、または Kendra GenAI Index の場合は、ログ配信はサポートされません。
次のようなログ配信の詳細を設定します。
- ログ記録先 (CloudWatch Logs、Amazon S3、または Amazon Data Firehose)
- (CloudWatch Logs を使用している場合) ロググループ名
- (Amazon S3 を使用している場合) バケット名
- (Amazon Data Firehose を使用している場合) Firehose ストリーム

アカウントに IAM ポリシーをアタッチして、送信先にログを書き込むアクセス許可を付与します。

次の IAM ポリシーの例では、CloudWatch Logs を使用するときに必要なアクセス許可を付与します。

ログ配信ステータスに、コンソールで配信がアクティブと表示されていることを確認します。

Amazon Bedrock ナレッジベースのログ記録の有効化 (CloudWatch API)

CloudWatch API を使用してログ記録を有効にするには

Amazon Bedrock API または Amazon Bedrock コンソールを使用してナレッジベースを作成します。手順については、「ナレッジベースの作成」を参照してください。
ナレッジベースの ARN を取得します。GetKnowledgeBase API を呼び出して ARN を取得します。ナレッジベースの ARN は次の形式に従います。arn:aws:bedrock:your-region:your-account-id:knowledge-base/knowledge-base-id
PutDeliverySource API を呼び出して、ナレッジベースの配信ソースを作成します。ナレッジベース ARN をとして渡しますresourceArn。を 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"
}
```
PutDeliveryDestination API を呼び出して、ログの保存先を設定します。
1. 送信先として CloudWatch Logs、Amazon S3、または Amazon Data Firehose を選択します。
2. 選択した送信先の ARN を指定します。
3. を、、json、plain、w3c、のいずれかoutputFormatに設定しますrawparquet。
次の例では、ログを JSON 形式で Amazon S3 バケットに保存します。
```
{
   "deliveryDestinationConfiguration": { 
      "destinationResourceArn": "arn:aws:s3:::bucket-name"
   },
   "name": "string",
   "outputFormat": "json",
   "tags": { 
      "key" : "value" 
   }
}
```
ログをクロスアカウントで配信するには、 PutDeliveryDestinationPolicy API を使用して送信先アカウントに IAM ポリシーを割り当てます。このポリシーでは、あるアカウントから別のアカウントへの配信を許可します。
CreateDelivery API を呼び出して、配信ソースを送信先にリンクします。これにより、配信ソースが最終送信先に関連付けられます。
```
{
   "deliveryDestinationArn": "string",
   "deliverySourceName": "string",
   "tags": { 
      "string" : "string" 
   }
}
```

注記

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

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

ナレッジベースログの例

Amazon Bedrock ナレッジベースにはデータインジェストレベルのログとリソースレベルのログがあります。

以下は、データインジェストジョブログの例です。


{
    "event_timestamp": 1718683433639,
    "event": {
        "ingestion_job_id": "<IngestionJobId>",
        "data_source_id": "<IngestionJobId>",
        "ingestion_job_status": "INGESTION_JOB_STARTED" | "STOPPED" | "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 プロパティ内の処理の概要を含むログが公開されます。
CRAWLED、RESOURCE_CRAWLED、RESOURCE_FETCHED、CRAWLING_COMPLETED、CONNECTOR_CRAWLING_COMPLETED: これらのステータス値は、リソースがデータソースコネクタからクロールまたはフェッチされたことを示します。
PENDING、STARTING、IN_PROGRESS: これらのステータス値は、リソースがキューに入っているか、現在処理中であることを示します。
DELETE_IN_PROGRESS、DELETING: これらのステータス値は、リソースが削除されていることを示します。
INGESTION_JOB_STARTED、INGESTION_JOB_FAILED: これらのステータス値は、リソースの全体的な取り込みジョブの開始または失敗を示します。
GRAPH_ENTITY_EXTRACTION_STARTED、GRAPH_ENTITY_EXTRACTION_COMPLETED、GRAPH_ENTITY_EXTRACTION_FAILED: これらのステータス値は、グラフデータストアを使用するナレッジベースのグラフエンティティ抽出の進行状況を示します。

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

クエリを使用してログを操作できます。例えば、ドキュメントまたはデータの取り込み中に、イベントステータスが 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"

ブラウザで JavaScript が無効になっているか、使用できません。

AWS ドキュメントを使用するには、JavaScript を有効にする必要があります。手順については、使用するブラウザのヘルプページを参照してください。

ドキュメントの表記規則

機能をモニタリングする

ガードレールのモニタリング