Häufige Probleme - Amazon Data Firehose

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.

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 .

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.

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

  • 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

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

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

  • 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 (StringSetNumberSet, undBinarySet) indexiert, speichert er sie im Datenkatalog als SET<STRING>SET<BIGINT>, bzw.. SET<BINARY> 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/.

  2. Wählen Sie im linken Bereich unter der Überschrift Data catalog (Datenkatalog) die Option Tables (Tabellen).

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

  4. Wählen Sie in der oberen rechten Ecke der Detailseite die Schaltfläche Schema bearbeiten

  5. Wählen Sie in der Spalte Data type (Datentyp) den ersten set-Datentyp aus.

  6. Ändern Sie in der Dropdownliste Column type (Spaltentyp) den Typ von set in array.

  7. Geben Sie in das ArraySchemaFeld array<string>array<int>, oder einarray<binary>, je nachdem, welcher Datentyp für Ihr Szenario geeignet ist.

  8. Wählen Sie Aktualisieren aus.

  9. Wiederholen Sie die vorherigen Schritte, um andere set-Typen in array-Typen zu konvertieren.

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