View a markdown version of this page

Surveillez les bases de connaissances à l'aide CloudWatch des journaux - Amazon Bedrock
Conditions préalablesActivation de la journalisation pour une base de connaissances Amazon Bedrock (console)Activation de la journalisation pour une base de connaissances (CloudWatch API) Amazon BedrockExemples de journaux de base de connaissancesExemples de requêtes courantes pour déboguer les journaux de base de connaissances

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

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 Console de gestion AWS et. Grâce à ce système de journalisation, vous pouvez bénéficier d’une meilleure visibilité sur l’ingestion de données de vos ressources de base de connaissances.

Conditions préalables

Avant d'activer la journalisation pour une base de connaissances Amazon Bedrock, vérifiez les points suivants :

  • Le compte utilisateur connecté à la console est bedrock:AllowVendedLogDeliveryForResource autorisé. Cette autorisation permet de fournir des journaux pour la ressource de la base de connaissances. Pour un exemple de politique IAM avec toutes les autorisations requises, voir Autorisations relatives aux journaux automatisés pour les différentes destinations de livraison. Suivez l'exemple de role/permission politique 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 CloudWatch Logs, Amazon S3 ou Amazon Data Firehose).

  • Vérifiez s'il existe des limites de quota pour les appels d'API liés à la livraison de CloudWatch journaux. Pour plus d'informations, consultez la documentation sur les quotas de service CloudWatch Logs. Si vous dépassez une limite, cela entraîne une ServiceQuotaExceededException erreur.

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 le statut actuel d’un fichier spécifique lors d’une tâche d’ingestion de données.

Activation de la journalisation pour une base de connaissances Amazon Bedrock (console)

Pour activer la journalisation à l'aide de la console

  1. Créez une base de connaissances. Pour obtenir des instructions, voir Création d'une base de connaissances.

  2. Modifiez votre base de connaissances pour ajouter une option de livraison des journaux.

    Note

    Les livraisons de journaux ne sont pas prises en charge lors de la création d’une base de connaissances avec un magasin de données structuré ou pour un index GenAI Kendra.

  3. Configurez les détails de livraison du journal, notamment :

    • Destination de journalisation (CloudWatch Logs, Amazon S3 ou Amazon Data Firehose)

    • (Si vous utilisez CloudWatch Logs) Nom du groupe de journaux

    • (Si vous utilisez Amazon S3) Nom du compartiment

    • (Si vous utilisez Amazon Data Firehose) Stream Firehose

  4. Associez une politique IAM à votre compte pour autoriser l'écriture de journaux vers la destination.

    L'exemple de politique IAM suivant accorde les autorisations nécessaires lors de l'utilisation de 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:*"
            ]
        }
    ]
}

  5. Vérifiez que l'état de remise du journal indique que la livraison est active dans la console.

Activation de la journalisation pour une base de connaissances (CloudWatch API) Amazon Bedrock

Pour activer la journalisation à l'aide de l' CloudWatch API

  1. Créez une base de connaissances à l'aide de l'API Amazon Bedrock ou de la console Amazon Bedrock. Pour obtenir des instructions, voir Création d'une base de connaissances.

  2. Obtenez l'ARN de votre base de connaissances. Appelez l'GetKnowledgeBaseAPI pour récupérer l'ARN. L'ARN d'une base de connaissances suit le format suivant : arn:aws:bedrock:your-region:your-account-id:knowledge-base/knowledge-base-id

  3. Appelez l'PutDeliverySourceAPI pour créer une source de diffusion pour la base de connaissances. Transmettez l'ARN de la base de connaissances en tant queresourceArn. Défini logType surAPPLICATION_LOGS, ce qui permet de suivre l'état des fichiers au cours 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"
}

  4. Appelez l'PutDeliveryDestinationAPI pour configurer l'emplacement de stockage des journaux.

    1. Choisissez CloudWatch Logs, Amazon S3 ou Amazon Data Firehose comme destination.

    2. Spécifiez l'ARN de la destination que vous avez choisie.

    3. outputFormatRéglez sur l'une des valeurs suivantes : jsonplain,,w3c,raw,parquet.

    L'exemple suivant stocke les journaux dans un compartiment Amazon S3 au format JSON :

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

    Pour diffuser des journaux entre comptes, utilisez l'PutDeliveryDestinationPolicyAPI pour attribuer une politique IAM au compte de destination. La politique autorise la livraison d'un compte à un autre.

  5. Appelez l'CreateDeliveryAPI pour lier la source de diffusion à la destination. Cela associe la source de diffusion à la destination finale.

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

Si vous souhaitez utiliser CloudFormation, vous pouvez utiliser les éléments suivants :

L’ResourceArn correspond à l’KnowledgeBaseARN et LogType doit être défini sur APPLICATION_LOGS, comme étant le type de journaux pris en charge.

Exemples de journaux de base de connaissances

Il existe des journaux au niveau de l’ingestion de données et des journaux au niveau des ressources pour les bases de connaissances Amazon Bedrock.

Voici un exemple de journal de 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" | "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"
}

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

Le status de la ressource peut être l’un des suivants :

  • SCHEDULED_FOR_INGESTION, SCHEDULED_FOR_DELETION, SCHEDULED_FOR_UPDATE, SCHEDULED_FOR_METADATA_UPDATE : ces valeurs de statut 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 de statut indique que la ressource a été ignorée pour le traitement, et la raison est détaillée dans la propriété status_reasons.

  • EMBEDDING_STARTED et EMBEDDING_COMPLETED : ces valeurs de statut indiquent à quel moment la vectorisation d’une ressource a commencé et s’est terminée.

  • INDEXING_STARTED et INDEXING_COMPLETED : ces valeurs de statut indiquent à quel moment l’indexation d’une ressource a commencé et s’est terminée.

  • DELETION_STARTED et DELETION_COMPLETED : ces valeurs de statut indiquent à quel moment la suppression d’une ressource a commencé et s’est terminée.

  • METADATA_UPDATE_STARTED et METADATA_UPDATE_COMPLETED : ces valeurs de statut indiquent à quel moment la mise à jour des métadonnées d’une ressource a commencé et s’est terminée.

  • EMBEDDING_FAILED, INDEXING_FAILED, DELETION_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 propriété status_reasons.

  • INDEXED, DELETED, PARTIALLY_INDEXED, METADATA_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 propriété chunk_statistics.

  • CRAWLED,RESOURCE_CRAWLED, RESOURCE_FETCHEDCRAWLING_COMPLETED, CONNECTOR_CRAWLING_COMPLETED : Ces valeurs d'état indiquent que la ressource a été analysée ou extraite depuis le connecteur de source de données.

  • PENDING,STARTING, IN_PROGRESS : Ces valeurs d'état indiquent que la ressource est en file d'attente ou en cours de traitement.

  • DELETE_IN_PROGRESS, DELETING : Ces valeurs d'état indiquent que la ressource est en cours de suppression.

  • INGESTION_JOB_STARTED, INGESTION_JOB_FAILED : Ces valeurs d'état indiquent le début ou l'échec de la tâche d'ingestion globale pour la ressource.

  • GRAPH_ENTITY_EXTRACTION_STARTED,GRAPH_ENTITY_EXTRACTION_COMPLETED, GRAPH_ENTITY_EXTRACTION_FAILED : Ces valeurs d'état indiquent la progression de l'extraction des entités graphiques pour les bases de connaissances qui utilisent un magasin de données graphiques.

Exemples de requêtes courantes pour déboguer les journaux de 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 d’é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 :

  • Recherchez tous les journaux générés pour un document S3 spécifique.

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

  • Recherchez 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 la vectorisation de documents.

    filter event.status = "EMBEDDING_FAILED"

  • Recherchez toutes les exceptions survenues lors de l’indexation de documents dans la base de données vectorielles.

    filter event.status = "INDEXING_FAILED"

  • Recherchez toutes les exceptions survenues lors de la suppression de documents de la base de données vectorielles.

    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 vectorielles.

    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"