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

# CloudWatch Logs を使用したナレッジベースのモニタリング
<a name="knowledge-bases-logging"></a>

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

## コンソールを使用したナレッジベースのログ記録
<a name="knowledge-bases-logging-console"></a>

 AWS マネジメントコンソールを使用して Amazon Bedrock ナレッジベースのログ記録を有効にするには:

1. **ナレッジベースを作成する**: AWS マネジメントコンソール for Amazon Bedrock を使用して[新しいナレッジベースを作成します](https://docs.aws.amazon.com/bedrock/latest/userguide/knowledge-base-create.html)。

1. **ログ配信オプションを追加する: **ナレッジベースを作成したら、ナレッジベースを編集または更新してログ配信オプションを追加します。
**注記**  
構造化データストアを使用してナレッジベースを作成する場合、または Kendra GenAI Index の場合は、ログ配信はサポートされません。

   **ログ配信の詳細を設定する**: ログ配信の詳細を入力します。
   + ログ記録先 (CloudWatch Logs、Amazon S3、Amazon Data Firehose のいずれか)
   + (CloudWatch Logs をログ記録先として使用する場合) ロググループ名
   + (Amazon S3 をログ記録先として使用する場合) バケット名
   + (Amazon Data Firehose をログ記録先として使用する場合) Firehose ストリーム

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

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

------
#### [ JSON ]

****  

   ```
   {
       "Version":"2012-10-17",		 	 	 
       "Statement": [
           {
               "Effect": "Allow",
               "Action": "logs:CreateDelivery",
               "Resource": [
                   "arn:aws:logs:us-east-1:123456789012:delivery-source:*",
                   "arn:aws:logs:us-east-1:123456789012:delivery:*",
                   "arn:aws:logs:us-east-1:123456789012:delivery-destination:*"
               ]
           }
       ]
   }
   ```

------

1. **配信ステータスの確認**: コンソールでログ配信ステータスが「配信が有効」であることを確認します。

## CloudWatch API を使用したナレッジベースのログ記録
<a name="knowledge-bases-logging-cloudwatch-api"></a>

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

1. **ナレッジベースの ARN を取得する**: Amazon Bedrock API または Amazon Bedrock コンソールを使用して[ナレッジベースを作成](https://docs.aws.amazon.com/bedrock/latest/userguide/knowledge-base-create.html)したら、ナレッジベースの Amazon リソースネームを取得します。Amazon リソースネームを取得するには、[GetKnowledgeBase](https://docs.aws.amazon.com/bedrock/latest/APIReference/API_agent_GetKnowledgeBase.html) API を呼び出します。ナレッジベースの Amazon リソースネームは、次の形式に従います: *arn:aws:bedrock:your-region:your-account-id:knowledge-base/knowledge-base-id*

1. **`PutDeliverySource` を呼び出す**: Amazon CloudWatch が提供する [PutDeliverySource](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_PutDeliverySource.html) 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"
   }
   ```

1. **`PutDeliveryDestination` を呼び出す**: Amazon CloudWatch が提供する [PutDeliveryDestination](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_PutDeliveryDestination.html) 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 ポリシーは、あるアカウントから別のアカウントへの配信を許可します。

1. **`CreateDelivery` を呼び出す:** [CreateDelivery](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_CreateDelivery.html) API コールを使用して、配信ソースを、前のステップで作成した送信先にリンクします。この API オペレーションは、配信ソースを最終配信先と関連付けます。

   ```
   {
      "deliveryDestinationArn": "string",
      "deliverySourceName": "string",
      "tags": { 
         "string" : "string" 
      }
   }
   ```

**注記**  
を使用する場合は CloudFormation、以下を使用できます。  
[Delivery](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-logs-delivery.html)
[DeliveryDestination](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-logs-deliverydestination.html)
[DeliverySource](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-logs-deliverysource.html)
`ResourceArn` は `KnowledgeBaseARN` であり、`APPLICATION_LOGS` はサポートされているログタイプとして `LogType` にする必要があります。

## サポートされているログのタイプ
<a name="knowledge-bases-logging-log-types"></a>

Amazon Bedrock ナレッジベースでは、次のログタイプがサポートされています。
+ `APPLICATION_LOGS`: データインジェストジョブ中に特定のファイルの現在のステータスを追跡するログ。

## ユーザーアクセス許可と制限
<a name="knowledge-bases-logging-permissions-other-requirements"></a>

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

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

   特定のログ記録先に必要なすべてのアクセス許可を持つ IAM ロール/アクセス許可ポリシーの例を表示できます。「[Vended logs permissions for different delivery destinations](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AWS-logs-and-resource-policy.html#AWS-vended-logs-permissions-V2)」を参照し、特定のログ記録先リソース (CloudWatch Logs、Amazon S3、Amazon Data Firehose のいずれでも) の更新を許可するなど、ログ記録先の IAM ロール/アクセス許可ポリシーの例に従います。

[CloudWatch Logs のサービスクォータドキュメント](https://docs.aws.amazon.com/general/latest/gr/cwl_region.html)で、CloudWatch Logs の配信関連の API コールを行うためのクォータ制限があるかどうかを確認することもできます。クォータ制限は、API を呼び出したり、リソースを作成したりできる最大回数を設定します。制限を超えると、`ServiceQuotaExceededException` エラーが発生します。

## ナレッジベースログの例
<a name="knowledge-bases-logging-example-logs"></a>

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` プロパティ内の処理の概要を含むログが公開されます。

## ナレッジベースログをデバッグするための一般的なクエリの例
<a name="knowledge-bases-logging-example-queries"></a>

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