Überwachen Sie Wissensdatenbanken mithilfe von CloudWatch Protokollen

Amazon Bedrock unterstützt ein Überwachungssystem, das Ihnen hilft, die Ausführung von Datenerfassungsaufträgen für Ihre Wissensdatenbanken nachzuvollziehen. In den folgenden Abschnitten wird beschrieben, wie Sie das Protokollierungssystem für Amazon Bedrock-Wissensdatenbanken aktivieren und konfigurieren, indem Sie beide AWS Management Console und. CloudWatch API Mit diesem Protokollierungssystem können Sie sich einen Überblick über die Datenaufnahme Ihrer Wissensdatenbank-Ressourcen verschaffen.

Protokollierung von Wissensdatenbanken mithilfe der Konsole

Um die Protokollierung für eine Amazon Bedrock-Wissensdatenbank zu aktivieren, verwenden Sie den AWS Management Console:

1. Erstellen Sie eine Wissensdatenbank: Verwenden Sie die AWS Management Console für Amazon Bedrock, um eine neue Wissensdatenbank zu erstellen.

2. Fügen Sie eine Option für die Protokollzustellung hinzu: Nachdem Sie die Wissensdatenbank erstellt haben, bearbeiten oder aktualisieren Sie Ihre Wissensdatenbank, um eine Option für die Protokollzustellung hinzuzufügen.

   Details zur Protokollzustellung konfigurieren: Geben Sie die Details für die Protokollzustellung ein, darunter:

   • Ziel der Protokollierung (entweder CloudWatch Logs, Amazon S3, Amazon Data Firehose)

   • (Wenn CloudWatch Logs als Ziel für die Protokollierung verwendet wird) Name der Protokollgruppe

   • (Wenn Amazon S3 als Logging-Ziel verwendet wird) Bucket-Name

   • (Wenn Sie Amazon Data Firehose als Logging-Ziel verwenden) Firehose-Stream

3. Zugriffsberechtigungen einbeziehen: Der Benutzer, der an der Konsole angemeldet ist, muss über die erforderlichen Berechtigungen verfügen, um die gesammelten Protokolle an das gewählte Ziel zu schreiben.

   Die folgende IAM Beispielrichtlinie kann dem an der Konsole angemeldeten Benutzer angehängt werden, um die erforderlichen Berechtigungen bei der Verwendung von CloudWatch Logs zu gewähren

   {
       "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:*"
           ]
       }]
   }
   

4. Übermittlungsstatus bestätigen: Stellen Sie sicher, dass der Status der Protokollzustellung in der Konsole „Versand aktiv“ lautet.

Protokollierung von Wissensdatenbanken mit dem CloudWatch API

Um die Protokollierung für eine Amazon Bedrock-Wissensdatenbank zu aktivieren, verwenden Sie: CloudWatch API

1. Machen Sie sich mit ARN Ihrer Wissensdatenbank vertraut: Nachdem Sie eine Wissensdatenbank mit der Amazon Bedrock API - oder der Amazon Bedrock-Konsole erstellt haben, rufen Sie den Amazon-Ressourcennamen der Wissensdatenbank ab. Den Amazon-Ressourcennamen erhalten Sie telefonisch GetKnowledgeBaseAPI. Eine Wissensdatenbank Amazon Resource Name folgt diesem Format: arn:aws:bedrock:your-region:your-account-id:knowledge-base/knowledge-base-id

2. Anruf PutDeliverySource: Verwenden Sie die von Amazon PutDeliverySourceAPIbereitgestellten CloudWatch , um eine Lieferquelle für die Wissensdatenbank zu erstellen. Übergeben Sie den Amazon-Ressourcennamen der Wissensdatenbank alsresourceArn. logTypegibt APPLICATION_LOGS als Typ der gesammelten Protokolle an. APPLICATION_LOGSverfolgt den aktuellen Status von Dateien während eines Aufnahmevorgangs.

   {
       "logType": "APPLICATION_LOGS",
       "name": "my-knowledge-base-delivery-source",
       "resourceArn": "arn:aws:bedrock:your-region:your-account-id:knowledge-base/knowledge_base_id"
   }
   

3. Anruf PutDeliveryDestination: Verwenden Sie das von Amazon PutDeliveryDestinationAPIbereitgestellte CloudWatch , um zu konfigurieren, wo die Protokolle gespeichert werden. Sie können entweder CloudWatch Logs, Amazon S3 oder Amazon Data Firehose als Ziel für das Speichern von Protokollen wählen. Sie müssen den Amazon-Ressourcennamen einer der Zieloptionen angeben, wo Ihre Protokolle gespeichert werden sollen. Sie können outputFormat eines der folgenden Protokolle wählen:json,,plain, w3craw,parquet. Im Folgenden finden Sie ein Beispiel für die Konfiguration von Protokollen, die in einem Amazon S3 S3-Bucket und im JSON Format gespeichert werden sollen.

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

   Beachten Sie, dass Sie, wenn Sie Protokolle kontoübergreifend bereitstellen, das verwenden müssen, PutDeliveryDestinationPolicy API um eine AWS Identity and Access Management (IAM) Richtlinie für das Zielkonto. Die IAM Richtlinie ermöglicht die Lieferung von einem Konto zu einem anderen Konto.

4. Anruf CreateDelivery: Verwenden Sie den CreateDeliveryAPIAnruf, um die Lieferquelle mit dem Ziel zu verknüpfen, das Sie in den vorherigen Schritten erstellt haben. Bei diesem API Vorgang wird die Lieferquelle dem Endziel zugeordnet.

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

Anmerkung

Wenn Sie verwenden möchten AWS CloudFormation, können Sie Folgendes verwenden:

• Lieferung

• DeliveryDestination

• DeliverySource

Der ResourceArn ist der KnowledgeBaseARN unterstützte Protokolltyp und LogType muss APPLICATION_LOGS auch so sein.

Unterstützte Protokolltypen

Die Amazon Bedrock-Wissensdatenbanken unterstützen die folgenden Protokolltypen:

• APPLICATION_LOGS: Protokolle, die den aktuellen Status einer bestimmten Datei während eines Datenaufnahme-Jobs verfolgen.

Benutzerberechtigungen und Beschränkungen

Um die Protokollierung für eine Amazon Bedrock-Wissensdatenbank zu aktivieren, sind die folgenden Berechtigungen für das an der Konsole angemeldete Benutzerkonto erforderlich:

1. bedrock:AllowVendedLogDeliveryForResource— Erforderlich, um die Übermittlung von Protokollen für die Wissensdatenbank-Ressource zu ermöglichen.

   Sie können sich ein Beispiel für eine IAM Rollen-/Berechtigungsrichtlinie mit allen erforderlichen Berechtigungen für Ihr spezifisches Protokollierungsziel ansehen. Sehen Sie sich Vended-Log-Berechtigungen für verschiedene Lieferziele an und folgen Sie dem Beispiel für IAM Rollen-/Berechtigungsrichtlinien für Ihr Protokollierungsziel, einschließlich der Zulassung von Aktualisierungen für Ihre spezifische Logging-Zielressource ( CloudWatch Logs, Amazon S3 oder Amazon Data Firehose).

In der Dokumentation zu den Kontingenten für den Logs-Service können Sie auch überprüfen, ob es Kontingentbeschränkungen für API Aufrufe im Zusammenhang mit der Übermittlung von CloudWatch Protokollen gibt. CloudWatch Mit Kontingentbeschränkungen legen Sie fest, wie oft Sie eine Ressource aufrufen API oder eine Ressource erstellen können. Wenn Sie ein Limit überschreiten, führt dies zu einem ServiceQuotaExceededException Fehler.

Beispiele für Wissensdatenbank-Logs

Es gibt Protokolle auf Datenerfassungsebene und Protokolle auf Ressourcenebene für Amazon Bedrock-Wissensdatenbanken.

Im Folgenden finden Sie ein Beispiel für ein Jobprotokoll zur Datenaufnahme.

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

Das Folgende ist ein Beispiel für ein Protokoll auf Ressourcenebene.

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

Das status für die Ressource kann eines der folgenden sein:

• SCHEDULED_FOR_INGESTION,SCHEDULED_FOR_DELETION,SCHEDULED_FOR_UPDATE,SCHEDULED_FOR_METADATA_UPDATE: Diese Statuswerte geben an, dass die Verarbeitung der Ressource geplant ist, nachdem die Differenz zwischen dem aktuellen Status der Wissensdatenbank und den an der Datenquelle vorgenommenen Änderungen berechnet wurde.

• RESOURCE_IGNORED: Dieser Statuswert gibt an, dass die Ressource bei der Verarbeitung ignoriert wurde. Der Grund dafür ist in der status_reasons Eigenschaft detailliert beschrieben.

• EMBEDDING_STARTEDundEMBEDDING_COMPLETED: Diese Statuswerte geben an, wann die Vektoreinbettung für eine Ressource begonnen und abgeschlossen wurde.

• INDEXING_STARTEDundINDEXING_COMPLETED: Diese Statuswerte geben an, wann die Indizierung für eine Ressource gestartet und abgeschlossen wurde.

• DELETION_STARTEDundDELETION_COMPLETED: Diese Statuswerte geben an, wann der Löschvorgang für eine Ressource begonnen und abgeschlossen wurde.

• METADATA_UPDATE_STARTEDundMETADATA_UPDATE_COMPLETED: Diese Statuswerte geben an, wann die Metadaten-Aktualisierung für eine Ressource gestartet und abgeschlossen wurde.

• EMBEDDING_FAILED, INDEXING_FAILEDDELETION_FAILED, undMETADATA_UPDATE_FAILED: Diese Statuswerte geben an, dass die Verarbeitung einer Ressource fehlgeschlagen ist. Die Gründe dafür sind in der status_reasons Eigenschaft detailliert beschrieben.

• INDEXED,DELETED,PARTIALLY_INDEXED,METADATA_PARTIALLY_INDEXED,FAILED: Sobald die Verarbeitung eines Dokuments abgeschlossen ist, wird ein Protokoll veröffentlicht, das den endgültigen Status des Dokuments und die Zusammenfassung der Verarbeitung in der chunk_statistics Eigenschaft enthält.

Beispiele für häufig vorkommende Abfragen zum Debuggen von Knowledge-Base-Logs

Sie können mithilfe von Abfragen mit Protokollen interagieren. Sie können beispielsweise alle Dokumente abfragen, deren Ereignisstatus RESOURCE_IGNORED bei der Aufnahme von Dokumenten oder Daten besteht.

Im Folgenden finden Sie einige häufig verwendete Abfragen, die zum Debuggen der mit CloudWatch Logs Insights generierten Protokolle verwendet werden können:

• Fragen Sie nach allen Protokollen ab, die für ein bestimmtes S3-Dokument generiert wurden.

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

• Abfrage für alle Dokumente, die bei der Datenerfassung ignoriert wurden.

  filter event.status = "RESOURCE_IGNORED"

• Fragt nach allen Ausnahmen ab, die beim Einbetten von Vektordokumenten aufgetreten sind.

  filter event.status = "EMBEDDING_FAILED"

• Fragt nach allen Ausnahmen ab, die beim Indizieren von Dokumenten in die Vektordatenbank aufgetreten sind.

  filter event.status = "INDEXING_FAILED"

• Fragt nach allen Ausnahmen ab, die beim Löschen von Dokumenten aus der Vektordatenbank aufgetreten sind.

  filter event.status = "DELETION_FAILED"

• Fragen Sie nach allen Ausnahmen ab, die beim Aktualisieren der Metadaten Ihres Dokuments in der Vektordatenbank aufgetreten sind.

  filter event.status = "DELETION_FAILED"

• Fragen Sie nach allen Ausnahmen ab, die bei der Ausführung eines Datenaufnahmeauftrags aufgetreten sind.

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