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.
Jedes Amazon Data Firehose-Ziel hat seine eigene Behandlung bei Datenlieferfehlern.
Wenn Sie einen Firehose für viele Ziele wie Splunk- und HTTP-Endpunkte einrichten OpenSearch, richten Sie auch einen S3-Bucket ein, in dem Daten, die nicht zugestellt werden können, gesichert werden können. Weitere Informationen darüber, wie Firehose Daten bei fehlgeschlagenen Lieferungen sichert, finden Sie in den entsprechenden Zielabschnitten auf dieser Seite. Weitere Informationen darüber, wie Sie Zugriff auf S3-Buckets gewähren, in denen Daten gesichert werden können, die nicht zugestellt werden können, finden Sie unter Firehose-Zugriff auf ein Amazon S3 S3-Ziel gewähren. Wenn Firehose (a) keine Daten an das Stream-Ziel liefert und (b) keine Daten für fehlgeschlagene Lieferungen in den Backup-S3-Bucket schreibt, wird die Stream-Übertragung effektiv angehalten, bis Daten entweder an das Ziel geliefert oder an den Backup-S3-Speicherort geschrieben werden können.
Amazon S3
Die Datenbereitstellung zu Ihrem S3-Bucket kann aus verschiedenen Gründen fehlschlagen. Beispielsweise ist der Bucket möglicherweise nicht mehr vorhanden, die IAM-Rolle, von der Amazon Data Firehose annimmt, dass sie keinen Zugriff auf den Bucket hat, dass das Netzwerk ausgefallen ist oder ähnliche Ereignisse auftreten. Unter diesen Bedingungen versucht Amazon Data Firehose bis zu 24 Stunden lang erneut, bis die Lieferung erfolgreich ist. Die maximale Datenspeicherzeit von Amazon Data Firehose beträgt 24 Stunden. Falls die Datenbereitstellung länger als 24 Stunden fehlschlägt, gehen die Daten verloren.
Die Datenlieferung an Ihren S3-Bucket kann aus verschiedenen Gründen fehlschlagen, z. B.:
-
Der Bucket ist nicht mehr vorhanden.
-
Die von Amazon Data Firehose übernommene IAM-Rolle hat keinen Zugriff auf den Bucket.
-
Probleme mit dem Netzwerk.
-
S3-Fehler, wie HTTP 500s oder andere API-Fehler.
In diesen Fällen versucht Amazon Data Firehose die Lieferung erneut:
-
DirectPut Quellen: Wiederholungen dauern bis zu 24 Stunden an.
-
Kinesis Data Streams- oder Amazon MSK-Quellen: Wiederholungen werden auf unbestimmte Zeit fortgesetzt, bis die für den Stream definierte Aufbewahrungsrichtlinie eingehalten wird.
Amazon Data Firehose übermittelt fehlgeschlagene Datensätze nur dann an einen S3-Fehler-Bucket, wenn die Lambda-Verarbeitung oder die Parquet-Konvertierung fehlschlägt. Andere Fehlerszenarien führen zu kontinuierlichen Wiederholungsversuchen mit S3, bis die Aufbewahrungsfrist erreicht ist. Wenn Firehose erfolgreich Datensätze an S3 liefert, erstellt es eine S3-Objektdatei, und bei teilweisen Datensatzfehlern versucht es automatisch, erneut zuzustellen und aktualisiert dieselbe S3-Objektdatei mit den erfolgreich verarbeiteten Datensätzen.
Amazon Redshift
Für ein Amazon Redshift Redshift-Ziel können Sie beim Erstellen eines Firehose-Streams eine Wiederholungsdauer (0—7200 Sekunden) angeben.
Die Datenbereitstellung an Ihren bereitgestellten Amazon-Redshift-Cluster oder Ihre Arbeitsgruppe von Amazon Redshift Serverless kann aus verschiedenen Gründen fehlschlagen. Möglicherweise haben Sie beispielsweise eine falsche Clusterkonfiguration Ihres Firehose-Streams, einen Cluster oder eine Arbeitsgruppe, die gewartet wird, oder es liegt ein Netzwerkausfall vor. Unter diesen Bedingungen versucht Amazon Data Firehose es für die angegebene Zeitdauer erneut und überspringt diesen bestimmten Stapel von Amazon S3 S3-Objekten. Die Informationen zu den übersprungenen Objekten werden Ihrem S3-Bucket als Manifestdatei im Ordner errors/ bereitgestellt. Sie können diesen für manuelle Backfill-Vorgänge verwenden. Informationen darüber, wie Sie Daten manuell mit Manifestdateien kopieren, finden Sie unter Verwenden eines Manifests für die Angabe von Datendateien.
Amazon OpenSearch Service und OpenSearch Serverless
Für das OpenSearch Service- und OpenSearch Serverless-Ziel können Sie bei der Erstellung des Firehose-Streams eine Wiederholungsdauer (0—7200 Sekunden) angeben.
Die Datenzustellung an Ihren OpenSearch Service-Cluster oder Ihre OpenSearch serverlose Sammlung kann aus verschiedenen Gründen fehlschlagen. Möglicherweise haben Sie beispielsweise eine falsche OpenSearch Service Cluster- oder OpenSearch Serverless Collection-Konfiguration Ihres Firehose-Streams, einen OpenSearch Service-Cluster oder eine OpenSearch Serverless-Sammlung, die gerade gewartet wird, ein Netzwerkausfall oder ähnliche Ereignisse vorliegen. Unter diesen Bedingungen versucht Amazon Data Firehose es für die angegebene Zeitdauer erneut und überspringt dann die jeweilige Indexanforderung. Die übersprungenen Dokumente werden Ihrem S3-Bucket im Ordner AmazonOpenSearchService_failed/ bereitgestellt. Sie können diesen für manuelle Backfill-Vorgänge verwenden.
Für OpenSearch Service hat jedes Dokument das folgende JSON-Format:
{
"attemptsMade": "(number of index requests attempted)",
"arrivalTimestamp": "(the time when the document was received by Firehose)",
"errorCode": "(http error code returned by OpenSearch Service)",
"errorMessage": "(error message returned by OpenSearch Service)",
"attemptEndingTimestamp": "(the time when Firehose stopped attempting index request)",
"esDocumentId": "(intended OpenSearch Service document ID)",
"esIndexName": "(intended OpenSearch Service index name)",
"esTypeName": "(intended OpenSearch Service type name)",
"rawData": "(base64-encoded document data)"
}Bei OpenSearch Serverless hat jedes Dokument das folgende JSON-Format:
{
"attemptsMade": "(number of index requests attempted)",
"arrivalTimestamp": "(the time when the document was received by Firehose)",
"errorCode": "(http error code returned by OpenSearch Serverless)",
"errorMessage": "(error message returned by OpenSearch Serverless)",
"attemptEndingTimestamp": "(the time when Firehose stopped attempting index request)",
"osDocumentId": "(intended OpenSearch Serverless document ID)",
"osIndexName": "(intended OpenSearch Serverless index name)",
"rawData": "(base64-encoded document data)"
}
Splunk
Wenn Amazon Data Firehose Daten an Splunk sendet, wartet es auf eine Bestätigung von Splunk. Wenn ein Fehler auftritt oder die Bestätigung nicht innerhalb des Zeitlimits für die Bestätigung eingeht, startet Amazon Data Firehose den Zähler für die Dauer der Wiederholungsversuche. Der Vorgang wird wiederholt, bis die Wiederholungsdauer abgelaufen ist. Danach betrachtet Amazon Data Firehose den Fehler bei der Datenübermittlung und sichert die Daten in Ihrem Amazon S3 S3-Bucket.
Jedes Mal, wenn Amazon Data Firehose Daten an Splunk sendet, unabhängig davon, ob es sich um einen ersten Versuch oder einen erneuten Versuch handelt, wird der Timeout-Zähler für die Bestätigung neu gestartet. Er wartet dann auf eine Bestätigung von Splunk. Selbst wenn die Dauer des Wiederholungsversuchs abläuft, wartet Amazon Data Firehose immer noch auf die Bestätigung, bis sie eingeht oder das Bestätigungs-Timeout erreicht ist. Wenn bei der Bestätigung eine Zeitüberschreitung eintritt, prüft Amazon Data Firehose, ob im Wiederholungszähler noch Zeit übrig ist. Ist noch Zeit übrig, führt es erneut eine Wiederholung durch und wiederholt die Logik, bis es eine Bestätigung erhält, oder feststellt, dass die Wiederholungszeitdauer abgelaufen ist.
Eine fehlende Bestätigung ist nicht der einzige Fehlertyp, der bei einer Datenübermittlung auftreten kann. Weitere Informationen zu den anderen Fehlertypen finden Sie unter Fehler bei der Datenbereitstellung für Splunk. Ein Fehler bei der Datenbereitstellung löst die Wiederhollogik aus, wenn Ihre Wiederholdauer größer als 0 ist.
Nachfolgend sehen Sie ein Beispiel für einen Fehlerdatensatz.
{
"attemptsMade": 0,
"arrivalTimestamp": 1506035354675,
"errorCode": "Splunk.AckTimeout",
"errorMessage": "Did not receive an acknowledgement from HEC before the HEC acknowledgement timeout expired. Despite the acknowledgement timeout, it's possible the data was indexed successfully in Splunk. Amazon Data Firehose backs up in Amazon S3 data for which the acknowledgement timeout expired.",
"attemptEndingTimestamp": 13626284715507,
"rawData": "MiAyNTE2MjAyNzIyMDkgZW5pLTA1ZjMyMmQ1IDIxOC45Mi4xODguMjE0IDE3Mi4xNi4xLjE2NyAyNTIzMyAxNDMzIDYgMSA0MCAxNTA2MDM0NzM0IDE1MDYwMzQ3OTQgUkVKRUNUIE9LCg==",
"EventId": "49577193928114147339600778471082492393164139877200035842.0"
}HTTP-Endpunktziel
Wenn Amazon Data Firehose Daten an ein HTTP-Endpunktziel sendet, wartet es auf eine Antwort von diesem Ziel. Wenn ein Fehler auftritt oder die Antwort nicht innerhalb des Antwort-Timeouts eingeht, startet Amazon Data Firehose den Zähler für die Dauer der Wiederholungsversuche. Der Vorgang wird wiederholt, bis die Wiederholungsdauer abgelaufen ist. Danach betrachtet Amazon Data Firehose den Fehler bei der Datenübermittlung und sichert die Daten in Ihrem Amazon S3 S3-Bucket.
Jedes Mal, wenn Amazon Data Firehose Daten an ein HTTP-Endpunktziel sendet, unabhängig davon, ob es sich um den ersten Versuch oder einen erneuten Versuch handelt, wird der Antwort-Timeout-Zähler neu gestartet. Anschließend wartet es darauf, dass eine Antwort vom HTTP-Endpunktziel eingeht. Selbst wenn die Wiederholungsdauer abläuft, wartet Amazon Data Firehose immer noch auf die Antwort, bis sie eingeht oder das Antwort-Timeout erreicht ist. Wenn bei der Antwort eine Zeitüberschreitung eintritt, prüft Amazon Data Firehose, ob im Wiederholungszähler noch Zeit übrig ist. Ist noch Zeit übrig, führt es erneut eine Wiederholung durch und wiederholt die Logik, bis es eine Response erhält, oder feststellt, dass die Wiederholungszeitdauer abgelaufen ist.
Eine fehlende Response ist nicht der einzige Fehlertyp, der bei einer Datenübermittlung auftreten kann. Weitere Informationen zu den anderen Fehlertypen finden Sie unter Fehler bei der Datenbereitstellung für den HTTP-Endpunkt
Nachfolgend sehen Sie ein Beispiel für einen Fehlerdatensatz.
{
"attemptsMade":5,
"arrivalTimestamp":1594265943615,
"errorCode":"HttpEndpoint.DestinationException",
"errorMessage":"Received the following response from the endpoint destination. {"requestId": "109777ac-8f9b-4082-8e8d-b4f12b5fc17b", "timestamp": 1594266081268, "errorMessage": "Unauthorized"}",
"attemptEndingTimestamp":1594266081318,
"rawData":"c2FtcGxlIHJhdyBkYXRh",
"subsequenceNumber":0,
"dataId":"49607357361271740811418664280693044274821622880012337186.0"
} Snowflake
Für das Snowflake-Ziel können Sie beim Erstellen Firehose Firehose-Streams eine optionale Wiederholungsdauer (0-7200 Sekunden) angeben. Der Standardwert für die Dauer der Wiederholungen beträgt 60 Sekunden.
Die Datenübermittlung an Ihre Snowflake-Tabelle kann aus verschiedenen Gründen fehlschlagen, z. B. aufgrund einer falschen Snowflake-Zielkonfiguration, eines Snowflake-Ausfalls, eines Netzwerkausfalls usw. Die Wiederholungsrichtlinie gilt nicht für Fehler, die nicht behoben werden können. Wenn Snowflake beispielsweise Ihre JSON-Nutzlast ablehnt, weil sie eine zusätzliche Spalte hatte, die in der Tabelle fehlt, versucht Firehose nicht, sie erneut zu liefern. Stattdessen wird eine Sicherungskopie für alle Einfügefehler erstellt, die auf Probleme mit der JSON-Nutzlast in Ihrem S3-Fehler-Bucket zurückzuführen sind.
Wenn die Lieferung aufgrund einer falschen Rolle, Tabelle oder Datenbank fehlschlägt, versucht Firehose ebenfalls nicht erneut und schreibt die Daten in Ihren S3-Bucket. Die Dauer der Wiederholungsversuche gilt nur für Fehler aufgrund eines Snowflake-Dienstproblems, vorübergehender Netzwerkstörungen usw. Unter diesen Bedingungen versucht Firehose für die angegebene Zeitdauer erneut, bevor sie an S3 gesendet werden. Die fehlgeschlagenen Datensätze werden im Ordner snowflake-failed/ geliefert, den Sie für manuelles Auffüllen verwenden können.
Im Folgenden finden Sie ein JSON-Beispiel für jeden Datensatz, den Sie an S3 liefern.
{
"attemptsMade": 3,
"arrivalTimestamp": 1594265943615,
"errorCode": "Snowflake.InvalidColumns",
"errorMessage": "Snowpipe Streaming does not support columns of type AUTOINCREMENT, IDENTITY, GEO, or columns with a default value or collation",
"attemptEndingTimestamp": 1712937865543,
"rawData": "c2FtcGxlIHJhdyBkYXRh"
}