View a markdown version of this page

Überwachen Sie Wissensdatenbanken mithilfe von CloudWatch Protokollen - Amazon Bedrock
VoraussetzungenAktivierung der Protokollierung für eine Amazon Bedrock-Wissensdatenbank (Konsole)Aktivierung der Protokollierung für eine Amazon Bedrock Knowledge Base (CloudWatch API)Beispiele für WissensdatenbankprotokolleBeispiele für häufig vorkommende Abfragen zum Debuggen von Wissensdatenbank-Protokollen

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Ü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 mithilfe der CloudWatch API AWS-Managementkonsole und aktivieren und konfigurieren. Mit diesem Protokollierungssystem können Sie sich einen Überblick über die Datenerfassung Ihrer Wissensdatenbank-Ressourcen verschaffen.

Voraussetzungen

Bevor Sie die Protokollierung für eine Amazon Bedrock-Wissensdatenbank aktivieren, überprüfen Sie Folgendes:

  • Das in der Konsole angemeldete Benutzerkonto verfügt über die bedrock:AllowVendedLogDeliveryForResource entsprechende Berechtigung. Diese Berechtigung ermöglicht die Bereitstellung von Protokollen für die Wissensdatenbank-Ressource. Ein Beispiel für eine IAM-Richtlinie mit allen erforderlichen Berechtigungen finden Sie unter Vended-Logs-Berechtigungen für verschiedene Übermittlungsziele. Folgen Sie dem Beispiel einer role/permission IAM-Richtlinie für Ihr Logging-Ziel, einschließlich der Zulassung von Aktualisierungen für Ihre spezifische Logging-Zielressource (ob CloudWatch Logs, Amazon S3 oder Amazon Data Firehose).

  • Prüfen Sie, ob es Kontingentbeschränkungen für API-Aufrufe im Zusammenhang mit der CloudWatch Logs-Lieferung gibt. Weitere Informationen finden Sie in der Dokumentation zu den Kontingenten für den CloudWatch Logs-Dienst. Wenn Sie einen Grenzwert überschreiten, führt dies zu einem ServiceQuotaExceededException Fehler.

Unterstützte Protokolltypen

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

  • APPLICATION_LOGS: Protokolle, die den aktuellen Status einer bestimmten Datei während eines Datenerfassungsauftrags verfolgen

Aktivierung der Protokollierung für eine Amazon Bedrock-Wissensdatenbank (Konsole)

Um die Protokollierung mit der Konsole zu aktivieren

  1. Erstellen Sie eine Wissensdatenbank. Eine Anleitung finden Sie unter Eine Wissensdatenbank erstellen.

  2. Bearbeiten Sie Ihre Wissensdatenbank, um eine Option für die Übermittlung von Protokollen hinzuzufügen.

    Anmerkung

    Protokollbereitstellungen werden nicht unterstützt, wenn eine Wissensdatenbank mit einem strukturierten Datenspeicher oder für einen Kendra GenAI-Index erstellt wird.

  3. Konfigurieren Sie die Details zur Protokollzustellung, einschließlich:

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

    • (Bei Verwendung von CloudWatch Logs) Name der Protokollgruppe

    • (Wenn Sie Amazon S3 verwenden) Bucket-Name

    • (Wenn Sie Amazon Data Firehose verwenden) Firehose-Stream

  4. Fügen Sie Ihrem Konto eine IAM-Richtlinie hinzu, um Berechtigungen zum Schreiben von Protokollen an das Ziel zu gewähren.

    Das folgende Beispiel für eine IAM-Richtlinie gewährt die erforderlichen Berechtigungen bei der Verwendung von 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. Vergewissern Sie sich, dass für den Status der Protokollzustellung in der Konsole Delivery active angezeigt wird.

Aktivierung der Protokollierung für eine Amazon Bedrock Knowledge Base (CloudWatch API)

Um die Protokollierung mithilfe der CloudWatch API zu aktivieren

  1. Erstellen Sie mithilfe der Amazon Bedrock-API oder der Amazon Bedrock-Konsole eine Wissensdatenbank. Eine Anleitung finden Sie unter Eine Wissensdatenbank erstellen.

  2. Holen Sie sich den ARN Ihrer Wissensdatenbank. Rufen Sie die GetKnowledgeBase API auf, um den ARN abzurufen. Ein Knowledgebase-ARN folgt diesem Format: arn:aws:bedrock:your-region:your-account-id:knowledge-base/knowledge-base-id

  3. Rufen Sie die PutDeliverySource API auf, um eine Lieferquelle für die Wissensdatenbank zu erstellen. Übergeben Sie den ARN der Wissensdatenbank alsresourceArn. Auf festgelegt logTypeAPPLICATION_LOGS, wodurch der Status von Dateien während eines Aufnahmeauftrags verfolgt wird.

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

  4. Rufen Sie die PutDeliveryDestination API auf, um zu konfigurieren, wo die Protokolle gespeichert werden.

    1. Wählen Sie CloudWatch Logs, Amazon S3 oder Amazon Data Firehose als Ziel.

    2. Geben Sie den ARN Ihres ausgewählten Ziels an.

    3. Stellen outputFormat Sie einen der folgenden Werte ein: jsonplain,w3c,raw,parquet.

    Im folgenden Beispiel werden Protokolle in einem Amazon S3-Bucket im JSON-Format gespeichert:

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

    Um Protokolle kontoübergreifend bereitzustellen, verwenden Sie die PutDeliveryDestinationPolicy API, um dem Zielkonto eine IAM-Richtlinie zuzuweisen. Die Richtlinie ermöglicht die Übertragung von einem Konto auf ein anderes.

  5. Rufen Sie die CreateDelivery API auf, um die Lieferquelle mit dem Ziel zu verknüpfen. Dadurch wird die Lieferquelle mit dem Endziel verknüpft.

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

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

Der ResourceArn ist der KnowledgeBaseARN und LogType muss APPLICATION_LOGS als unterstützten Protokolltyp aufweisen.

Beispiele für Wissensdatenbankprotokolle

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

Im Folgenden finden Sie ein Beispiel für ein Protokoll eines Datenerfassungsauftrags.

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

Im Folgenden finden Sie 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"
}

Beim status für die Ressource kann es sich um einen der folgenden Werte handeln:

  • SCHEDULED_FOR_INGESTION, SCHEDULED_FOR_DELETION, SCHEDULED_FOR_UPDATE oder 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_STARTED und EMBEDDING_COMPLETED: Diese Statuswerte geben an, wann die Vektoreinbettung für eine Ressource begonnen und abgeschlossen wurde.

  • INDEXING_STARTED und INDEXING_COMPLETED: Diese Statuswerte geben an, wann die Indizierung für eine Ressource begonnen und abgeschlossen wurde.

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

  • METADATA_UPDATE_STARTED und METADATA_UPDATE_COMPLETED: Diese Statuswerte geben an, wann die Aktualisierung der Metadaten für eine Ressource begonnen und abgeschlossen wurde.

  • EMBEDDING_FAILED, INDEXING_FAILED, DELETION_FAILED und METADATA_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.

  • CRAWLED,RESOURCE_CRAWLED, RESOURCE_FETCHEDCRAWLING_COMPLETED,CONNECTOR_CRAWLING_COMPLETED: Diese Statuswerte geben an, dass die Ressource gecrawlt oder vom Datenquellen-Connector abgerufen wurde.

  • PENDING,STARTING,IN_PROGRESS: Diese Statuswerte geben an, dass sich die Ressource in der Warteschlange befindet oder gerade verarbeitet wird.

  • DELETE_IN_PROGRESS,DELETING: Diese Statuswerte geben an, dass die Ressource gerade gelöscht wird.

  • INGESTION_JOB_STARTED,INGESTION_JOB_FAILED: Diese Statuswerte geben an, ob der gesamte Aufnahmevorgang für die Ressource gestartet oder fehlgeschlagen ist.

  • GRAPH_ENTITY_EXTRACTION_STARTED,GRAPH_ENTITY_EXTRACTION_COMPLETED,GRAPH_ENTITY_EXTRACTION_FAILED: Diese Statuswerte geben den Fortschritt der Extraktion von Graphentitäten für Wissensdatenbanken an, die einen Graphdatenspeicher verwenden.

Beispiele für häufig vorkommende Abfragen zum Debuggen von Wissensdatenbank-Protokollen

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

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

  • Abfrage nach allen Protokollen, die für ein bestimmtes S3-Dokument generiert wurden

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

  • Abfrage nach allen Dokumenten, die bei der Datenerfassung ignoriert wurden

    filter event.status = "RESOURCE_IGNORED"

  • Abfrage nach allen Ausnahmen, die beim Einbetten von Vektordokumenten aufgetreten sind

    filter event.status = "EMBEDDING_FAILED"

  • Abfrage nach allen Ausnahmen, die beim Indizieren von Dokumenten in der Vektordatenbank aufgetreten sind

    filter event.status = "INDEXING_FAILED"

  • Abfrage nach allen Ausnahmen, die beim Löschen von Dokumenten in der Vektordatenbank aufgetreten sind

    filter event.status = "DELETION_FAILED"

  • Abfrage nach allen Ausnahmen, die beim Aktualisieren der Metadaten Ihres Dokuments in der Vektordatenbank aufgetreten sind

    filter event.status = "DELETION_FAILED"

  • Abfrage nach allen Ausnahmen, die bei der Ausführung eines Datenerfassungsauftrags aufgetreten sind.

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