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.
# Fehler in Amazon Data Firehose beheben
Wenn Firehose bei der Bereitstellung oder Verarbeitung von Daten auf Fehler stößt, versucht es erneut, bis die konfigurierte Wiederholungsdauer abgelaufen ist. Wenn die Wiederholungsdauer endet, bevor die Daten erfolgreich übermittelt wurden, sichert Firehose die Daten im konfigurierten S3-Backup-Bucket. Wenn das Ziel Amazon S3 ist und die Lieferung fehlschlägt oder wenn die Lieferung an den Backup-S3-Bucket fehlschlägt, versucht Firehose es so lange erneut, bis die Aufbewahrungsfrist abgelaufen ist.
Informationen zur Nachverfolgung von Lieferfehlern mithilfe von finden Sie CloudWatch unter. [Überwachen Sie Amazon Data Firehose mithilfe von Protokollen CloudWatch](monitoring-with-cloudwatch-logs.md)
------
#### [ Direct PUT ]
Bei `DirectPut` Firehose-Streams bewahrt Firehose die Aufzeichnungen 24 Stunden lang auf. Für einen Firehose-Stream, dessen Datenquelle ein Kinesis-Datenstream ist, können Sie den Aufbewahrungszeitraum ändern, wie unter [Ändern des Datenaufbewahrungszeitraums](https://docs.aws.amazon.com/streams/latest/dev/kinesis-extended-retention.html) beschrieben. In diesem Fall wiederholt Firehose die folgenden Operationen auf unbestimmte Zeit:`DescribeStream`, und`GetRecords`. `GetShardIterator`
Wenn der Firehose-Stream verwendet`DirectPut`, überprüfen Sie die `IncomingRecords` Metriken `IncomingBytes` und, um festzustellen, ob eingehender Datenverkehr vorhanden ist. Wenn Sie `PutRecord` oder `PutRecordBatch` verwenden, müssen Sie Ausnahmen abfangen und Wiederholungsversuche veranlassen. Wir empfehlen eine Wiederholungsrichtlinie mit exponentiellem Backoff mit Jitter und mehreren Wiederholungsversuchen. Wenn Sie die `PutRecordBatch` API verwenden, stellen Sie außerdem sicher, dass Ihr Code den Wert von [FailedPutCount](https://docs.aws.amazon.com/firehose/latest/APIReference/API_PutRecordBatch.html#Firehose-PutRecordBatch-response-FailedPutCount)in der Antwort überprüft, auch wenn der API-Aufruf erfolgreich ist.
------
#### [ Kinesis Data Stream ]
Wenn der Firehose-Stream einen Kinesis-Datenstream als Quelle verwendet, überprüfen Sie die `IncomingBytes` `IncomingRecords` UND-Metriken für den Quelldatenstream. Stellen Sie außerdem sicher, dass die `DataReadFromKinesisStream.Records` Metriken `DataReadFromKinesisStream.Bytes` und für den Firehose-Stream ausgegeben werden.
------
# Häufige Probleme
Im Folgenden finden Sie Tipps zur Fehlerbehebung, die Ihnen helfen sollen, häufig auftretende Probleme bei der Arbeit mit einem Firehose-Stream zu lösen.
## Firehose-Stream nicht verfügbar
Der Firehose-Stream ist nicht als Ziel für CloudWatch Protokolle, CloudWatch Ereignisse oder AWS IoT-Aktionen verfügbar, da einige AWS Dienste nur Nachrichten und Ereignisse an einen Firehose-Stream senden können, der sich im selben befindet. AWS-Region Stellen Sie sicher, dass sich Ihr Firehose-Stream in derselben Region wie Ihre anderen Dienste befindet.
## Keine Daten am Ziel
Wenn es keine Probleme bei der Datenaufnahme gibt und die für den Firehose-Stream ausgegebenen Metriken gut aussehen, Sie die Daten am Ziel jedoch nicht sehen, überprüfen Sie die Leselogik. Stellen Sie sicher, dass die Lesekomponente alle Daten richtig analysiert.
## Die Metrik zur Datenaktualität nimmt zu oder wird nicht ausgegeben
Die Datenaktualität ist ein Maß dafür, wie aktuell Ihre Daten in Ihrem Firehose-Stream sind. Es ist das Alter des ältesten Datensatzes im Firehose-Stream, gemessen von der Zeit, als Firehose die Daten aufgenommen hat, bis heute. Firehose bietet Metriken, mit denen Sie die Datenaktualität überwachen können. Für Informationen zum Identifizieren der Datenaktualitätsmetrik für ein bestimmtes Ziel siehe [Überwachen Sie Amazon Data Firehose mit Metriken CloudWatch](monitoring-with-cloudwatch-metrics.md).
Wenn Sie die Sicherung für alle Ereignisse oder alle Dokumente aktivieren, sollten Sie zwei verschiedene Datenaktualitätsmetriken überwachen: eine für das Hauptziel und eine für die Sicherung.
Wenn die Datenaktualisierungsmetrik nicht ausgegeben wird, bedeutet dies, dass für den Firehose-Stream keine aktive Bereitstellung erfolgt. Dies geschieht, wenn die Datenbereitstellung vollständig blockiert wurde oder keine Daten eingehen.
Wenn die Datenaktualitätsmetrik kontinuierlich ansteigt, bedeutet dies, dass die Daten immer stärker veralten. Dies kann aus einem der folgenden Gründe geschehen.
+ Das Ziel kann mit der Bereitstellungsrate nicht Schritt halten. Wenn Firehose aufgrund des hohen Datenverkehrs auf vorübergehende Fehler stößt, kann es sein, dass die Lieferung in Verzug gerät. Dies kann für andere Ziele als Amazon S3 passieren (es kann für OpenSearch Service, Amazon Redshift oder Splunk passieren). Stellen Sie sicher, dass das Ziel über genügend Kapazität verfügt, um den eingehenden Datenverkehr zu verarbeiten.
+ Das Ziel ist langsam. Die Datenzustellung könnte ins Hintertreffen geraten, wenn Firehose auf eine hohe Latenz stößt. Überwachen Sie die Latenzmetrik des Ziels.
+ Die Lambda-Funktion ist langsam. Dies kann zu einer Datenübermittlungsrate führen, die unter der Datenaufnahmerate für den Firehose-Stream liegt. Verbessern Sie die Effizienz der Lambda-Funktion (wenn möglich). Wenn die Funktion beispielsweise Netzwerk-I/O-Operationen ausführt, verwenden Sie mehrere Threads oder asynchrone I/O-Operationen, um die parallele Ausführung zu verbessern. Erwägen Sie außerdem, die Größe des Speichers für die Lambda-Funktion zu erhöhen, damit die CPU-Zuweisung entsprechend erhöht werden kann. Dies kann zu schnelleren Lambda-Aufrufen führen. Informationen zur Konfiguration von Lambda-Funktionen finden Sie unter [Konfiguration von AWS Lambda-Funktionen](https://docs.aws.amazon.com/lambda/latest/dg/resource-model.html).
+ Es treten Fehler bei der Datenbereitstellung auf. Informationen zur Fehlerüberwachung mithilfe von Amazon CloudWatch Logs finden Sie unter[Überwachen Sie Amazon Data Firehose mithilfe von Protokollen CloudWatch](monitoring-with-cloudwatch-logs.md).
+ Wenn die Datenquelle des Firehose-Streams ein Kinesis-Datenstream ist, kann es zu einer Drosselung kommen. Prüfen Sie die Metriken `ThrottledGetRecords`, `ThrottledGetShardIterator` und `ThrottledDescribeStream`. Wenn an den Kinesis-Daten-Stream mehrere Konsumenten angefügt sind, müssen Sie Folgendes beachten:
+ Wenn die Metriken `ThrottledGetRecords` und `ThrottledGetShardIterator` hohe Werte aufweisen, sollten Sie die Anzahl der für den Daten-Stream bereitgestellten Shards erhöhen.
+ Wenn der Wert hoch `ThrottledDescribeStream` ist, empfehlen wir Ihnen, die `kinesis:listshards` Berechtigung zu der in konfigurierten Rolle hinzuzufügen. [KinesisStreamSourceConfiguration](https://docs.aws.amazon.com/firehose/latest/APIReference/API_CreateDeliveryStream.html#Firehose-CreateDeliveryStream-request-KinesisStreamSourceConfiguration)
+ Hinweise auf erschöpfte BufferingHints für das Ziel. Dies könnte die Anzahl der Hin- und Rückfahrten erhöhen, die Firehose zum Zielort unternehmen muss, was dazu führen könnte, dass die Lieferung ins Hintertreffen gerät. Erwägen Sie, den Wert für BufferingHints zu erhöhen. Weitere Informationen finden Sie unter [BufferingHints](https://docs.aws.amazon.com/firehose/latest/APIReference/API_BufferingHints.html).
+ Eine hohe Anzahl Wiederholungsversuche kann dazu führen, dass die Bereitstellung zurückfällt, wenn die Fehler häufig auftreten. Erwägen Sie, den Wiederholungszeitraum zu verkürzen. Überwachen Sie außerdem die Fehler und versuchen Sie, deren Anzahl zu reduzieren. Informationen zur Fehlerüberwachung mithilfe von Amazon CloudWatch Logs finden Sie unter[Überwachen Sie Amazon Data Firehose mithilfe von Protokollen CloudWatch](monitoring-with-cloudwatch-logs.md).
+ Wenn das Ziel Splunk und `DeliveryToSplunk.DataFreshness` hoch ist, `DeliveryToSplunk.Success` jedoch gute Werte zeigt, ist der Splunk-Cluster möglicherweise ausgelastet. Befreien Sie den Splunk-Cluster von Belastungen, wenn möglich. Wenden Sie sich alternativ an den AWS Support und fordern Sie eine Erhöhung der Anzahl der Kanäle an, die Firehose für die Kommunikation mit dem Splunk-Cluster verwendet.
## Die Konvertierung des Datensatzformats in Apache Parquet schlägt fehl
Dies passiert, wenn Sie DynamoDB-Daten, die den `Set` Typ enthalten, über Lambda in einen Firehose-Stream streamen und das Datensatzformat mithilfe von in Apache Parquet AWS Glue Data Catalog konvertieren.
Wenn der AWS Glue Crawler die in DynamoDB festgelegten Datentypen (`StringSet``NumberSet`, und`BinarySet`) indexiert, speichert er sie im Datenkatalog als `SET``SET`, bzw.. `SET` Damit Firehose die Datensätze in das Apache Parquet-Format konvertieren kann, sind jedoch Apache Hive-Datentypen erforderlich. Da es sich bei den festgelegten Typen um keine gültigen Apache Hive-Datentypen handelt, schlägt die Konvertierung fehl. Damit die Konvertierung funktioniert, aktualisieren Sie den Datenkatalog mit Apache Hive-Datentypen. Sie können dies tun, indem Sie im Datenkatalog `set` in `array` ändern.
**Um einen oder mehrere Datentypen `array` in einem AWS Glue Datenkatalog von `set` zu zu ändern**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die AWS Glue Konsole unter [https://console.aws.amazon.com/glue/](https://console.aws.amazon.com/glue/).
1. Wählen Sie im linken Bereich unter der Überschrift **Data catalog (Datenkatalog)** die Option **Tables (Tabellen)**.
1. Wählen Sie in der Liste der Tabellen den Namen der Tabelle aus, in der Sie mindestens einen Datentyp ändern müssen. Dadurch gelangen Sie zur Seite mit den Details für die Tabelle.
1. Wählen Sie in der oberen rechten Ecke der Detailseite die Schaltfläche **Schema bearbeiten**
1. Wählen Sie in der Spalte **Data type (Datentyp)** den ersten `set`-Datentyp aus.
1. Ändern Sie in der Dropdownliste **Column type (Spaltentyp)** den Typ von `set` in `array`.
1. Geben Sie in das **ArraySchema**Feld `array``array`, oder ein`array`, je nachdem, welcher Datentyp für Ihr Szenario geeignet ist.
1. Wählen Sie **Aktualisieren** aus.
1. Wiederholen Sie die vorherigen Schritte, um andere `set`-Typen in `array`-Typen zu konvertieren.
1. Wählen Sie **Speichern**.
## Fehlende Felder für transformiertes Objekt für Lambda
Wenn Sie die Lambda-Datentransformation verwenden, um JSON-Daten in ein Parquet-Objekt zu ändern, fehlen nach der Transformation möglicherweise einige Felder. Dies passiert, wenn Ihr JSON-Objekt Großbuchstaben enthält und die Berücksichtigung von Groß- und Kleinschreibung auf `false` eingestellt ist. Dies kann zu einer Nichtübereinstimmung der JSON-Schlüssel nach der Datentransformation führen, wodurch Daten im resultierenden Parquet-Objekt im s3-Bucket fehlen.
Um dieses Problem zu beheben, stellen Sie sicher, dass die Schlauchkonfiguration auf `deserializationOption: case.insensitive` eingestellt ist, `true` sodass die JSON-Schlüssel nach der Transformation übereinstimmen.
# Fehlerbehebung für Amazon S3
Überprüfen Sie Folgendes, wenn Daten nicht an Ihren Amazon Simple Storage Service (Amazon S3)-Bucket geliefert werden.
+ Überprüfen Sie Firehose `IncomingBytes` und die `IncomingRecords` Metriken, um sicherzustellen, dass Daten erfolgreich an Ihren Firehose-Stream gesendet wurden. Weitere Informationen finden Sie unter [Überwachen Sie Amazon Data Firehose mit Metriken CloudWatch](monitoring-with-cloudwatch-metrics.md).
+ Wenn die Datentransformation mit Lambda aktiviert ist, überprüfen Sie die `ExecuteProcessingSuccess` Firehose-Metrik, um sicherzustellen, dass Firehose versucht hat, Ihre Lambda-Funktion aufzurufen. Weitere Informationen finden Sie unter [Überwachen Sie Amazon Data Firehose mit Metriken CloudWatch](monitoring-with-cloudwatch-metrics.md).
+ Überprüfen Sie die `DeliveryToS3.Success` Firehose-Metrik, um sicherzustellen, dass Firehose versucht hat, Daten in Ihren Amazon S3 S3-Bucket zu laden. Weitere Informationen finden Sie unter [Überwachen Sie Amazon Data Firehose mit Metriken CloudWatch](monitoring-with-cloudwatch-metrics.md).
+ Aktivieren Sie die Fehlerprotokollierung, falls noch nicht geschehen, und überprüfen Sie die Fehlerprotokolle auf Bereitstellungsfehler. Weitere Informationen finden Sie unter [Überwachen Sie Amazon Data Firehose mithilfe von Protokollen CloudWatch](monitoring-with-cloudwatch-logs.md).
+ Wenn Sie im Protokoll eine Fehlermeldung sehen, die *besagt, dass Firehose InternalServerError beim Aufrufen des Amazon S3 S3-Dienstes aufgetreten ist. Der Vorgang wird erneut versucht. Wenn der Fehler weiterhin besteht, wenden Sie sich bitte an S3, um eine Lösung zu finden.“* , dies könnte auf den deutlichen Anstieg der Anforderungsraten auf einer einzelnen Partition in S3 zurückzuführen sein. Sie können die Entwurfsmuster für S3-Präfixe optimieren, um das Problem zu beheben. Weitere Informationen finden Sie unter [Bewährte Entwurfsmuster: Optimierung der Amazon S3 S3-Leistung](https://docs.aws.amazon.com/AmazonS3/latest/userguide/optimizing-performance.html). Wenn das Problem dadurch nicht behoben wird, wenden Sie sich an den AWS Support, um weitere Unterstützung zu erhalten.
+ Stellen Sie sicher, dass der Amazon S3 S3-Bucket, der in Ihrem Firehose-Stream angegeben ist, noch existiert.
+ Wenn die Datentransformation mit Lambda aktiviert ist, stellen Sie sicher, dass die Lambda-Funktion, die in Ihrem Firehose-Stream angegeben ist, noch vorhanden ist.
+ Stellen Sie sicher, dass die in Ihrem Firehose-Stream angegebene IAM-Rolle Zugriff auf Ihren S3-Bucket und Ihre Lambda-Funktion hat (sofern die Datentransformation aktiviert ist). Stellen Sie außerdem sicher, dass die IAM-Rolle Zugriff auf die CloudWatch Protokollgruppe und die Protokollstreams hat, um Fehlerprotokolle zu überprüfen. Weitere Informationen finden Sie unter [Firehose Zugriff auf ein Amazon S3 S3-Ziel gewähren](controlling-access.md#using-iam-s3).
+ Wenn Sie die Datentransformation verwenden, stellen Sie sicher, dass Ihre Lambda-Funktion keine Antworten zurückgibt, deren Nutzlast 6 MB überschreitet. Weitere Informationen finden Sie unter [Amazon Data FirehoseData Transformation](data-transformation.md).
# Fehlerbehebung für Amazon Redshift
Überprüfen Sie Folgendes, wenn Daten an Ihren bereitgestellten Amazon-Redshift-Cluster oder Ihre Arbeitsgruppe von Amazon Redshift Serverless nicht übermittelt werden.
Daten werden vor dem Laden in Amazon Redshift an Ihren S3-Bucket übermittelt. Wenn die Daten nicht an Ihren S3-Bucket gesendet wurden, vgl. [Fehlerbehebung für Amazon S3](data-not-delivered-to-s3.md).
+ Überprüfen Sie die `DeliveryToRedshift.Success` Firehose-Metrik, um sicherzustellen, dass Firehose versucht hat, Daten aus Ihrem S3-Bucket in den von Amazon Redshift bereitgestellten Cluster oder die Amazon Redshift Serverless-Arbeitsgruppe zu kopieren. Weitere Informationen finden Sie unter [Überwachen Sie Amazon Data Firehose mit Metriken CloudWatch](monitoring-with-cloudwatch-metrics.md).
+ Aktivieren Sie die Fehlerprotokollierung, falls noch nicht geschehen, und überprüfen Sie die Fehlerprotokolle auf Bereitstellungsfehler. Weitere Informationen finden Sie unter [Überwachen Sie Amazon Data Firehose mithilfe von Protokollen CloudWatch](monitoring-with-cloudwatch-logs.md).
+ Sehen Sie in der Amazon Redshift `STL_CONNECTION_LOG` Redshift-Tabelle nach, ob Firehose erfolgreiche Verbindungen herstellen kann. In dieser Tabelle sehen Sie die Verbindungen und ihre Status auf der Grundlage eines Benutzernamens. Weitere Informationen finden Sie unter [https://docs.aws.amazon.com/redshift/latest/dg/r_STL_CONNECTION_LOG.html](https://docs.aws.amazon.com/redshift/latest/dg/r_STL_CONNECTION_LOG.html) im *Leitfaden für Datenbankentwickler für Amazon Redshift*.
+ Wenn die vorige Prüfung zeigt, dass Verbindungen eingerichtet werden, prüfen Sie die `STL_LOAD_ERRORS`-Tabelle von Amazon Redshift, um die Ursache für den Fehler beim COPY-Befehl festzustellen. Weitere Informationen finden Sie unter [https://docs.aws.amazon.com/redshift/latest/dg/r_STL_LOAD_ERRORS.html](https://docs.aws.amazon.com/redshift/latest/dg/r_STL_LOAD_ERRORS.html) im *Leitfaden für Datenbankentwickler für Amazon Redshift*.
+ Stellen Sie sicher, dass die Amazon Redshift Redshift-Konfiguration in Ihrem Firehose-Stream korrekt und gültig ist.
+ Stellen Sie sicher, dass die in Ihrem Firehose-Stream angegebene IAM-Rolle auf den S3-Bucket zugreifen kann, aus dem Amazon Redshift Daten kopiert, sowie auf die Lambda-Funktion für die Datentransformation (sofern die Datentransformation aktiviert ist). Stellen Sie außerdem sicher, dass die IAM-Rolle Zugriff auf die CloudWatch Protokollgruppe und die Protokollstreams hat, um Fehlerprotokolle zu überprüfen. Weitere Informationen finden Sie unter [Firehose Zugriff auf ein Amazon Redshift Redshift-Ziel gewähren](controlling-access.md#using-iam-rs).
+ Wenn sich Ihr von Amazon Redshift bereitgestellter Cluster oder Ihre Amazon Redshift Serverless-Arbeitsgruppe in einer Virtual Private Cloud (VPC) befindet, stellen Sie sicher, dass der Cluster den Zugriff über Firehose-IP-Adressen ermöglicht. Weitere Informationen finden Sie unter [Firehose Zugriff auf ein Amazon Redshift Redshift-Ziel gewähren](controlling-access.md#using-iam-rs).
+ Stellen Sie sicher, dass der von Amazon Redshift bereitgestellte Cluster oder die Arbeitsgruppe von Amazon Redshift Serverless öffentlich verfügbar ist.
+ Wenn Sie die Datentransformation verwenden, stellen Sie sicher, dass Ihre Lambda-Funktion keine Antworten zurückgibt, deren Nutzlast 6 MB überschreitet. Weitere Informationen finden Sie unter [Amazon Data FirehoseData Transformation](data-transformation.md).
# Problembehebung bei Amazon OpenSearch Service
Überprüfen Sie Folgendes, wenn Daten nicht an Ihre OpenSearch Service-Domain geliefert werden.
Daten können gleichzeitig in Ihrem Amazon-S3-Bucket gesichert werden. Wenn die Daten nicht an Ihren S3-Bucket gesendet wurden, vgl. [Fehlerbehebung für Amazon S3](data-not-delivered-to-s3.md).
+ Überprüfen Sie Firehose `IncomingBytes` und die `IncomingRecords` Metriken, um sicherzustellen, dass Daten erfolgreich an Ihren Firehose-Stream gesendet wurden. Weitere Informationen finden Sie unter [Überwachen Sie Amazon Data Firehose mit Metriken CloudWatch](monitoring-with-cloudwatch-metrics.md).
+ Wenn die Datentransformation mit Lambda aktiviert ist, überprüfen Sie die `ExecuteProcessingSuccess` Firehose-Metrik, um sicherzustellen, dass Firehose versucht hat, Ihre Lambda-Funktion aufzurufen. Weitere Informationen finden Sie unter [Überwachen Sie Amazon Data Firehose mit Metriken CloudWatch](monitoring-with-cloudwatch-metrics.md).
+ Überprüfen Sie die `DeliveryToAmazonOpenSearchService.Success` Firehose-Metrik, um sicherzustellen, dass Firehose versucht hat, Daten für den OpenSearch Service-Cluster zu indizieren. Weitere Informationen finden Sie unter [Überwachen Sie Amazon Data Firehose mit Metriken CloudWatch](monitoring-with-cloudwatch-metrics.md).
+ Aktivieren Sie die Fehlerprotokollierung, falls noch nicht geschehen, und überprüfen Sie die Fehlerprotokolle auf Bereitstellungsfehler. Weitere Informationen finden Sie unter [Überwachen Sie Amazon Data Firehose mithilfe von Protokollen CloudWatch](monitoring-with-cloudwatch-logs.md).
+ Stellen Sie sicher, dass die OpenSearch Dienstkonfiguration in Ihrem Firehose-Stream korrekt und gültig ist.
+ Wenn die Datentransformation mit Lambda aktiviert ist, stellen Sie sicher, dass die Lambda-Funktion, die in Ihrem Firehose-Stream angegeben ist, noch vorhanden ist. Stellen Sie außerdem sicher, dass die IAM-Rolle Zugriff auf die CloudWatch Protokollgruppe und die Protokollstreams hat, um Fehlerprotokolle zu überprüfen. Weitere Informationen finden Sie unter [Grant FirehoseAccess to a Public OpenSearch Service Destination](https://docs.aws.amazon.com/firehose/latest/dev/controlling-access.html#using-iam-es).
+ Stellen Sie sicher, dass die in Ihrem Firehose-Stream angegebene IAM-Rolle auf Ihren OpenSearch Service-Cluster, Ihren S3-Backup-Bucket und die Lambda-Funktion zugreifen kann (sofern die Datentransformation aktiviert ist). Stellen Sie außerdem sicher, dass die IAM-Rolle Zugriff auf die CloudWatch Protokollgruppe und die Protokollstreams hat, um Fehlerprotokolle zu überprüfen. Weitere Informationen finden Sie unter [Firehose Zugang zu einem Ziel des öffentlichen OpenSearch Dienstes gewähren](controlling-access.md#using-iam-es).
+ Wenn Sie die Datentransformation verwenden, stellen Sie sicher, dass Ihre Lambda-Funktion keine Antworten zurückgibt, deren Nutzlast 6 MB überschreitet. Weitere Informationen finden Sie unter [Amazon Data FirehoseData Transformation](data-transformation.md).
+ Amazon Data Firehose unterstützt derzeit nicht die Übermittlung von CloudWatch Protokollen an das Amazon OpenSearch Service-Ziel, da Amazon mehrere Protokollereignisse zu einem Firehose-Datensatz CloudWatch zusammenfasst und Amazon OpenSearch Service nicht mehrere Protokollereignisse in einem Datensatz akzeptieren kann. Als Alternative können Sie erwägen, den [Abonnementfilter für Amazon OpenSearch Service in CloudWatch Logs zu verwenden](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_OpenSearch_Stream.html).
# Fehlerbehebung bei Splunk
Prüfen Sie die folgenden Punkte, wenn die Daten nicht an Ihren Splunk endpoint übergeben wurden.
+ Wenn sich Ihre Splunk-Plattform in einer VPC befindet, stellen Sie sicher, dass Firehose darauf zugreifen kann. Weitere Informationen finden Sie unter [Zugreifen auf Splunk in VPC](controlling-access.md#using-iam-splunk-vpc).
+ Wenn Sie einen Load AWS Balancer verwenden, stellen Sie sicher, dass es sich um einen Classic Load Balancer oder einen Application Load Balancer handelt. Aktivieren Sie außerdem dauerbasierte Sticky-Sitzungen mit deaktiviertem Cookie-Ablauf für Classic Load Balancer und mit maximaler Ablaufzeit (7 Tage) für Application Load Balancer. [Informationen dazu finden Sie unter Duration-Based Session Stickiness für [Classic Load Balancer oder einen Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-sticky-sessions.html#enable-sticky-sessions-duration).](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/sticky-sessions.html)
+ Überprüfen Sie die Splunk-Plattformanforderungen. Das Splunk-Add-on für Firehose erfordert Splunk-Plattformversion 6.6.X oder höher. Weitere Informationen finden Sie unter [Splunk-Add-On für Amazon Kinesis Firehose](http://docs.splunk.com/Documentation/AddOns/released/Firehose/Hardwareandsoftwarerequirements).
+ Wenn Sie einen Proxy (Elastic Load Balancing oder ein anderer) zwischen Firehose und dem HTTP Event Collector (HEC) -Knoten haben, aktivieren Sie Sticky Sessions, um HEC-Bestätigungen () zu unterstützen. ACKs
+ Stellen Sie sicher, dass Sie ein gültiges HEC-Token verwenden.
+ Stellen Sie sicher, dass der HEC-Token aktiviert ist.
+ Überprüfen Sie, ob die Daten, die Sie an Splunk senden, ordnungsgemäß formatiert sind. Weitere Informationen finden Sie unter [Formatieren von Ereignissen für HTTP-Ereigniserfassung](http://docs.splunk.com/Documentation/Splunk/7.0.3/Data/FormateventsforHTTPEventCollector).
+ Stellen Sie sicher, dass der HEC-Token und das Eingabeereignis mit einem gültigen Index konfiguriert sind.
+ Wenn ein Upload an Splunk aufgrund eines Server-Fehlers im HEC-Knoten fehlschlägt, wird die Anforderung automatisch wiederholt. Wenn alle Wiederholungen fehlschlagen, werden die Daten in Amazon S3 gesichert. Überprüfen Sie, ob Ihre Daten in Amazon S3 angezeigt werden, was auf eine solche Fehlfunktion hinweist.
+ Stellen Sie sicher, dass die Indexbestätigung auf Ihrem HEC-Token aktiviert ist.
+ Erhöhen Sie den Wert von `HECAcknowledgmentTimeoutInSeconds` in der Splunk-Zielkonfiguration Ihres Firehose-Streams.
+ Erhöhen Sie den Wert von `DurationInSeconds` under `RetryOptions` in der Splunk-Zielkonfiguration Ihres Firehose-Streams.
+ Überprüfen Sie Ihre HEC-Lizenzen. Die Aktivierung des Health Checks ist eine Grundvoraussetzung für die Datenübertragung zu Splunk.
+ Wenn Sie die Datentransformation verwenden, stellen Sie sicher, dass Ihre Lambda-Funktion keine Antworten zurückgibt, deren Nutzlast 6 MB überschreitet. Weitere Informationen finden Sie unter [Amazon Data Firehose Data Transformation](data-transformation.md#data-transformation.title).
+ Stellen Sie sicher, dass der Splunk-Parameter namens `ackIdleCleanup` auf `true` festgelegt ist. Standardmäßig lautet er "false". Um diesen Parameter auf `true` festzulegen, gehen Sie wie folgt vor:
+ Senden Sie eine Anfrage für eine [verwaltete Splunk Cloud-Bereitstellung](http://docs.splunk.com/Documentation/AddOns/released/Firehose/RequestFirehose) über das Splunk-Support-Portal. Bitten Sie den Splunk-Support in diesem Fall, die HTTP-Ereigniserfassung zu aktivieren, `ackIdleCleanup` in `inputs.conf` auf `true` festzulegen und einen Load Balancer, der mit diesem Add-On verwendet wird, zu erstellen oder zu ändern.
+ Für eine [verteilte Splunk-Enterprise-Bereitstellung](http://docs.splunk.com/Documentation/AddOns/released/Firehose/ConfigureHECdistributed) legen Sie für den Parameter `ackIdleCleanup` in der Datei `inputs.conf` den Wert „true“ fest. Für \$1nix-Benutzer befindet sich die Datei unter `$SPLUNK_HOME/etc/apps/splunk_httpinput/local/`. Für Windows-Benutzer befindet sie sich unter `%SPLUNK_HOME%\etc\apps\splunk_httpinput\local\`.
+ Für eine [Single-Instance-Splunk-Enterprise-Bereitstellung](http://docs.splunk.com/Documentation/AddOns/released/Firehose/ConfigureHECsingle) legen Sie für den Parameter `ackIdleCleanup` in der Datei `inputs.conf` den Wert „`true`“ fest. Für \$1nix-Benutzer befindet sich die Datei unter `$SPLUNK_HOME/etc/apps/splunk_httpinput/local/`. Für Windows-Benutzer befindet sie sich unter `%SPLUNK_HOME%\etc\apps\splunk_httpinput\local\`.
+ Stellen Sie sicher, dass die in Ihrem Firehose-Stream angegebene IAM-Rolle auf den S3-Backup-Bucket und die Lambda-Funktion für die Datentransformation zugreifen kann (sofern die Datentransformation aktiviert ist). Stellen Sie außerdem sicher, dass die IAM-Rolle Zugriff auf die Protokollgruppe und die Protokollstreams hat, um CloudWatch Fehlerprotokolle zu überprüfen. Weitere Informationen finden Sie unter [Grant FirehoseAccess to a Splunk Destination](https://docs.aws.amazon.com/firehose/latest/dev/controlling-access.html#using-iam-splunk).
+ [Gehen Sie wie in der Splunk-Dokumentation beschrieben vor, um die Daten, die an den S3-Fehler-Bucket (S3-Backup) übermittelt wurden, wieder an Splunk weiterzuleiten.](https://www.splunk.com/en_us/blog/tips-and-tricks/aws-technical-add-on-simplifying-error-data-re-ingestion.html)
+ Weitere Informationen finden Sie unter [Fehlersuche für das Splunk Add-on für Amazon Kinesis Firehose](http://docs.splunk.com/Documentation/AddOns/released/Firehose/Troubleshoot).
# Fehlerbehebung bei Snowflake
In diesem Abschnitt werden allgemeine Schritte zur Fehlerbehebung bei der Verwendung von Snowflake als Ziel beschrieben
## Die Firehose-Stream-Erstellung schlägt fehl
Wenn die Firehose-Stream-Erstellung für einen Stream fehlschlägt, der Daten an einen PrivateLink -fähigen Snowflake-Cluster liefert, bedeutet dies, dass die VPCE-ID für Firehose nicht erreichbar ist. Dies kann einen der folgenden Gründe haben:
+ Falsche VPCE-ID. Vergewissern Sie sich, dass keine Tippfehler vorliegen.
+ Firehose unterstützt URLs Snowflake ohne Region in der Vorschauversion nicht. Geben Sie die URL mit dem Snowflake Account Locator an. Weitere Informationen finden Sie in der [Snowflake-Dokumentation](https://docs.snowflake.com/en/user-guide/admin-account-identifier#format-2-legacy-account-locator-in-a-region).
+ Vergewissern Sie sich, dass der Firehose-Stream in derselben AWS Region wie die Snowflake-Region erstellt wurde.
+ Wenn das Problem weiterhin besteht, wenden Sie sich an den Support. AWS
### Fehler bei der Zustellung
Überprüfen Sie Folgendes, wenn Daten nicht an Ihre Snowflake-Tabelle übermittelt werden. Daten, die bei der Snowflake-Zustellung fehlgeschlagen sind, werden zusammen mit einem Fehlercode und einer Fehlermeldung, die der Payload entsprechen, an den S3-Fehler-Bucket übermittelt. Im Folgenden sind einige häufig auftretende Fehlerszenarien aufgeführt. Die gesamte Liste der Fehlercodes finden Sie unter[Fehler bei der Lieferung von Snowflake-Daten](monitoring-with-cloudwatch-logs.md#monitoring-snowflake-errors).
+ **Fehlercode: Snowflake. DefaultRoleMissing**: Zeigt an, dass die Snowflake-Rolle beim Erstellen des Firehose-Streams nicht konfiguriert wurde. Wenn die Snowflake-Rolle nicht konfiguriert ist, stellen Sie sicher, dass Sie eine Standardrolle für den angegebenen Snowflake-Benutzer festlegen.
+ **Fehlercode: Snowflake. ExtraColumns**: Zeigt an, dass das Einfügen in Snowflake aufgrund zusätzlicher Spalten in der Eingabe-Payload abgelehnt wurde. Spalten, die in der Tabelle nicht vorhanden sind, sollten nicht angegeben werden. Beachten Sie, dass bei Snowflake-Spaltennamen Groß- und Kleinschreibung beachtet wird. Wenn die Lieferung mit diesem Fehler fehlschlägt, obwohl eine Spalte in der Tabelle vorhanden ist, stellen Sie sicher, dass die Groß-/Kleinschreibung des Spaltennamens in der Eingabe-Payload mit dem in der Tabellendefinition deklarierten Spaltennamen übereinstimmt.
+ **Fehlercode: Snowflake. MissingColumns**: Zeigt an, dass das Einfügen in Snowflake aufgrund fehlender Spalten in der Eingabe-Payload abgelehnt wurde. Stellen Sie sicher, dass Werte für alle Spalten angegeben sind, die keine NULL-Werte zulassen.
+ **Fehlercode: Snowflake. InvalidInput**: Dies kann passieren, wenn Firehose die bereitgestellte Eingabe-Payload nicht in ein gültiges JSON-Format parsen konnte. Stellen Sie sicher, dass die JSON-Nutzlast gut geformt ist und keine zusätzlichen doppelten Anführungszeichen, Anführungszeichen, Escape-Zeichen usw. enthält. Derzeit unterstützt Firehose nur ein einzelnes JSON-Element als Datensatznutzlast, JSON-Arrays werden nicht unterstützt.
+ **Fehlercode: Snowflake. InvalidValue**: Zeigt an, dass die Lieferung aufgrund eines falschen Datentyps in der Eingabe-Payload fehlgeschlagen ist. Stellen Sie sicher, dass die in der Eingabe-Payload angegebenen JSON-Werte dem in der Snowflake-Tabellendefinition deklarierten Datentyp entsprechen.
+ **Fehlercode: Snowflake. InvalidTableType**: Zeigt an, dass der im Firehose-Stream konfigurierte Tabellentyp nicht unterstützt wird. Informationen zu den unterstützten Tabellen, Spalten und Datentypen finden Sie in den [Einschränkungen unter Einschränkungen](https://docs.snowflake.com/en/user-guide/data-load-snowpipe-streaming-overview#limitations)) von Snowpipe-Streaming.
**Anmerkung**
Wenn die Tabellendefinition oder die Rollenberechtigungen an Ihrem Snowflake-Ziel nach der Erstellung des Firehose-Streams geändert werden, kann es aus irgendeinem Grund mehrere Minuten dauern, bis Firehose diese Änderungen erkennt. Wenn Sie aus diesem Grund Lieferfehler feststellen, versuchen Sie, den Firehose-Stream zu löschen und neu zu erstellen.
# Fehlerbehebung bei der Erreichbarkeit von Firehose-Endpunkten
Wenn die Firehose auf ein Timeout stößt, führen Sie die folgenden Schritte aus, um die Erreichbarkeit der Endpunkte zu testen:
+ Prüfen Sie, ob API-Anfragen von einem Host in einer VPC gestellt werden. Der gesamte Datenverkehr von einer VPC erfordert die Einrichtung eines Firehose-VPC-Endpunkts. Weitere Informationen finden Sie unter [Firehose verwenden mit AWS PrivateLink](https://docs.aws.amazon.com/firehose/latest/dev/vpc.html).
+ Wenn der Verkehr von einem öffentlichen Netzwerk oder einer VPC kommt, bei der der Firehose-VPC-Endpunkt in einem bestimmten Subnetz eingerichtet ist, führen Sie die folgenden Befehle vom Host aus, um die Netzwerkkonnektivität zu überprüfen. Den Firehose-Endpunkt finden Sie unter [Firehose-Endpunkte und Kontingente](https://docs.aws.amazon.com/general/latest/gr/fh.html).
+ Verwenden Sie Tools wie **traceroute** oder**tcping**, um zu überprüfen, ob die Netzwerkkonfiguration korrekt ist. Wenn das fehlschlägt, überprüfen Sie Ihre Netzwerkeinstellungen:
Beispiel:
```
traceroute firehose.us-east-2.amazonaws.com
```
oder
```
tcping firehose.us-east-2.amazonaws.com 443
```
+ Wenn es den Anschein hat, dass die Netzwerkeinstellungen korrekt sind und der folgende Befehl fehlschlägt, überprüfen Sie, ob sich die [Amazon CA (Certficate Authority)](https://docs.aws.amazon.com//acm/latest/userguide/acm-overview.html) in der Vertrauenskette befindet.
Beispiel:
```
curl firehose.us-east-2.amazonaws.com
```
Wenn die obigen Befehle erfolgreich sind, versuchen Sie es erneut mit der API, um zu sehen, ob von der API eine Antwort zurückgegeben wurde.
# Fehlerbehebung bei HTTP-Endpunkten
In diesem Abschnitt werden allgemeine Schritte zur Fehlerbehebung beschrieben, wenn Amazon Data Firehose Daten an generische HTTP-Endpunktziele und Partnerziele wie Datadog, Dynatrace,, MongoDB, New Relic LogicMonitor, Splunk oder Sumo Logic übermittelt. Für die Zwecke dieses Abschnitts werden alle zutreffenden Ziele als HTTP-Endpunkte bezeichnet. Stellen Sie sicher, dass die in Ihrem Firehose-Stream angegebene IAM-Rolle auf den S3-Backup-Bucket und die Lambda-Funktion für die Datentransformation zugreifen kann (sofern die Datentransformation aktiviert ist). Stellen Sie außerdem sicher, dass die IAM-Rolle Zugriff auf die CloudWatch Protokollgruppe und die Protokollstreams hat, um Fehlerprotokolle zu überprüfen. Weitere Informationen finden Sie unter [Firehose-Zugriff auf ein HTTP-Endpunktziel gewähren](https://docs.aws.amazon.com/firehose/latest/dev/controlling-access.html#using-iam-http).
**Anmerkung**
Die Informationen in diesem Abschnitt gelten nicht für die folgenden Ziele: Splunk, OpenSearch Service, S3 und Redshift.
## CloudWatch Logs
Es wird dringend empfohlen, [CloudWatch Logging für](monitoring-with-cloudwatch-logs.md) zu aktivieren. Protokolle werden nur veröffentlicht, wenn bei der Lieferung an Ihr Ziel Fehler auftreten.
### Ausnahmen vom Zielort
**ErrorCode: HttpEndpoint.DestinationException**
```
{
"deliveryStreamARN": "arn:aws:firehose:us-east-1:123456789012:deliverystream/ronald-test",
"destination": "custom.firehose.endpoint.com...",
"deliveryStreamVersionId": 1,
"message": "The following response was received from the endpoint destination. 413: {\"requestId\": \"43b8e724-dbac-4510-adb7-ef211c6044b9\", \"timestamp\": 1598556019164, \"errorMessage\": \"Payload too large\"}",
"errorCode": "HttpEndpoint.DestinationException",
"processor": "arn:aws:lambda:us-east-1:379522611494:function:httpLambdaProcessing"
}
```
Zielausnahmen weisen darauf hin, dass Firehose in der Lage **ist**, eine Verbindung zu Ihrem Endpunkt herzustellen und eine HTTP-Anfrage zu stellen, aber **keinen** 200-Antwortcode erhalten hat. 2xx-Antworten, die nicht 200s sind, führen ebenfalls zu einer Zielausnahme. Amazon Data Firehose protokolliert den Antwortcode und eine gekürzte Antwortnutzlast, die vom konfigurierten Endpunkt empfangen wurde, in Logs. CloudWatch Da Amazon Data Firehose den Antwortcode und die Nutzdaten ohne Änderung oder Interpretation protokolliert, ist es Sache des Endpunkts, den genauen Grund anzugeben, warum er die HTTP-Lieferanforderung von Amazon Data Firehose abgelehnt hat. Im Folgenden sind die häufigsten Empfehlungen zur Problembehandlung für diese Ausnahmen:
+ **400**: Zeigt an, dass Sie aufgrund einer Fehlkonfiguration Ihrer Amazon Data Firehose eine fehlerhafte Anfrage senden. Stellen Sie sicher, dass Sie die richtige [URL](https://docs.aws.amazon.com/firehose/latest/APIReference/API_HttpEndpointConfiguration.html#Firehose-Type-HttpEndpointConfiguration-Url), die richtigen [allgemeinen Attribute](https://docs.aws.amazon.com/firehose/latest/APIReference/API_HttpEndpointRequestConfiguration.html#Firehose-Type-HttpEndpointRequestConfiguration-CommonAttributes), die [Inhaltskodierung](https://docs.aws.amazon.com/firehose/latest/APIReference/API_HttpEndpointRequestConfiguration.html#Firehose-Type-HttpEndpointRequestConfiguration-ContentEncoding), den [Zugriffsschlüssel](https://docs.aws.amazon.com/firehose/latest/APIReference/API_HttpEndpointConfiguration.html#Firehose-Type-HttpEndpointConfiguration-AccessKey) und die richtigen [Pufferhinweise](https://docs.aws.amazon.com/firehose/latest/APIReference/API_HttpEndpointDestinationConfiguration.html#Firehose-Type-HttpEndpointDestinationConfiguration-BufferingHints) für Ihr Ziel haben. Informationen zur erforderlichen Konfiguration finden Sie in der zielspezifischen Dokumentation.
+ **401**: Zeigt an, dass der Zugriffsschlüssel, den Sie für Ihren Firehose konfiguriert haben, falsch ist oder fehlt.
+ **403**: Zeigt an, dass der Zugriffsschlüssel, den Sie für Ihren Firehose-Stream konfiguriert haben, nicht berechtigt ist, Daten an den konfigurierten Endpunkt zu liefern.
+ **413**: Zeigt an, dass die Anforderungsnutzlast, die Amazon Data Firehose an den Endpunkt sendet, zu groß ist, als dass der Endpunkt sie verarbeiten könnte. Versuchen Sie, [den Pufferhinweis auf die empfohlene Größe](https://docs.aws.amazon.com/firehose/latest/APIReference/API_HttpEndpointBufferingHints.html#Firehose-Type-HttpEndpointBufferingHints-SizeInMBs) für Ihr Ziel zu reduzieren.
+ **429**: Zeigt an, dass Amazon Data Firehose Anfragen mit einer höheren Geschwindigkeit sendet, als das Ziel verarbeiten kann. Optimieren Sie Ihren Pufferhinweis, indem Sie Ihre Pufferzeit verlängern und damit Ihre Puffergröße and/or erhöhen (aber immer noch innerhalb der Grenzen Ihres Ziels).
+ **5xx**: Zeigt an, dass ein Problem mit dem Ziel vorliegt. Der Amazon Data Firehose-Service funktioniert immer noch einwandfrei.
**Wichtig**
Wichtig: Obwohl dies die allgemeinen Empfehlungen zur Fehlerbehebung sind, können für bestimmte Endpunkte unterschiedliche Gründe für die Bereitstellung der Antwortcodes vorliegen. Daher sollten die endpunktspezifischen Empfehlungen zuerst befolgt werden.
### Ungültige Antwort
**ErrorCode: HttpEndpoint.InvalidResponseFromDestination**
```
{
"deliveryStreamARN": "arn:aws:firehose:us-east-1:123456789012:deliverystream/ronald-test",
"destination": "custom.firehose.endpoint.com...",
"deliveryStreamVersionId": 1,
"message": "The response received from the specified endpoint is invalid. Contact the owner of the endpoint to resolve the issue. Response for request 2de9e8e9-7296-47b0-bea6-9f17b133d847 is not recognized as valid JSON or has unexpected fields. Raw response received: 200 {\"requestId\": null}",
"errorCode": "HttpEndpoint.InvalidResponseFromDestination",
"processor": "arn:aws:lambda:us-east-1:379522611494:function:httpLambdaProcessing"
}
```
Ausnahmen für ungültige Antworten weisen darauf hin, dass Amazon Data Firehose eine ungültige Antwort vom Endpunktziel erhalten hat. Die Antwort muss den [Antwortspezifikationen](httpdeliveryrequestresponse.md) entsprechen. Andernfalls betrachtet Amazon Data Firehose den Zustellungsversuch als Fehlschlag und übermittelt dieselben Daten erneut, bis die konfigurierte Wiederholungsdauer überschritten ist. Amazon Data Firehose behandelt Antworten, die nicht den Antwortspezifikationen entsprechen, als Fehlschläge, selbst wenn die Antwort den Status 200 hat. Wenn Sie einen Amazon Data Firehose-kompatiblen Endpunkt entwickeln, befolgen Sie die Antwortspezifikationen, um sicherzustellen, dass die Daten erfolgreich übermittelt werden.
Im Folgenden finden Sie einige der häufigsten Arten von ungültigen Antworten und deren Behebung:
+ **Ungültiges JSON oder unerwartete Felder**: Zeigt an, dass die Antwort nicht ordnungsgemäß als JSON deserialisiert werden kann oder unerwartete Felder enthält. Stellen Sie sicher, dass die Antwort nicht inhaltskodiert ist.
+ **Fehlt RequestId**: Zeigt an, dass die Antwort keine requestId enthält.
+ **RequestId stimmt nicht überein**: Zeigt an, dass die requestId in der Antwort nicht mit der ausgehenden requestId übereinstimmt.
+ **Fehlender Zeitstempel**: Zeigt an, dass die Antwort kein Zeitstempelfeld enthält. Das Zeitstempelfeld muss eine Zahl und keine Zeichenfolge sein.
+ **Fehlender Content-Type-Header**: Zeigt an, dass die Antwort keinen „content-type: application/json“-Header enthält. Es wird kein anderer Inhaltstyp akzeptiert.
**Wichtig**
[Wichtig: Amazon Data Firehose kann Daten nur an Endpunkte liefern, die den Anforderungen und Antworten von Firehose entsprechen.](httpdeliveryrequestresponse.md) Wenn Sie Ihr Ziel für einen Drittanbieter-Service konfigurieren, stellen Sie sicher, dass Sie den richtigen Amazon Data Firehose-kompatiblen Endpunkt verwenden, der sich wahrscheinlich vom öffentlichen Aufnahmeendpunkt unterscheidet. Zum Beispiel ist der Amazon Data Firehose-Endpunkt von Datadog, `https://aws-kinesis-http-intake.logs.datadoghq.com/` während es sein öffentlicher Endpunkt ist. `https://api.datadoghq.com/`
### Andere häufige Fehler
Zusätzliche Fehlercodes und Definitionen werden im Folgenden aufgelistet.
+ **Fehlercode:. HttpEndpoint RequestTimeout** - Zeigt an, dass die Antwort des Endpunkts länger als 3 Minuten gedauert hat. Wenn Sie der Besitzer des Ziels sind, verringern Sie die Antwortzeit des Zielendpunkts. Wenn Sie nicht der Eigentümer des Ziels sind, wenden Sie sich an den Eigentümer und fragen Sie, ob etwas getan werden kann, um die Antwortzeit zu verkürzen (d. h. den Pufferhinweis zu verringern, sodass weniger Daten pro Anfrage verarbeitet werden).
+ **Fehlercode: HttpEndpoint. ResponseTooLarge** - Zeigt an, dass die Antwort zu groß ist. Die Antwort muss weniger als 1 MiB einschließlich der Header betragen.
+ **Fehlercode: HttpEndpoint. ConnectionFailed** - Zeigt an, dass keine Verbindung mit dem konfigurierten Endpunkt hergestellt werden konnte. Dies kann auf einen Tippfehler in der konfigurierten URL zurückzuführen sein, der Endpunkt ist für Amazon Data Firehose nicht zugänglich oder es dauert zu lange, bis der Endpunkt auf die Verbindungsanfrage reagiert.
+ **Fehlercode:. HttpEndpoint ConnectionReset** - Zeigt an, dass eine Verbindung hergestellt, aber vom Endpunkt zurückgesetzt oder vorzeitig geschlossen wurde.
+ **Fehlercode:. HttpEndpoint SSLHandshake**Fehler — Zeigt an, dass ein SSL-Handshake mit dem konfigurierten Endpunkt nicht erfolgreich abgeschlossen werden konnte.
# Problembehandlung bei MSK As Source
In diesem Abschnitt werden allgemeine Schritte zur Fehlerbehebung bei der Verwendung von MSK As Source beschrieben
**Anmerkung**
Informationen zur Behebung von Problemen bei der Verarbeitung, Transformation oder S3-Bereitstellung finden Sie in den vorherigen Abschnitten
## Fehler bei der Schlaucherstellung
Überprüfen Sie Folgendes, wenn Ihr Schlauch mit MSK als Quelle nicht erstellt werden kann:
+ Stellen Sie sicher, dass sich der Quell-MSK-Cluster im Status Aktiv befindet.
+ Wenn Sie private Konnektivität verwenden, stellen Sie sicher, dass [Private Link auf dem Cluster aktiviert ist](https://docs.aws.amazon.com/msk/latest/developerguide/aws-access-mult-vpc.html).
Wenn Sie öffentliche Konnektivität verwenden, stellen Sie sicher, dass der [öffentliche Zugriff auf dem Cluster aktiviert ist](https://docs.aws.amazon.com/msk/latest/developerguide/public-access.html).
+ Wenn Sie private Konnektivität verwenden, stellen Sie sicher, dass Sie eine [ressourcenbasierte Richtlinie hinzufügen, die es Firehose ermöglicht, Private Links zu erstellen](controlling-access.md#access-to-msk). Siehe auch: [Kontoübergreifende MSK-Berechtigungen](https://docs.aws.amazon.com/msk/latest/developerguide/mvpc-cross-account-permissions.html).
+ Stellen Sie sicher, dass die Rolle in der Quellkonfiguration [berechtigt ist, Daten aus dem Thema des Clusters aufzunehmen](controlling-access.md#firehose-assume-role).
+ Stellen Sie sicher, dass Ihre VPC-Sicherheitsgruppen eingehenden Datenverkehr an den [Ports zulassen, die von den Bootstrap-Servern des Clusters verwendet werden](https://docs.aws.amazon.com/msk/latest/developerguide/port-info.html).
## Schlauch suspendiert
Prüfen Sie Folgendes, wenn sich Ihr Schlauch im Zustand SUSPENDIERT befindet
+ Stellen Sie sicher, dass sich der Quell-MSK-Cluster im Status Aktiv befindet.
+ Stellen Sie sicher, dass das Quellthema vorhanden ist. Falls das Thema gelöscht und neu erstellt wurde, müssen Sie auch den Firehose-Stream löschen und neu erstellen.
## Schlauch mit Gegendruck
Der Wert von DataReadFromSource .Backpressured ist 1, wenn jede Partition überschritten wird oder wenn BytesPerSecondLimit der normale Übertragungsfluss langsam ist oder gestoppt wird.
+ Wenn Sie darauf stoßen, überprüfen Sie BytesPerSecondLimit bitte die DataReadFromSource .Bytes-Metrik und fordern Sie eine Erhöhung des Limits an.
+ Überprüfen Sie die CloudWatch Protokolle, Zielmetriken, Datenumwandlungsmetriken und Metriken zur Formatkonvertierung, um die Engpässe zu identifizieren.
## Falsche Datenaktualität
Die Aktualität der Daten scheint falsch zu sein
+ Firehose berechnet die Datenaktualität anhand des Zeitstempels des verbrauchten Datensatzes. Um sicherzustellen, dass dieser Zeitstempel korrekt aufgezeichnet wird, wenn der Produzentendatensatz in den Broker-Protokollen von Kafka gespeichert wird, stellen Sie die Konfiguration des Zeitstempeltyps Kafka-Thema auf `message.timestamp.type=LogAppendTime`.
## Verbindungsprobleme mit dem MSK-Cluster
Im folgenden Verfahren wird erklärt, wie Sie die Konnektivität zu MSK-Clustern überprüfen können. Einzelheiten zur Einrichtung des Amazon MSK-Clients finden Sie unter [Erste Schritte mit Amazon MSK im Amazon](https://docs.aws.amazon.com/msk/latest/developerguide/getting-started.html) *Managed Streaming for Apache Kafka* Developer Guide.
**Um die Konnektivität zu MSK-Clustern zu überprüfen**
1. Erstellen Sie eine UNIX-basierte (vorzugsweise AL2) Amazon EC2 EC2-Instance. Wenn Sie auf Ihrem Cluster nur VPC-Konnektivität aktiviert haben, stellen Sie sicher, dass Ihre EC2-Instance in derselben VPC ausgeführt wird. Stellen Sie eine SSH-Verbindung zur Instance her, sobald sie verfügbar ist. Weitere Informationen finden Sie in [diesem Tutorial](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EC2_GetStarted.html) im *Amazon EC2 EC2-Benutzerhandbuch*.
1. Installieren Sie Java mithilfe des Yum-Paketmanagers, indem Sie den folgenden Befehl ausführen. Weitere Informationen finden Sie in den [Installationsanweisungen](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EC2_GetStarted.html) im Amazon Corretto 8-Benutzerhandbuch.
```
sudo yum install java-1.8.0
```
1. Installieren Sie den [AWS Client](https://aws.amazon.com/cli/), indem Sie den folgenden Befehl ausführen.
```
curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
unzip awscliv2.zip
sudo ./aws/install
```
1. Laden Sie die Version 2.6\$1 des Apache Kafka-Clients herunter, indem Sie den folgenden Befehl ausführen.
```
wget https://archive.apache.org/dist/kafka/2.6.2/kafka_2.12-2.6.2.tgz
tar -xzf kafka_2.12-2.6.2.tgz
```
1. Wechseln Sie zum Verzeichnis `kafka_2.12-2.6.2/libs` und führen Sie dann den folgenden Befehl aus, um die Amazon-MSK-IAM-JAR-Datei herunterzuladen.
```
wget https://github.com/aws/aws-msk-iam-auth/releases/download/v1.1.3/aws-msk-iam-auth-1.1.3-all.jar
```
1. Erstellen Sie die `client.properties` Datei im Kafka-Ordner bin.
1. `awsRoleArn`Ersetzen Sie es durch den Rollen-ARN, den Sie in Ihrer Firehose verwendet haben, `SourceConfiguration` und überprüfen Sie den Speicherort des Zertifikats. Erlauben Sie Ihrem AWS Client-Benutzer, die Rolle zu übernehmen. `awsRoleArn` AWS Der Client-Benutzer wird versuchen, die Rolle anzunehmen, die Sie hier angegeben haben.
```
[ec2-user@ip-xx-xx-xx-xx bin]$ cat client.properties
security.protocol=SASL_SSL
sasl.mechanism=AWS_MSK_IAM
sasl.jaas.config=software.amazon.msk.auth.iam.IAMLoginModule required awsRoleArn="" awsStsRegion="";
sasl.client.callback.handler.class=software.amazon.msk.auth.iam.IAMClientCallbackHandler
awsDebugCreds=true
ssl.truststore.location=/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.342.b07-1.amzn2.0.1.x86_64/jre/lib/security/cacerts
ssl.truststore.password=changeit
```
1. Führen Sie den folgenden Kafka-Befehl aus, um die Themen aufzulisten. Wenn Ihre Verbindung öffentlich ist, verwenden Sie die öffentlichen Endpunkt-Bootstrap-Server. Wenn Ihre Verbindung privat ist, verwenden Sie die privaten Endpunkt-Bootstrap-Server.
```
bin/kafka-topics.sh --list --bootstrap-server --command-config bin/client.properties
```
Wenn die Anfrage erfolgreich ist, sollten Sie eine Ausgabe sehen, die dem folgenden Beispiel ähnelt.
```
[ec2-user@ip-xx-xx-xx-xx kafka_2.12-2.6.2]$ bin/kafka-topics.sh --list --bootstrap-server --command-config bin/client.properties
[xxxx-xx-xx 05:49:50,877] WARN The configuration 'awsDebugCreds' was supplied but isn't a known config. (org.apache.kafka.clients.admin.AdminClientConfig)
[xxxx-xx-xx 05:49:50,878] WARN The configuration 'ssl.truststore.location' was supplied but isn't a known config. (org.apache.kafka.clients.admin.AdminClientConfig)
[xxxx-xx-xx 05:49:50,878] WARN The configuration 'sasl.jaas.config' was supplied but isn't a known config. (org.apache.kafka.clients.admin.AdminClientConfig)
[xxxx-xx-xx 05:49:50,878] WARN The configuration 'sasl.client.callback.handler.class' was supplied but isn't a known config. (org.apache.kafka.clients.admin.AdminClientConfig)
[xxxx-xx-xx 05:49:50,878] WARN The configuration 'ssl.truststore.password' was supplied but isn't a known config. (org.apache.kafka.clients.admin.AdminClientConfig)
[xxxx-xx-xx 05:50:21,629] WARN [AdminClient clientId=adminclient-1] Connection to node...
__amazon_msk_canary
__consumer_offsets
```
1. Wenn Sie Probleme mit der Ausführung des vorherigen Skripts haben, überprüfen Sie, ob die von Ihnen angegebenen Bootstrap-Server über den angegebenen Port erreichbar sind. Zu diesem Zweck können Sie **Telnet** oder ein ähnliches Hilfsprogramm herunterladen und verwenden, wie im folgenden Befehl gezeigt.
```
sudo yum install telnet
telnet
```
Wenn die Anfrage erfolgreich ist, erhalten Sie die folgende Ausgabe. Das bedeutet, dass Sie innerhalb Ihrer lokalen VPC eine Verbindung zu Ihrem MSK-Cluster herstellen können und die Bootstrap-Server auf dem angegebenen Port fehlerfrei sind.
```
Connected to ..
```
1. Wenn die Anfrage nicht erfolgreich ist, überprüfen Sie die Regeln für eingehende Nachrichten in Ihrer [VPC-Sicherheitsgruppe](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-rules.html). Als Beispiel könnten Sie die folgenden Eigenschaften für die Regel für eingehenden Datenverkehr verwenden.
```
Type: All traffic
Port: Port used by the bootstrap server (e.g. 14001)
Source: 0.0.0.0/0
```
Versuchen Sie erneut, die **Telnet-Verbindung** herzustellen, wie im vorherigen Schritt gezeigt. Wenn Sie immer noch keine Verbindung herstellen können oder Ihre Firehose-Verbindung immer noch ausfällt, wenden Sie sich an den [AWS Support](https://aws.amazon.com/contact-us/).