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 utilisateur Exemples de journaux de base de connaissances Exemples de requêtes courantes pour déboguer les journaux de 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 bénéficier d’une meilleure visibilité sur l’ingestion des données de vos ressources de 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 la 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.

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.

Configurer les détails de livraison de journaux : saisissez les détails de la livraison de journaux, notamment les éléments suivants :
- 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
- (En cas d’utilisation d’Amazon S3 comme destination de journalisation) Nom du compartiment
- (En cas d’utilisation d’Amazon Data Firehose comme destination de journalisation) Flux Firehose

Inclure les autorisations d’accès : l’utilisateur connecté à la console doit disposer des autorisations nécessaires pour écrire les journaux recueillis dans 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.

Confirmer le statut de livraison : vérifiez que le statut de livraison des journaux 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 :

Obtenir 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 l’Amazon Resource Name 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 l’Amazon Resource Name de la base de connaissances comme resourceArn. logType indique APPLICATION_LOGS comme type de journaux recueillis. Les APPLICATION_LOGS suivent le statut 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'emplacement de stockage des journaux. Vous pouvez choisir CloudWatch Logs, Amazon S3 ou Amazon Data Firehose comme destination pour le stockage des journaux. Vous devez spécifier l’Amazon Resource Name de l’une des options de destination pour l’emplacement de stockage de vos journaux. Vous pouvez choisir le outputFormat des journaux parmi les suivants : json, plain, w3c, raw, parquet. Voici un exemple de configuration de 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 Gestion des identités et des accès AWS (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 utiliserCloudFormation, vous pouvez utiliser ce qui suit :

L’ResourceArn correspond à l’KnowledgeBaseARN et LogType doit être défini sur APPLICATION_LOGS, comme étant le type de journaux 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 le statut actuel d’un fichier spécifique lors d’une tâche d’ingestion de données.

Autorisations et limites utilisateur

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 des journaux pour la ressource de base de connaissances.

Vous pouvez consulter un exemple de role/permissions politique IAM avec toutes les autorisations requises pour votre destination de journalisation spécifique. Consultez les autorisations relatives aux journaux Vended pour les différentes destinations de livraison et 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).

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 un nombre maximum de fois que vous pouvez appeler une API ou créer une ressource. Si vous dépassez une limite, cela entraîne une erreur ServiceQuotaExceededException.

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.

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"

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 de CloudWatch Logs et d'Amazon S3

Surveillance des barrières de protection à l’aide de métriques CloudWatch