Protokollierung von Wissensdatenbanken mithilfe der Konsole Protokollierung von Wissensdatenbanken mithilfe der API CloudWatch Unterstützte Protokolltypen Benutzerberechtigungen und Beschränkungen Beispiele für Wissensdatenbankprotokolle Beispiele für häufig vorkommende Abfragen zum Debuggen von Wissensdatenbank-Protokollen

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

Protokollierung von Wissensdatenbanken mithilfe der Konsole

So aktivieren Sie die Protokollierung für eine Amazon-Bedrock-Wissensdatenbank mit der AWS-Managementkonsole:

Erstellen Sie eine Wissensdatenbank: Verwenden Sie Bedrock AWS-Managementkonsole für Amazon, um eine neue Wissensdatenbank zu erstellen.
Hinzufügen einer Option für die Protokollbereitstellung: Nachdem Sie die Wissensdatenbank erstellt haben, bearbeiten oder aktualisieren Sie Ihre Wissensdatenbank, um eine Option für die Protokollbereitstellung hinzuzufügen.

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

Konfigurieren von Details zur Protokollbereitstellung: Geben Sie die Details für die Protokollbereitstellung ein, einschließlich:
- 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 Protokollierungsziel verwendet wird) Bucket-Name
- (Wenn Sie Amazon Data Firehose als Protokollierungsziel verwenden) Firehose-Stream

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

Das folgende Beispiel für eine IAM-Richtlinie kann an den Benutzer angehängt werden, der an der Konsole angemeldet ist, um bei der Verwendung CloudWatch von Logs die erforderlichen Berechtigungen zu gewähren

Bestätigen des Bereitstellungsstatus: Stellen Sie sicher, dass der Status der Protokollbereitstellung in der Konsole „Bereitstellung aktiv“ lautet.

Protokollierung von Wissensdatenbanken mithilfe der API CloudWatch

So aktivieren Sie die Protokollierung für eine Amazon Bedrock-Wissensdatenbank mithilfe der CloudWatch API:

Abrufen des ARN Ihrer Wissensdatenbank: Nachdem Sie eine Wissensdatenbank entweder mit der Amazon-Bedrock-API oder der Amazon-Bedrock-Konsole erstellt haben, rufen Sie den Amazon-Ressourcennamen der Wissensdatenbank ab. Sie können den Amazon-Ressourcennamen abrufen, indem Sie die GetKnowledgeBaseAPI aufrufen. Eine Wissensdatenbank Amazon Resource Name folgt diesem Format: arn:aws:bedrock:your-region:your-account-id:knowledge-base/knowledge-base-id
Aufruf PutDeliverySource: Verwenden Sie die von Amazon bereitgestellte PutDeliverySourceAPI CloudWatch , um eine Lieferquelle für die Wissensdatenbank zu erstellen. Übergeben Sie den Amazon-Ressourcennamen der Wissensdatenbank als resourceArn. logType gibt APPLICATION_LOGS als Typ der gesammelten Protokolle an. APPLICATION_LOGS verfolgt den aktuellen Status von Dateien während eines Erfassungsauftrags.
```
{
    "logType": "APPLICATION_LOGS",
    "name": "my-knowledge-base-delivery-source",
    "resourceArn": "arn:aws:bedrock:your-region:your-account-id:knowledge-base/knowledge_base_id"
}
```
Aufruf PutDeliveryDestination: Verwenden Sie die von Amazon bereitgestellte PutDeliveryDestinationAPI 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 das outputFormat der Protokolle aus folgenden Optionen auswählen: json, plain, w3c, raw, parquet. Es folgt ein Beispiel für die Konfiguration von Protokollen, die in einem Amazon-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, die PutDeliveryDestinationPolicy API verwenden müssen, um dem Zielkonto eine AWS Identity and Access Management (IAM-) Richtlinie zuzuweisen. Die IAM-Richtlinie ermöglicht die Bereitstellung von einem Konto in einem anderen Konto.
Anruf CreateDelivery: Verwenden Sie den CreateDeliveryAPI-Aufruf, um die Versandquelle mit dem Ziel zu verknüpfen, das Sie in den vorherigen Schritten erstellt haben. Diese API-Operation verknüpft die Bereitstellungsquelle mit dem Endziel.
```
{
   "deliveryDestinationArn": "string",
   "deliverySourceName": "string",
   "tags": { 
      "string" : "string" 
   }
}
```

Anmerkung

Wenn Sie verwenden möchtenCloudFormation, können Sie Folgendes verwenden:

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

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

Benutzerberechtigungen und Beschränkungen

Zum Aktivieren der Protokollierung für eine Amazon-Bedrock-Wissensdatenbank sind die folgenden Berechtigungen für das an der Konsole angemeldete Benutzerkonto erforderlich:

bedrock:AllowVendedLogDeliveryForResource – Erforderlich, um die Bereitstellung von Protokollen für die Wissensdatenbank-Ressource zu erlauben.

Sie können sich ein Beispiel für eine role/permissions IAM-Richtlinie mit allen erforderlichen Berechtigungen für Ihr spezifisches Logging-Ziel ansehen. Sehen Sie sich Vended-Log-Berechtigungen für verschiedene Lieferziele an und folgen Sie dem Beispiel der role/permission IAM-Richtlinie für Ihr Logging-Ziel, einschließlich der Zulassung von Updates 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 CloudWatch Bereitstellung von CloudWatch Protokollen gibt. Mit den Kontingentlimits wird festgelegt, wie oft Sie eine API aufrufen oder eine Ressource erstellen können. Wenn Sie ein Limit überschreiten, führt dies zu einem ServiceQuotaExceededException-Fehler.

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.

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 CloudWatch Logs Insights generierten 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"

Warnung JavaScript ist in Ihrem Browser nicht verfügbar oder deaktiviert.

Zur Nutzung der AWS-Dokumentation muss JavaScript aktiviert sein. Weitere Informationen finden auf den Hilfe-Seiten Ihres Browsers.

Dokumentkonventionen

Überwachen Sie den Modellaufruf mithilfe von CloudWatch Logs und Amazon S3

Überwachen des Integritätsschutzes mit CloudWatch-Metriken