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. # Beobachtbarkeit für verwaltete Wissensdatenbanken Für eine verwaltete Wissensdatenbank veröffentlicht Amazon Bedrock Betriebskennzahlen und Aufnahmeprotokolle in Ihrem AWS Konto, sodass Sie den Zustand und die Nutzung Ihrer Wissensdatenbank überwachen können. Mit Runtime-Metriken können Sie das Anforderungsvolumen, die Fehler und die Drosselung für Ihre Knowledge-Base-API-Operationen verfolgen, und mit Aufnahmeprotokollen können Sie den Status einzelner Dokumente während eines Datenaufnahme-Jobs verfolgen. In den folgenden Abschnitten werden die verfügbaren Observability-Daten und der Zugriff darauf beschrieben. ## Laufzeitmetriken für verwaltete Wissensdatenbanken Amazon Bedrock veröffentlicht Laufzeitmetriken für Ihre Knowledge-Base-API-Operationen auf Amazon CloudWatch unter dem `AWS/Bedrock/KnowledgeBases` Namespace. Verwenden Sie diese Metriken, um das Aufrufvolumen, die Fehlerraten und die Drosselung bei Vorgängen wie zu überwachen. `Retrieve` Metriken werden ohne zusätzliche Kosten in Ihrem Konto veröffentlicht und in der Konsole angezeigt. CloudWatch In der folgenden Tabelle werden die Laufzeitmetriken beschrieben, die Amazon Bedrock für verwaltete Wissensdatenbanken veröffentlicht. | Metrikname | Einheit | Description | | --- | --- | --- | | Aufrufe | Anzahl | Anzahl der Anfragen an den Knowledgebase-Vorgang. Diese Metrik wird für jede Anfrage veröffentlicht, auch für Anfragen, die zu einem Fehler führen. | | ClientErrors | Anzahl | Anzahl der Anfragen, die zu einem clientseitigen Fehler geführt haben (eine andere `4xx` HTTP-Antwort als Drosselung). | | ServerErrors | Anzahl | Anzahl der Anfragen, die zu einem serverseitigen Fehler geführt haben (eine HTTP-Antwort). `5xx` | | Drosselungen | Anzahl | Anzahl der Anfragen, die gedrosselt wurden (eine `429` HTTP-Antwort). Gedrosselte Anfragen werden nicht als oder gezählt. `ClientErrors` `ServerErrors` | Die `Throttles` Metriken `ClientErrors``ServerErrors`, und werden nur veröffentlicht, wenn die entsprechende Bedingung eintritt. Die `Invocations` Metrik wird für jede Anfrage veröffentlicht. ### Zusätzliche Metrik für den AgenticRetrieveStream Vorgang Zusätzlich zu den Metriken in der vorherigen Tabelle veröffentlicht der `AgenticRetrieveStream` Vorgang die folgende Metrik. | Metrikname | Einheit | Description | | --- | --- | --- | | TotalIterationCount | Anzahl | Die Gesamtzahl der während der Anfrage durchgeführten Agentenabruf-Iterationen. Diese Metrik wird nur für den `AgenticRetrieveStream` Vorgang veröffentlicht, wenn die Anfrage erfolgreich abgeschlossen wurde. | Diese Metrik verwendet die `Operation` Dimension mit einem Wert von`AgenticRetrieveStream`. ### Dimensionen für verwaltete Wissensdatenbank-Metriken Amazon Bedrock verwendet die folgenden Dimensionen für verwaltete Laufzeitmetriken der Wissensdatenbank. | Dimension | Description | | --- | --- | | Operation | Der Knowledge-Base-API-Vorgang, für den die Metrik veröffentlicht wurde. Mögliche Werte sind `Retrieve` und `AgenticRetrieveStream`. | | KnowledgeBaseId | Die Wissensdatenbank, auf die die Anfrage abzielt, im Format`knowledge-base/{{knowledge-base-id}}`. Diese Dimension ist in der `Retrieve` Operation enthalten, die auf eine einzige Wissensbasis abzielt. Operationen, die nicht auf eine einzige Wissensdatenbank abzielen, werden nur mit dieser `Operation` Dimension veröffentlicht. | ### Berechtigungen für die Veröffentlichung von Metriken Amazon Bedrock veröffentlicht diese Metriken unter Verwendung der mit der Anfrage verknüpften Anmeldeinformationen auf Ihrem Konto: + Für den `Retrieve` Betrieb verwendet Amazon Bedrock die Servicerolle Knowledge Base. + Für andere Operationen verwendet Amazon Bedrock die Anmeldeinformationen der aufrufenden Identität (des IAM-Benutzers oder der Rolle, die den Vorgang aufruft) über eine Forward-Access-Sitzung. Damit Metriken veröffentlicht werden können, muss diese Identität den Namespace aufrufen `cloudwatch:PutMetricData` dürfen. `AWS/Bedrock/KnowledgeBases` Fügen Sie der Wissensdatenbank-Dienstrolle und jeder Identität, die die Knowledge-Base-Operationen aufruft, eine Richtlinie hinzu, die diese Berechtigung erteilt. Im folgenden Beispiel wird die erforderliche Berechtigung erteilt. ``` { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "cloudwatch:PutMetricData", "Resource": "*", "Condition": { "StringEquals": { "cloudwatch:namespace": "AWS/Bedrock/KnowledgeBases" } } } ] } ``` Das Veröffentlichen von Metriken ist die beste Methode. Wenn die Identität nicht über die erforderlichen Berechtigungen verfügt, werden die entsprechenden Metriken nicht veröffentlicht, aber die Knowledge-Base-Anfrage selbst ist davon nicht betroffen. ### Laufzeit-Metriken anzeigen Sie können Metriken für Ihre Wissensdatenbank mit der AWS-Managementkonsole AWS CLI, der oder der CloudWatch API abrufen. Sie können die CloudWatch API über eines der AWS Software Development Kits (SDKs) oder die CloudWatch API-Tools verwenden. Um verwaltete Wissensdatenbank-Metriken in der CloudWatch Konsole anzuzeigen, gehen Sie zum Abschnitt Metriken im Navigationsbereich, wählen Sie die Option Alle Metriken aus und suchen Sie dann nach dem `AWS/Bedrock/KnowledgeBases` Namespace. Sie müssen über die entsprechenden CloudWatch Berechtigungen verfügen, um Ihre Wissensdatenbank überwachen zu können. CloudWatch Weitere Informationen finden Sie unter [Authentifizierung und Zugriffskontrolle für Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/auth-and-access-control-cw.html) im * CloudWatch Amazon-Benutzerhandbuch*. ## Speichermetriken für verwaltete Wissensdatenbanken Für eine verwaltete Wissensdatenbank veröffentlicht Amazon Bedrock eine Speichermetrik CloudWatch unter dem `AWS/Bedrock/KnowledgeBases` Namespace für Amazon. Diese Metrik gibt die gesamte Rohgröße der in der Wissensdatenbank gespeicherten Quelldaten an und wird nach Abschluss eines Datenerfassungsvorgangs in Ihrem Konto veröffentlicht, sodass Sie verfolgen können, wie viele Daten im Laufe der Zeit in Ihrer Wissensdatenbank gespeichert sind. In der folgenden Tabelle wird die Speichermetrik beschrieben, die Amazon Bedrock für verwaltete Wissensdatenbanken veröffentlicht. | Metrikname | Einheit | Description | | --- | --- | --- | | RawDataSize | Gigabytes | Die gesamte Rohgröße der in der Wissensdatenbank gespeicherten Quelldaten in Gigabyte. Diese Metrik wird veröffentlicht, nachdem ein Datenaufnahmejob abgeschlossen ist. | Die Speichermetrik verwendet die `KnowledgeBaseId` Dimension im Format. `knowledge-base/{{knowledge-base-id}}` ## Beobachtbarkeit der Datenaufnahme für verwaltete Wissensdatenbanken Amazon Bedrock gibt Protokolle aus, die den Fortschritt eines Datenerfassungsauftrags für Ihre verwaltete Wissensdatenbank verfolgen, einschließlich des allgemeinen Auftragsstatus und des Status jedes verarbeiteten Dokuments. Sie können diese Protokolle verwenden, um zu bestätigen, welche Dokumente aufgenommen wurden, zu untersuchen, warum ein Dokument in den Abrufergebnissen nicht zurückgegeben wurde, und um Fehler bei der Erfassung zu beheben. Protokolle werden an ein von Ihnen konfiguriertes Ziel übermittelt (CloudWatch Logs, Amazon S3 oder Amazon Data Firehose). In den folgenden Abschnitten werden die Aktivierung der Protokollzustellung, der Lebenszyklus eines Dokuments während der Aufnahme, die Protokolltypen, die ausgegeben werden, und Beispielabfragen beschrieben. ### Aktivieren Sie die Übermittlung von Aufnahmeprotokollen Um Aufnahmeprotokolle zu erhalten, konfigurieren Sie eine Protokollzustellung für Ihre Wissensdatenbank mithilfe der API oder der AWS-Managementkonsole API. CloudWatch Sie können CloudWatch Protokolle an Logs, Amazon S3 oder Amazon Data Firehose senden. #### Aktivieren Sie die Protokollzustellung über die Konsole 1. **Öffnen Sie Ihre Wissensdatenbank**: Öffnen Sie in der Amazon Bedrock-Konsole die verwaltete Wissensdatenbank, die Sie überwachen möchten. 1. **Fügen Sie eine Protokollzustellung** hinzu: Bearbeiten Sie die Wissensdatenbank, um eine Protokollzustellung hinzuzufügen, und konfigurieren Sie die folgenden Details: + Das Protokollierungsziel (CloudWatch Logs, Amazon S3 oder Amazon Data Firehose). + (CloudWatch Logs) Der Name der Protokollgruppe. + (Amazon S3) Der Bucket-Name. + (Amazon Data Firehose) Der Firehose-Stream. 1. **Lieferstatus bestätigen**: Stellen Sie sicher, dass der Protokolllieferstatus in der Konsole „*Lieferung aktiv*“ lautet. #### Aktivieren Sie die Protokollzustellung mithilfe der CloudWatch API 1. **Den ARN Ihrer Wissensdatenbank abrufen**: Rufen Sie die [GetKnowledgeBase](https://docs.aws.amazon.com/bedrock/latest/APIReference/API_agent_GetKnowledgeBase.html)API auf, um den Amazon-Ressourcennamen (ARN) der Wissensdatenbank abzurufen. Ein Wissensdatenbank-ARN hat das folgende Format:{{arn:aws:bedrock:your-region:your-account-id:knowledge-base/knowledge-base-id}}. 1. **Aufruf `PutDeliverySource`**: Verwenden Sie die [PutDeliverySource](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_PutDeliverySource.html)API, um eine Lieferquelle für die Wissensdatenbank zu erstellen. Übergeben Sie den Knowledgebase-ARN als `resourceArn` und geben Sie `APPLICATION_LOGS` ihn als an`logType`. ``` { "logType": "APPLICATION_LOGS", "name": "my-knowledge-base-delivery-source", "resourceArn": "arn:aws:bedrock:your-region:your-account-id:knowledge-base/knowledge_base_id" } ``` 1. **Aufruf `PutDeliveryDestination`**: Verwenden Sie die [PutDeliveryDestination](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_PutDeliveryDestination.html)API, um zu konfigurieren, wo die Protokolle gespeichert werden. Geben Sie den ARN eines CloudWatch Logs-, Amazon S3- oder Amazon Data Firehose-Ziels an. Sie können `outputFormat` auf`json`,, `plain` `w3c``raw`, oder `parquet` einstellen. ``` { "deliveryDestinationConfiguration": { "destinationResourceArn": "arn:aws:s3:::bucket-name" }, "name": "my-knowledge-base-delivery-destination", "outputFormat": "json" } ``` Wenn Sie Protokolle an ein anderes Konto senden, verwenden Sie die `PutDeliveryDestinationPolicy` API, um eine AWS Identity and Access Management (IAM-) Richtlinie an das Zielkonto anzuhängen. 1. **Anruf `CreateDelivery`**: Verwenden Sie die [CreateDelivery](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_CreateDelivery.html)API, um die Lieferquelle mit dem Lieferziel zu verknüpfen. ``` { "deliveryDestinationArn": "string", "deliverySourceName": "my-knowledge-base-delivery-source" } ``` #### Unterstützte Protokolltypen und Berechtigungen Verwaltete Wissensdatenbanken unterstützen die folgenden Protokolltypen: + `APPLICATION_LOGS`: Protokolle, die den Status des Aufnahmeauftrags und jedes Dokuments, das während des Jobs verarbeitet wird, verfolgen. + `TRACES`: Verteilte Traces (Spans) für Laufzeitoperationen. Traces werden nur für den `Retrieve` Vorgang ausgegeben und an diese AWS X-Ray gesendet. Weitere Informationen finden Sie unter [Verfolgen Sie die Beobachtbarkeit für verwaltete Wissensdatenbanken](#kb-managed-observability-traces). Um die Protokollzustellung zu aktivieren, muss der Benutzer oder die Rolle zusätzlich zu den `bedrock:AllowVendedLogDeliveryForResource` Berechtigungen, die zum Schreiben in das von Ihnen gewählte Ziel erforderlich sind, über die erforderlichen Berechtigungen für die Wissensdatenbank-Ressource verfügen. Beispiele für IAM-Richtlinien für jedes Ziel finden Sie unter [Vended Logs-Berechtigungen für verschiedene Lieferziele](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AWS-logs-and-resource-policy.html#AWS-vended-logs-permissions-V2) im *Amazon CloudWatch Logs-Benutzerhandbuch*. ### Lebenszyklus von Dokumenten während der Aufnahme Während einer Datenaufnahme durchläuft jedes Dokument drei Phasen, und im Protokoll für das Dokument wird der Status jeder Phase aufgezeichnet: + **Crawl** (`crawl_status`): Amazon Bedrock ruft das Dokument aus der Datenquelle ab und bestimmt, ob es hinzugefügt, aktualisiert oder gelöscht werden muss. Das `crawl_action` Feld ist auf`ADD`, `DELETE` oder gesetzt. `UNMODIFIED` Ein Dokument, `UNMODIFIED` das in den verbleibenden Phasen übersprungen wird. + **Sync** (`sync_status`): Das Dokument wird zur Verarbeitung in die Wissensdatenbank eingereicht. + **Index** (`index_status`): Das Dokument ist aufgeteilt, eingebettet und dauerhaft in der Wissensdatenbank gespeichert. Das `chunk_statistics` Feld fasst die Blöcke zusammen, die erstellt oder gelöscht wurden. Jeder Stufenstatus ist oder. `SUCCESS` `FAILED` Das `connector_document_status` Feld gibt den konsolidierten Status des Dokuments an, und das `error_message` Feld wird nur gefüllt, wenn ein Dokument nicht verarbeitet werden kann. ### Protokolltypen und Beispiele Amazon Bedrock gibt zwei Arten von Protokolleinträgen für einen verwalteten Job zur Erfassung von Wissensdatenbanken aus, die sich nach dem Feld unterscheiden: `event_type` + `StartIngestionJob.StatusChanged`— Protokolle auf Jobebene, die den Fortschritt des gesamten Aufnahme-Jobs aufzeichnen, z. B. wann das Crawlen beginnt und abgeschlossen wird. Das `message` Feld enthält einen für Menschen lesbaren Status, zum Beispiel oder. `Crawling started` `Crawling completed` + `StartIngestionJob.ResourceStatusChanged`— Protokolle auf Dokumentebene, die den Verarbeitungsstatus eines einzelnen Dokuments aufzeichnen. Im Folgenden finden Sie ein Beispiel für ein Statusprotokoll auf Jobebene. ``` { "event_timestamp": 1718677300000, "event": { "ingestion_job_id": "", "data_source_id": "", "knowledge_base_arn": "arn:aws:bedrock:::knowledge-base/", "message": "Crawling started" }, "event_version": "1.0", "event_type": "StartIngestionJob.StatusChanged", "level": "INFO" } ``` Im Folgenden finden Sie ein Beispiel für ein Protokoll auf Dokumentebene, in dem der Verarbeitungsstatus eines einzelnen Dokuments aufgezeichnet wird. ``` { "event_timestamp": 1718677342332, "event": { "ingestion_job_id": "", "data_source_id": "", "knowledge_base_arn": "arn:aws:bedrock:::knowledge-base/", "document_id": "", "source_uri": "", "content_type": "", "crawl_action": "ADD" | "DELETE" | "UNMODIFIED", "index_status": { "Status": "SUCCESS" | "FAILED", "UpdatedTime": "" }, "crawl_status": { "Status": "SUCCESS" | "FAILED", "UpdatedTime": "" }, "sync_status": { "Status": "SUCCESS" | "FAILED", "UpdatedTime": "" }, "chunk_statistics": { "created": int, "deleted": int, "failed_to_create": int, "failed_to_delete": int }, "error_message": "" }, "event_version": "1.0", "event_type": "StartIngestionJob.ResourceStatusChanged", "level": "INFO" | "ERROR" } ``` Das `error_message` Feld ist nur vorhanden, wenn ein Dokument nicht verarbeitet werden kann. Das `chunk_statistics` Feld fasst die Abschnitte zusammen, die für das Dokument erstellt oder gelöscht wurden. In einigen Protokollen auf Dokumentebene wird anstelle der oben gezeigten Statusfelder eine Connector-Statusmeldung gemeldet. Diese Protokolle enthalten ein `message` Feld mit einer für Menschen lesbaren Beschreibung (z. B. eine Meldung, dass ein Dokument nicht abgerufen oder gelöscht werden konnte) und ein `level` Feld von, oder. `INFO` `WARN` `ERROR` ### Beispielabfragen Wenn Sie CloudWatch Protokolle an Logs senden, können Sie Logs Insights verwenden, um die CloudWatch Aufnahmeprotokolle für Ihre Wissensdatenbank abzufragen. Im Folgenden finden Sie einige häufig gestellte Fragen. + Listet alle Dokumente, die während der Aufnahme nicht verarbeitet werden konnten, mit ihren Fehlermeldungen auf. `filter event.connector_document_status.Status = "FAILED" | fields event.document_id, event.source_uri, event.error_message, @timestamp | sort @timestamp desc` + Findet alle Protokolleinträge für ein bestimmtes Dokument anhand seines Quellverzeichnisses. `filter event.source_uri = "s3:///" | fields event.document_id, event.connector_document_status.Status, @timestamp | sort @timestamp desc` + Listet alle Dokumente auf, die von einem bestimmten Aufnahmejob verarbeitet wurden. `filter event.ingestion_job_id = "" | fields event.document_id, event.connector_document_status.Status, @timestamp | sort @timestamp desc` + Zeigt den Gesamtfortschritt eines Aufnahme-Jobs an, einschließlich des Beginns und Abschlusses des Crawlings. `filter event_type = "StartIngestionJob.StatusChanged" | fields event.message, @timestamp | sort @timestamp asc` ## Verfolgen Sie die Beobachtbarkeit für verwaltete Wissensdatenbanken Amazon Bedrock kann verteilte Traces (Spans) für Laufzeitvorgänge in der Wissensdatenbank ausgeben, sodass Sie die Latenz von Anfragen und die internen Schritte einer Anfrage analysieren können. Traces werden nur für den `Retrieve` Vorgang ausgegeben und an diese gesendet. [AWS X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html) Bei der Trace-Zustellung wird dieselbe Pipeline für die Protokollzustellung verwendet wie bei den Aufnahmeprotokollen, allerdings mit dem `TRACES` Protokolltyp und einem X-Ray Zustellungsziel. ### Aktivieren Sie die Trace-Zustellung mithilfe der API CloudWatch Um Traces an zu senden AWS X-Ray, verwenden Sie die CloudWatch API, um eine Lieferung zu erstellen. Gehen Sie dabei wie folgt vor. 1. **Aufruf `PutDeliverySource`**: Verwenden Sie die [PutDeliverySource](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_PutDeliverySource.html)API, um eine Zustellungsquelle für die Wissensdatenbank zu erstellen. Übergeben Sie den Knowledgebase-ARN als `resourceArn` und geben Sie `TRACES` ihn als an`logType`. 1. **Aufruf `PutDeliveryDestination`**: Verwenden Sie die [PutDeliveryDestination](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_PutDeliveryDestination.html)API mit einem `deliveryDestinationType` von`XRAY`. X-Ray ist ein verwaltetes Ziel, daher geben Sie kein`destinationResourceArn`. Notieren Sie sich den ARN, der in der Antwort zurückgegeben wird. 1. **Aufruf `CreateDelivery`**: Verwenden Sie die [CreateDelivery](https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_CreateDelivery.html)API, um den Namen der Lieferquelle mit dem X-Ray Lieferziel-ARN zu verknüpfen. **Anmerkung** Diese API-Aufrufe sind idempotent. Wenn eine Ressource bereits existiert, können Sie ein `ConflictException` oder getrost ignorieren. `ResourceAlreadyExistsException` ### Berechtigungen für die Trace-Lieferung Um die Zustellung per Trace zu aktivieren, muss der Benutzer oder die Rolle zusätzlich zu den für die Zustellung erforderlichen Berechtigungen auch über die `bedrock:AllowVendedLogDeliveryForResource` Berechtigung für die Wissensdatenbank-Ressource verfügen AWS X-Ray. ### Ablaufverfolgungen anzeigen Nachdem Sie die Ablaufverfolgung aktiviert haben, rufen Sie den `Retrieve` Vorgang zur Generierung von Ablaufverfolgungen auf, und zeigen Sie sie dann in der AWS X-Ray Konsole an. ## AgentCore Beobachtbarkeit für verwaltete Wissensdatenbanken Amazon Bedrock integriert verwaltete Observabilitätsdaten aus der Wissensdatenbank in das Amazon Bedrock AgentCore Observability-Erlebnis und bietet Ihnen so einen konsolidierten Überblick über Ihre Wissensdatenbank-Metriken und Traces zusammen mit Ihren anderen Telemetriedaten. AgentCore Für diese Integration ist keine zusätzliche Konfiguration erforderlich. Nachdem Sie die Runtime-Metriken und die Trace-Bereitstellung wie in den vorherigen Abschnitten beschrieben aktiviert haben, wird Ihre AgentCore Observability-Seite automatisch mit den entsprechenden Wissensdatenbankdaten gefüllt. Es müssen keine zusätzlichen Maßnahmen ergriffen werden. **Anmerkung** AgentCore Die Observability-Integration ist nur für verwaltete Wissensdatenbanken verfügbar. ## Kundensupport und Problembehebung Amazon Bedrock Managed Knowledge Bases speichert vorübergehend Kundenanfragen und zugehörige Abrufdaten ausschließlich, um Debugging-Unterstützung bei von Kunden gemeldeten Problemen zu bieten. AWS greift nicht auf diese Daten zu, es sei denn, der Kunde stimmt im Rahmen eines Support-Auftrags ausdrücklich zu. Amazon Bedrock verwendet diese Daten nicht zum Trainieren oder Verbessern der zugrunde liegenden Modelle.