Journalisation des bases de connaissances à l'aide de la console Journalisation des bases de connaissances à l'aide de l' CloudWatch API Types de journaux pris en charge Autorisations et limites des utilisateurs Exemples de journaux de base de connaissances Exemples de requêtes courantes pour déboguer les journaux de la base de connaissances

Surveillez les bases de connaissances à l'aide CloudWatch des journaux

Amazon Bedrock prend en charge un système de surveillance qui vous aide à comprendre l'exécution de toutes les tâches d'ingestion de données pour vos bases de connaissances. Les sections suivantes expliquent comment activer et configurer le système de journalisation pour les bases de connaissances Amazon Bedrock à l'aide de l' CloudWatch API AWS Management Console and. Grâce à ce système de journalisation, vous pouvez obtenir une meilleure visibilité sur l'ingestion des données des ressources de votre base de connaissances.

Journalisation des bases de connaissances à l'aide de la console

Pour activer la journalisation d'une base de connaissances Amazon Bedrock à l'aide de AWS Management Console :

Création d'une base de connaissances : utilisez le AWS Management Console for Amazon Bedrock pour créer une nouvelle base de connaissances.
Ajouter une option de livraison de journaux : après avoir créé la base de connaissances, modifiez ou mettez à jour votre base de connaissances pour ajouter une option de livraison de journaux.

Configurer les détails de livraison du journal : entrez les détails de la livraison du journal, notamment :
- Destination de journalisation (soit CloudWatch Logs, Amazon S3, Amazon Data Firehose)
- (Si vous utilisez CloudWatch les journaux comme destination de journalisation) Nom du groupe de journaux
- (Si vous utilisez Amazon S3 comme destination de journalisation) Nom du compartiment
- (Si vous utilisez Amazon Data Firehose comme destination de journalisation) Firehose stream

Inclure les autorisations d'accès : l'utilisateur connecté à la console doit disposer des autorisations nécessaires pour écrire les journaux collectés vers la destination choisie.

L'exemple de politique IAM suivant peut être attaché à l'utilisateur connecté à la console pour accorder les autorisations nécessaires lors de l'utilisation CloudWatch de 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:*"
        ]
    }]
}

Confirmer le statut de livraison : vérifiez que le statut de livraison du journal est « Livraison active » dans la console.

Journalisation des bases de connaissances à l'aide de l' CloudWatch API

Pour activer la journalisation d'une base de connaissances Amazon Bedrock à l'aide de l' CloudWatch API :

Obtenez l'ARN de votre base de connaissances : après avoir créé une base de connaissances à l'aide de l'API Amazon Bedrock ou de la console Amazon Bedrock, obtenez le nom de ressource Amazon de la base de connaissances. Vous pouvez obtenir le nom de la ressource Amazon en appelant GetKnowledgeBasel'API. Le nom de ressource Amazon d'une base de connaissances suit le format suivant : arn:aws:bedrock:your-region:your-account-id:knowledge-base/knowledge-base-id
Appel PutDeliverySource : utilisez l'PutDeliverySourceAPI fournie par Amazon CloudWatch pour créer une source de diffusion pour la base de connaissances. Transmettez le nom de la ressource Amazon de la base de connaissances en tant queresourceArn. logTypeindique APPLICATION_LOGS le type de journaux collectés. APPLICATION_LOGSsuivre l'état actuel des fichiers lors d'une tâche d'ingestion.
```
{
    "logType": "APPLICATION_LOGS",
    "name": "my-knowledge-base-delivery-source",
    "resourceArn": "arn:aws:bedrock:your-region:your-account-id:knowledge-base/knowledge_base_id"
}
```
Appel PutDeliveryDestination : utilisez l'PutDeliveryDestinationAPI fournie par Amazon CloudWatch pour configurer l'endroit où les journaux seront stockés. Vous pouvez choisir CloudWatch Logs, Amazon S3 ou Amazon Data Firehose comme destination pour le stockage des journaux. Vous devez spécifier le nom de ressource Amazon de l'une des options de destination pour l'emplacement de stockage de vos journaux. Vous pouvez choisir outputFormat l'un des journaux suivants :json,plain, w3craw,parquet. Voici un exemple de configuration des journaux à stocker dans un compartiment Amazon S3 et au format JSON.
```
{
   "deliveryDestinationConfiguration": { 
      "destinationResourceArn": "arn:aws:s3:::bucket-name"
   },
   "name": "string",
   "outputFormat": "json",
   "tags": { 
      "key" : "value" 
   }
}
```
Notez que si vous distribuez des journaux entre comptes, vous devez utiliser l'PutDeliveryDestinationPolicyAPI pour attribuer une politique AWS Identity and Access Management (IAM) au compte de destination. La politique IAM autorise la livraison d'un compte à un autre.
Appel CreateDelivery : utilisez l'appel CreateDeliveryd'API pour lier la source de livraison à la destination que vous avez créée lors des étapes précédentes. Cette opération d'API associe la source de livraison à la destination finale.
```
{
   "deliveryDestinationArn": "string",
   "deliverySourceName": "string",
   "tags": { 
      "string" : "string" 
   }
}
```

Note

Si vous souhaitez utiliser AWS CloudFormation, vous pouvez utiliser ce qui suit :

ResourceArnIl s'agit du KnowledgeBaseARN type de journal pris en charge et LogType doit être APPLICATION_LOGS le type de journal pris en charge.

Types de journaux pris en charge

Les bases de connaissances Amazon Bedrock prennent en charge les types de journaux suivants :

APPLICATION_LOGS: journaux qui suivent l'état actuel d'un fichier spécifique lors d'une tâche d'ingestion de données.

Autorisations et limites des utilisateurs

Pour activer la journalisation pour une base de connaissances Amazon Bedrock, les autorisations suivantes sont requises pour le compte utilisateur connecté à la console :

bedrock:AllowVendedLogDeliveryForResource— Nécessaire pour autoriser la livraison de journaux pour la ressource de la base de connaissances.

Vous pouvez consulter un exemple de politique de rôle/d'autorisations IAM avec toutes les autorisations requises pour votre destination de journalisation spécifique. Consultez les autorisations des journaux Vended pour différentes destinations de livraison et suivez l'exemple de politique de rôle/autorisation IAM pour votre destination de journalisation, notamment en autorisant les mises à jour de votre ressource de destination de journalisation spécifique (qu'il s'agisse de Logs, CloudWatch Amazon S3 ou Amazon Data Firehose).

Vous pouvez également vérifier s'il existe des limites de quota pour effectuer des appels d'API liés à la livraison CloudWatch des journaux dans la documentation sur les quotas du service CloudWatch Logs. Les limites de quota définissent le nombre maximal de fois que vous pouvez appeler une API ou créer une ressource. Si vous dépassez une limite, cela provoquera une ServiceQuotaExceededException erreur.

Exemples de journaux de base de connaissances

Il existe des journaux du niveau d'ingestion des données et des journaux du niveau des ressources pour les bases de connaissances Amazon Bedrock.

Voici un exemple de journal des tâches d'ingestion de données.


{
    "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"
}

Voici un exemple de journal au niveau des ressources.


{
    "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"
}

La status ressource peut être l'une des suivantes :

SCHEDULED_FOR_INGESTION,SCHEDULED_FOR_DELETION,SCHEDULED_FOR_UPDATE, SCHEDULED_FOR_METADATA_UPDATE : Ces valeurs d'état indiquent que le traitement de la ressource est planifié après avoir calculé la différence entre l'état actuel de la base de connaissances et les modifications apportées à la source de données.
RESOURCE_IGNORED: Cette valeur d'état indique que la ressource a été ignorée pour le traitement, et la raison est détaillée dans la status_reasons propriété.
EMBEDDING_STARTEDet EMBEDDING_COMPLETED : Ces valeurs d'état indiquent à quel moment l'intégration vectorielle d'une ressource a commencé et s'est terminée.
INDEXING_STARTEDet INDEXING_COMPLETED : Ces valeurs de statut indiquent le début et la fin de l'indexation d'une ressource.
DELETION_STARTEDet DELETION_COMPLETED : Ces valeurs de statut indiquent à quel moment la suppression d'une ressource a commencé et s'est terminée.
METADATA_UPDATE_STARTEDet METADATA_UPDATE_COMPLETED : Ces valeurs d'état indiquent à quel moment la mise à jour des métadonnées d'une ressource a commencé et s'est terminée.
EMBEDDING_FAILED, INDEXING_FAILEDDELETION_FAILED, et METADATA_UPDATE_FAILED : Ces valeurs de statut indiquent que le traitement d'une ressource a échoué, et les raisons sont détaillées dans la status_reasons propriété.
INDEXED,DELETED, PARTIALLY_INDEXEDMETADATA_PARTIALLY_INDEXED, FAILED : Une fois le traitement d'un document finalisé, un journal est publié avec le statut final du document et le résumé du traitement dans la chunk_statistics propriété.

Exemples de requêtes courantes pour déboguer les journaux de la base de connaissances

Vous pouvez interagir avec les journaux à l'aide de requêtes. Par exemple, vous pouvez rechercher tous les documents présentant le statut de l'événement RESOURCE_IGNORED lors de l'ingestion de documents ou de données.

Voici quelques requêtes courantes qui peuvent être utilisées pour déboguer les journaux générés à l'aide de CloudWatch Logs Insights :

Requête tous les journaux générés pour un document S3 spécifique.

filter event.document_location.s3_location.uri = "s3://<bucketName>/<objectKey>"
Requête pour tous les documents ignorés lors de la tâche d'ingestion de données.

filter event.status = "RESOURCE_IGNORED"
Recherchez toutes les exceptions survenues lors de l'intégration vectorielle de documents.

filter event.status = "EMBEDDING_FAILED"
Recherchez toutes les exceptions survenues lors de l'indexation de documents dans la base de données vectorielle.

filter event.status = "INDEXING_FAILED"
Recherchez toutes les exceptions survenues lors de la suppression de documents de la base de données vectorielle.

filter event.status = "DELETION_FAILED"
Recherchez toutes les exceptions survenues lors de la mise à jour des métadonnées de votre document dans la base de données vectorielle.

filter event.status = "DELETION_FAILED"
Recherchez toutes les exceptions survenues lors de l'exécution d'une tâche d'ingestion de données.

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

Avertissement JavaScript est désactivé ou n'est pas disponible dans votre navigateur.

Pour que vous puissiez utiliser la documentation AWS, Javascript doit être activé. Vous trouverez des instructions sur les pages d'aide de votre navigateur.

Conventions de rédaction

Surveillez l'invocation du modèle à l'aide des journaux CloudWatch

Surveillez Amazon Bedrock Guardrails à l'aide de métriques CloudWatch