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. # Verstehen Sie die Datenlieferung in Amazon Data Firehose Wenn Sie Daten an Ihren Firehose-Stream senden, werden sie automatisch an das von Ihnen gewählte Ziel gesendet. In der folgenden Tabelle wird die Datenzustellung an verschiedene Ziele erklärt. | Ziel | Details | | --- | --- | | Amazon S3 | Für die Datenlieferung an Amazon S3 verkettet Firehose mehrere eingehende Datensätze auf der Grundlage der Pufferkonfiguration Ihres Firehose-Streams. Anschließend übermittelt es die Datensätze als Amazon-S3-Objekt an Amazon S3. Standardmäßig verkettet Firehose Daten ohne Trennzeichen. [Wenn Sie neue Zeilentrennzeichen zwischen Datensätzen haben möchten, können Sie neue Zeilentrennzeichen hinzufügen, indem Sie die Funktion in der [Firehose-Konsolenkonfiguration oder im API-Parameter](https://docs.aws.amazon.com/firehose/latest/dev/create-destination.html#create-destination-s3) aktivieren.](https://docs.aws.amazon.com/firehose/latest/APIReference/API_Processor.html) Die Datenübermittlung zwischen Firehose und dem Amazon S3 S3-Ziel ist mit TLS (HTTPS) verschlüsselt. | | Amazon Redshift | Für die Datenlieferung an Amazon Redshift liefert Firehose zunächst eingehende Daten in dem zuvor beschriebenen Format an Ihren S3-Bucket. Firehose gibt dann einen Amazon **COPY** Redshift-Befehl aus, um die Daten aus Ihrem S3-Bucket in Ihren von Amazon Redshift bereitgestellten Cluster oder Ihre Amazon Redshift Serverless-Arbeitsgruppe zu laden. Stellen Sie sicher, dass, nachdem Amazon Data Firehose mehrere eingehende Datensätze zu einem Amazon S3 S3-Objekt verkettet hat, das Amazon S3 S3-Objekt in Ihren von Amazon Redshift bereitgestellten Cluster oder Ihre Amazon Redshift Serverless-Arbeitsgruppe kopiert werden kann. Weitere Informationen finden Sie unter [Amazon Redshift COPY Command Data Format Parameters](https://docs.aws.amazon.com/redshift/latest/dg/copy-parameters-data-format.html). | | OpenSearch OpenSearch Service und Serverless | Für die Datenlieferung an OpenSearch Service und OpenSearch Serverless puffert Amazon Data Firehose eingehende Datensätze auf der Grundlage der Pufferkonfiguration Ihres Firehose-Streams. Anschließend generiert es eine OpenSearch Service- oder OpenSearch Serverless-Massenanforderung, um mehrere Datensätze in Ihrem Service-Cluster oder Ihrer OpenSearch Serverless-Sammlung zu indizieren. OpenSearch Stellen Sie sicher, dass Ihr Datensatz UTF-8-kodiert und auf ein einzeiliges JSON-Objekt reduziert ist, bevor Sie ihn an Amazon Data Firehose senden. Außerdem muss die rest.action.multi.allow\$1explicit\$1index Option für Ihren OpenSearch Service-Cluster auf true (Standard) gesetzt sein, um Massenanfragen mit einem expliziten Index entgegenzunehmen, der pro Datensatz festgelegt wird. Weitere Informationen finden Sie unter [OpenSearch Service Configure Advanced Options](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/es-createupdatedomains.html#es-createdomain-configure-advanced-options) im Amazon OpenSearch Service Developer Guide. | | Splunk | Für die Datenlieferung an Splunk verkettet Amazon Data Firehose die von Ihnen gesendeten Bytes. Wenn Sie Trennzeichen in Ihren Daten wünschen, wie z. B. ein Neue-Zeile-Zeichen, müssen Sie sie selbst einfügen. Stellen Sie sicher, dass Splunk so konfiguriert ist, dass diese Trennzeichen bei der Analyse berücksichtigt werden. [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) | | HTTP-Endpunkt | Für die Datenlieferung an einen HTTP-Endpunkt, der einem unterstützten Drittanbieter gehört, können Sie den integrierten Amazon Lambda-Service verwenden, um eine Funktion zu erstellen, um die eingehenden Datensätze in das Format umzuwandeln, das dem Format entspricht, das die Integration des Dienstanbieters erwartet. Wenden Sie sich an den Drittanbieter, dessen HTTP-Endpunkt Sie für Ihr Ziel ausgewählt haben, um mehr über das akzeptierte Datensatzformat zu erfahren. | | Snowflake | Für die Datenlieferung an Snowflake puffert Amazon Data Firehose intern Daten für eine Sekunde und verwendet Snowflake-Streaming-API-Operationen, um Daten in Snowflake einzufügen. Standardmäßig werden Datensätze, die Sie einfügen, jede Sekunde geleert und in die Snowflake-Tabelle übernommen. Nachdem Sie den Insert-Aufruf ausgeführt haben, gibt Firehose eine CloudWatch Metrik aus, die misst, wie lange es gedauert hat, bis die Daten an Snowflake übergeben wurden. Firehose unterstützt derzeit nur ein einzelnes JSON-Element als Datensatznutzlast und unterstützt keine JSON-Arrays. Stellen Sie sicher, dass Ihre Eingabe-Payload ein gültiges JSON-Objekt ist und ohne zusätzliche doppelte Anführungszeichen, Anführungszeichen oder Escape-Zeichen korrekt formatiert ist. | Jedes Firehose-Ziel hat seine eigene Datenlieferfrequenz. Weitere Informationen finden Sie unter [Pufferhinweise konfigurieren](create-configure-backup.md#buffering-hints). **Doppelte Datensätze** Amazon Data Firehose verwendet at-least-once Semantik für die Datenlieferung. Unter bestimmten Umständen, z. B. wenn das Zeitlimit für die Datenlieferung überschritten wird, kann es bei erneuten Zustellungsversuchen von Amazon Data Firehose zu Duplikaten kommen, wenn die ursprüngliche Datenlieferanforderung irgendwann durchgeht. Dies gilt für alle Zieltypen, die Amazon Data Firehose unterstützt, mit Ausnahme von Amazon S3 S3-Zielen, Apache Iceberg Tables und Snowflake-Zielen. **Topics** + [Verstehen Sie den Versand zwischen Konten und Regionen AWS](across.md) + [Verstehen Sie die Anforderungen- und Antwortspezifikationen für die HTTP-Endpunktzustellung](httpdeliveryrequestresponse.md) + [Behandeln Sie Fehler bei der Datenzustellung](retry.md) + [Amazon S3 S3-Objektnamenformat konfigurieren](s3-object-name.md) + [Konfigurieren Sie die Indexrotation für Service OpenSearch](es-index-rotation.md) + [Die Datenübermittlung unterbrechen und fortsetzen](pause-restart-stream.md) # Verstehen Sie den Versand zwischen Konten und Regionen AWS Amazon Data Firehose unterstützt die AWS kontenübergreifende Datenübermittlung an HTTP-Endpunktziele. Der Firehose-Stream und der HTTP-Endpunkt, den Sie als Ziel wählen, können zu unterschiedlichen AWS Konten gehören. Amazon Data Firehose unterstützt auch die Datenzustellung an HTTP-Endpunktziele in allen AWS Regionen. Sie können Daten aus einem Firehose-Stream in einer AWS Region an einen HTTP-Endpunkt in einer anderen AWS Region liefern. Sie können Daten auch von einem Firehose-Stream an ein HTTP-Endpunktziel außerhalb von AWS Regionen liefern, z. B. an Ihren eigenen lokalen Server, indem Sie die HTTP-Endpunkt-URL auf Ihr gewünschtes Ziel setzen. In diesen Szenarien werden zusätzliche Datenübertragungsgebühren zu Ihren Lieferkosten hinzugefügt. Weitere Informationen finden Sie im Abschnitt [Datenübertragung](https://aws.amazon.com/ec2/pricing/on-demand/#Data_Transfer) auf der Seite On-Demand-Preise. # Verstehen Sie die Anforderungen- und Antwortspezifikationen für die HTTP-Endpunktzustellung Damit Amazon Data Firehose erfolgreich Daten an benutzerdefinierte HTTP-Endpunkte liefern kann, müssen diese Endpunkte Anfragen annehmen und Antworten in bestimmten Amazon Data Firehose-Anfrage- und Antwortformaten senden. In diesem Abschnitt werden die Formatspezifikationen der HTTP-Anfragen beschrieben, die der Amazon Data Firehose-Service an benutzerdefinierte HTTP-Endpunkte sendet, sowie die Formatspezifikationen der HTTP-Antworten, die der Amazon Data Firehose-Service erwartet. HTTP-Endpunkte haben 3 Minuten Zeit, um auf eine Anfrage zu antworten, bevor Amazon Data Firehose das Zeitlimit für diese Anfrage überschreitet. Amazon Data Firehose behandelt Antworten, die nicht dem richtigen Format entsprechen, als Zustellungsfehler. ## Anforderungsformat **Pfad- und URL-Parameter** Diese werden direkt von Ihnen als Teil eines einzigen URL-Felds konfiguriert. Amazon Data Firehose sendet sie wie konfiguriert ohne Änderung. Es werden nur HTTPS-Ziele unterstützt. URL-Einschränkungen werden bei der Konfiguration des Bereitstellungsdatenstroms angewendet. Derzeit wird nur Port 443 für die Bereitstellung von HTTP-Endpunktdaten unterstützt. **HTTP-Header — -Version X-Amz-Firehose-Protocol** Dieser Header wird verwendet, um die Version der Anforderungs-/Antwortformate anzugeben. Derzeit gibt es nur die Version 1.0. **HTTP-Header - -ID X-Amz-Firehose-Request** Der Wert dieses Headers ist eine undurchsichtige GUID, die für Debugging- und Deduplizierungszwecke verwendet werden kann. Endpunktimplementierungen sollten den Wert dieses Headers nach Möglichkeit sowohl für erfolgreiche als auch für erfolglose Anfragen protokollieren. Die Anforderungs-ID wird bei mehreren Versuchen derselben Anfrage unverändert beibehalten. **HTTP-Header – Inhaltstyp** Der Wert des Content-Type-Headers ist immer `application/json`. **HTTP-Header – Inhaltskodierung** Ein Firehose-Stream kann so konfiguriert werden, dass er GZIP verwendet, um den Hauptteil beim Senden von Anfragen zu komprimieren. Wenn diese Komprimierung aktiviert ist, wird der Wert des Content-Encoding-Headers gemäß der Standardpraxis auf gzip gesetzt. Wenn die Komprimierung nicht aktiviert ist, fehlt der Content-Encoding-Header vollständig. **HTTP-Header – Inhaltslänge** Dies wird standardmäßig verwendet. **HTTP-Header - -Arn: X-Amz-Firehose-Source** Der ARN des Firehose-Streams, dargestellt im ASCII-String-Format. Der ARN kodiert die Region, die AWS Konto-ID und den Streamnamen. Beispiel, `arn:aws:firehose:us-east-1:123456789:deliverystream/testStream`. **HTTP-Header — -Schlüssel X-Amz-Firehose-Access** Dieser Header enthält einen API-Schlüssel oder andere Anmeldeinformationen. Sie haben die Möglichkeit, den API-Schlüssel (auch Autorisierungstoken genannt) zu erstellen oder zu aktualisieren, wenn Sie Ihren Bereitstellungsdatenstrom erstellen oder aktualisieren. Amazon Data Firehose beschränkt die Größe des Zugriffsschlüssels auf 4096 Byte. Amazon Data Firehose versucht in keiner Weise, diesen Schlüssel zu interpretieren. Der konfigurierte Schlüssel wird wortwörtlich in den Wert dieses Headers kopiert. Wenn Sie jedoch Secrets Manager verwenden, um den Schlüssel zu konfigurieren, muss der geheime Schlüssel einem bestimmten JSON-Objektformat folgen:`{"api_key": "..."}`. Der Inhalt kann beliebig sein und möglicherweise ein JWT-Token oder einen ACCESS\$1KEY darstellen. Wenn für einen Endpunkt Anmeldeinformationen mit mehreren Feldern erforderlich sind (z. B. Benutzername und Passwort), sollten die Werte aller Felder zusammen in einem einzigen Zugriffsschlüssel in einem Format gespeichert werden, das der Endpunkt versteht (JSON oder CSV). Dieses Feld kann Base-64-kodiert sein, wenn der ursprüngliche Inhalt binär ist. Amazon Data Firehose ändert den and/or konfigurierten Wert nicht und verwendet den Inhalt unverändert. **HTTP-Header — -Attribute X-Amz-Firehose-Common** Dieser Header enthält die gemeinsamen Attribute (Metadaten), die sich auf die gesamte Anfrage beziehen, und zwar and/or auf alle Datensätze innerhalb der Anfrage. Diese werden direkt von Ihnen konfiguriert, wenn Sie einen Firehose-Stream erstellen. Der Wert dieses Attributs ist als JSON-Objekt mit dem folgenden Schema kodiert: ``` "$schema": http://json-schema.org/draft-07/schema# properties: commonAttributes: type: object minProperties: 0 maxProperties: 50 patternProperties: "^.{1,256}$": type: string minLength: 0 maxLength: 1024 ``` Hier ein Beispiel: ``` "commonAttributes": { "deployment -context": "pre-prod-gamma", "device-types": "" } ``` **Hauptteil – maximale Größe** Die maximale Körpergröße wird von Ihnen konfiguriert und kann vor der Komprimierung bis zu 64 MiB betragen. **Körper – Schema** Der Hauptteil enthält ein einzelnes JSON-Dokument mit dem folgenden JSON-Schema (in YAML geschrieben): ``` "$schema": http://json-schema.org/draft-07/schema# title: FirehoseCustomHttpsEndpointRequest description: > The request body that the Firehose service sends to custom HTTPS endpoints. type: object properties: requestId: description: > Same as the value in the X-Amz-Firehose-Request-Id header, duplicated here for convenience. type: string timestamp: description: > The timestamp (milliseconds since epoch) at which the Firehose server generated this request. type: integer records: description: > The actual records of the Firehose stream, carrying the customer data. type: array minItems: 1 maxItems: 10000 items: type: object properties: data: description: > The data of this record, in Base64. Note that empty records are permitted in Firehose. The maximum allowed size of the data, before Base64 encoding, is 1024000 bytes; the maximum length of this field is therefore 1365336 chars. type: string minLength: 0 maxLength: 1365336 required: - requestId - records ``` Hier ein Beispiel: ``` { "requestId": "ed4acda5-034f-9f42-bba1-f29aea6d7d8f", "timestamp": 1578090901599 "records": [ { "data": "aGVsbG8=" }, { "data": "aGVsbG8gd29ybGQ=" } ] } ``` ## Reaktionsformat **Standardverhalten bei einem Fehler** Wenn eine Antwort die folgenden Anforderungen nicht erfüllt, behandelt der Firehose-Server sie so, als ob sie einen Statuscode 500 ohne Text hätte. **Statuscode** Der HTTP-Statuscode MUSS im 2XX-, 4XX- oder 5XX-Bereich liegen. Der Amazon Data Firehose-Server folgt KEINEN Weiterleitungen (3XX-Statuscodes). Nur der Antwortcode 200 gilt als erfolgreiche Übermittlung der Datensätze an HTTP/EP. Der Antwortcode 413 (Größe überschritten) wird als permanenter Fehler betrachtet und der Datensatzstapel wird nicht an den Fehler-Bucket gesendet, wenn er konfiguriert ist. Alle anderen Antwortcodes gelten als wiederherstellbare Fehler und unterliegen einem Back-off-Wiederholungsalgorithmus, der später erklärt wird. **Header – Inhaltstyp** Der einzig akzeptable Inhaltstyp ist application/json. **HTTP-Header – Inhaltskodierung** Content-Encoding DARF NICHT verwendet werden. Der Hauptteil MUSS unkomprimiert sein. **HTTP-Header – Inhaltslänge** Der Content-Length-Header MUSS vorhanden sein, wenn die Antwort einen Hauptteil hat. **Hauptteil – maximale Größe** Der Antworttext darf höchstens 1 MiB groß sein. ``` "$schema": http://json-schema.org/draft-07/schema# title: FirehoseCustomHttpsEndpointResponse description: > The response body that the Firehose service sends to custom HTTPS endpoints. type: object properties: requestId: description: > Must match the requestId in the request. type: string timestamp: description: > The timestamp (milliseconds since epoch) at which the server processed this request. type: integer errorMessage: description: > For failed requests, a message explaining the failure. If a request fails after exhausting all retries, the last Instance of the error message is copied to error output S3 bucket if configured. type: string minLength: 0 maxLength: 8192 required: - requestId - timestamp ``` Hier ein Beispiel: ``` Failure Case (HTTP Response Code 4xx or 5xx) { "requestId": "ed4acda5-034f-9f42-bba1-f29aea6d7d8f", "timestamp": "1578090903599", "errorMessage": "Unable to deliver records due to unknown error." } Success case (HTTP Response Code 200) { "requestId": "ed4acda5-034f-9f42-bba1-f29aea6d7d8f", "timestamp": 1578090903599 } ``` **Umgang mit Fehlerreaktionen** In allen Fehlerfällen versucht der Amazon Data Firehose-Server erneut, denselben Stapel von Datensätzen mithilfe eines exponentiellen Back-off-Algorithmus zuzustellen. Die Wiederholungen werden anhand einer anfänglichen Back-Off-Zeit (1 Sekunde) mit einem Jitterfaktor von (15%) zurückgesetzt, und jede weitere Wiederholung wird anhand der Formel (initial-backoff-time \$1 (multiplier (2) ^ retry\$1count)) mit zusätzlichem Jitter zurückgestellt. Die Backoff-Zeit ist auf ein maximales Intervall von 2 Minuten begrenzt. Beispielsweise beträgt die Back-Off-Zeit bei der 'n-ten Wiederholung = MAX (120, 2^n) \$1 random (0,85, 1,15). Die in der vorherigen Gleichung angegebenen Parameter können sich ändern. Die genaue anfängliche Backoff-Zeit, AWS die maximale Backoff-Zeit, den Multiplikator und die Jitter-Prozentsätze, die im exponentiellen Backoff-Algorithmus verwendet werden, finden Sie in der Firehose-Dokumentation. Bei jedem nachfolgenden Wiederholungsversuch kann sich das and/or Zugriffsschlüsselziel, an das Datensätze übermittelt werden, basierend auf der aktualisierten Konfiguration des Firehose ändern. Der Amazon Data Firehose-Service verwendet dieselbe Anforderungs-ID für alle Wiederholungen nach bestem Wissen und Gewissen. Das letzte Feature kann vom HTTP-Endpunktserver zur Deduplizierung verwendet werden. Wenn die Anfrage nach Ablauf der maximal zulässigen Zeit (basierend auf der Firehose-Stream-Konfiguration) immer noch nicht zugestellt wird, kann der Datensatzstapel optional auf der Grundlage der Stream-Konfiguration an einen Fehler-Bucket übermittelt werden. ## Beispiele Beispiel für eine Anfrage mit CWLog Herkunft. ``` { "requestId": "ed4acda5-034f-9f42-bba1-f29aea6d7d8f", "timestamp": 1578090901599, "records": [ { "data": { "messageType": "DATA_MESSAGE", "owner": "123456789012", "logGroup": "log_group_name", "logStream": "log_stream_name", "subscriptionFilters": [ "subscription_filter_name" ], "logEvents": [ { "id": "0123456789012345678901234567890123456789012345", "timestamp": 1510109208016, "message": "log message 1" }, { "id": "0123456789012345678901234567890123456789012345", "timestamp": 1510109208017, "message": "log message 2" } ] } } ] } ``` # Behandeln Sie Fehler bei der Datenzustellung 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](https://docs.aws.amazon.com/firehose/latest/dev/controlling-access.html#using-iam-s3). 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 übermittelt, 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](https://docs.aws.amazon.com/redshift/latest/dg/loading-data-files-using-manifest.html). ## 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. Es wird so lange wiederholt, bis die Dauer des Wiederholungsversuchs 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](https://docs.aws.amazon.com/firehose/latest/dev/monitoring-with-cloudwatch-logs.html#monitoring-splunk-errors). 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. Es wird so lange wiederholt, bis die Dauer des Wiederholungsversuchs 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](https://docs.aws.amazon.com/firehose/latest/dev/monitoring-with-cloudwatch-logs.html#monitoring-http-errors) 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" } ``` # Amazon S3 S3-Objektnamenformat konfigurieren Wenn Firehose Daten an Amazon S3 liefert, folgt der Name des S3-Objektschlüssels dem Format** , wobei das Suffix das Format *- - - - - -* hat, mit 1 beginnt und bei jeder Konfigurationsänderung des Firehose-Streams um 1 erhöht wird. Sie können die Firehose-Stream-Konfigurationen ändern (z. B. den Namen des S3-Buckets, Pufferhinweise, Komprimierung und Verschlüsselung). Sie können dies mithilfe der Firehose-Konsole oder der [UpdateDestination](https://docs.aws.amazon.com/firehose/latest/APIReference/API_UpdateDestination.html)API-Operation tun. Denn** Firehose fügt dem Format `YYYY/MM/dd/HH` ein Standard-Zeitpräfix hinzu. Dieses Präfix erstellt eine logische Hierarchie im Bucket, wobei jeder Schrägstrich (/) eine Ebene in der Hierarchie erzeugt. Sie können diese Struktur ändern, indem Sie ein benutzerdefiniertes Präfix angeben, das Ausdrücke enthält, die zur Laufzeit ausgewertet werden. Informationen zur Angabe eines benutzerdefinierten [Präfixes finden Sie unter Benutzerdefinierte Präfixe für Amazon Simple Storage Service Objects](https://docs.aws.amazon.com/firehose/latest/dev/s3-prefixes.html). Standardmäßig ist die Zeitzone, die für das Zeitpräfix und das Suffix verwendet wird, UTC, aber Sie können sie in eine Zeitzone ändern, die Sie bevorzugen. Um beispielsweise Japan Standard Time anstelle von UTC zu verwenden, können Sie die Zeitzone in der AWS-Managementkonsole oder Asia/Tokyo in der [API-Parametereinstellung (CustomTimeZone)](https://docs.aws.amazon.com/firehose/latest/APIReference/API_ExtendedS3DestinationConfiguration.html) so konfigurieren. Die folgende Liste enthält Zeitzonen, die Firehose für die S3-Präfixkonfiguration unterstützt. ## Unterstützte Zeitzonen Im Folgenden finden Sie eine Liste der Zeitzonen, die Firehose für die S3-Präfixkonfiguration unterstützt. ------ #### [ Africa ] ``` Africa/Abidjan Africa/Accra Africa/Addis_Ababa Africa/Algiers Africa/Asmera Africa/Bangui Africa/Banjul Africa/Bissau Africa/Blantyre Africa/Bujumbura Africa/Cairo Africa/Casablanca Africa/Conakry Africa/Dakar Africa/Dar_es_Salaam Africa/Djibouti Africa/Douala Africa/Freetown Africa/Gaborone Africa/Harare Africa/Johannesburg Africa/Kampala Africa/Khartoum Africa/Kigali Africa/Kinshasa Africa/Lagos Africa/Libreville Africa/Lome Africa/Luanda Africa/Lubumbashi Africa/Lusaka Africa/Malabo Africa/Maputo Africa/Maseru Africa/Mbabane Africa/Mogadishu Africa/Monrovia Africa/Nairobi Africa/Ndjamena Africa/Niamey Africa/Nouakchott Africa/Ouagadougou Africa/Porto-Novo Africa/Sao_Tome Africa/Timbuktu Africa/Tripoli Africa/Tunis Africa/Windhoek ``` ------ #### [ America ] ``` America/Adak America/Anchorage America/Anguilla America/Antigua America/Aruba America/Asuncion America/Barbados America/Belize America/Bogota America/Buenos_Aires America/Caracas America/Cayenne America/Cayman America/Chicago America/Costa_Rica America/Cuiaba America/Curacao America/Dawson_Creek America/Denver America/Dominica America/Edmonton America/El_Salvador America/Fortaleza America/Godthab America/Grand_Turk America/Grenada America/Guadeloupe America/Guatemala America/Guayaquil America/Guyana America/Halifax America/Havana America/Indianapolis America/Jamaica America/La_Paz America/Lima America/Los_Angeles America/Managua America/Manaus America/Martinique America/Mazatlan America/Mexico_City America/Miquelon America/Montevideo America/Montreal America/Montserrat America/Nassau America/New_York America/Noronha America/Panama America/Paramaribo America/Phoenix America/Port_of_Spain America/Port-au-Prince America/Porto_Acre America/Puerto_Rico America/Regina America/Rio_Branco America/Santiago America/Santo_Domingo America/Sao_Paulo America/Scoresbysund America/St_Johns America/St_Kitts America/St_Lucia America/St_Thomas America/St_Vincent America/Tegucigalpa America/Thule America/Tijuana America/Tortola America/Vancouver America/Winnipeg ``` ------ #### [ Antarctica ] ``` Antarctica/Casey Antarctica/DumontDUrville Antarctica/Mawson Antarctica/McMurdo Antarctica/Palmer ``` ------ #### [ Asia ] ``` Asia/Aden Asia/Almaty Asia/Amman Asia/Anadyr Asia/Aqtau Asia/Aqtobe Asia/Ashgabat Asia/Ashkhabad Asia/Baghdad Asia/Bahrain Asia/Baku Asia/Bangkok Asia/Beirut Asia/Bishkek Asia/Brunei Asia/Calcutta Asia/Colombo Asia/Dacca Asia/Damascus Asia/Dhaka Asia/Dubai Asia/Dushanbe Asia/Hong_Kong Asia/Irkutsk Asia/Jakarta Asia/Jayapura Asia/Jerusalem Asia/Kabul Asia/Kamchatka Asia/Karachi Asia/Katmandu Asia/Krasnoyarsk Asia/Kuala_Lumpur Asia/Kuwait Asia/Macao Asia/Magadan Asia/Manila Asia/Muscat Asia/Nicosia Asia/Novosibirsk Asia/Phnom_Penh Asia/Pyongyang Asia/Qatar Asia/Rangoon Asia/Riyadh Asia/Saigon Asia/Seoul Asia/Shanghai Asia/Singapore Asia/Taipei Asia/Tashkent Asia/Tbilisi Asia/Tehran Asia/Thimbu Asia/Thimphu Asia/Tokyo Asia/Ujung_Pandang Asia/Ulaanbaatar Asia/Ulan_Bator Asia/Vientiane Asia/Vladivostok Asia/Yakutsk Asia/Yekaterinburg Asia/Yerevan ``` ------ #### [ Atlantic ] ``` Atlantic/Azores Atlantic/Bermuda Atlantic/Canary Atlantic/Cape_Verde Atlantic/Faeroe Atlantic/Jan_Mayen Atlantic/Reykjavik Atlantic/South_Georgia Atlantic/St_Helena Atlantic/Stanley ``` ------ #### [ Australia ] ``` Australia/Adelaide Australia/Brisbane Australia/Broken_Hill Australia/Darwin Australia/Hobart Australia/Lord_Howe Australia/Perth Australia/Sydney ``` ------ #### [ Europe ] ``` Europe/Amsterdam Europe/Andorra Europe/Athens Europe/Belgrade Europe/Berlin Europe/Brussels Europe/Bucharest Europe/Budapest Europe/Chisinau Europe/Copenhagen Europe/Dublin Europe/Gibraltar Europe/Helsinki Europe/Istanbul Europe/Kaliningrad Europe/Kiev Europe/Lisbon Europe/London Europe/Luxembourg Europe/Madrid Europe/Malta Europe/Minsk Europe/Monaco Europe/Moscow Europe/Oslo Europe/Paris Europe/Prague Europe/Riga Europe/Rome Europe/Samara Europe/Simferopol Europe/Sofia Europe/Stockholm Europe/Tallinn Europe/Tirane Europe/Vaduz Europe/Vienna Europe/Vilnius Europe/Warsaw Europe/Zurich ``` ------ #### [ Indian ] ``` Indian/Antananarivo Indian/Chagos Indian/Christmas Indian/Cocos Indian/Comoro Indian/Kerguelen Indian/Mahe Indian/Maldives Indian/Mauritius Indian/Mayotte Indian/Reunion ``` ------ #### [ Pacific ] ``` Pacific/Apia Pacific/Auckland Pacific/Chatham Pacific/Easter Pacific/Efate Pacific/Enderbury Pacific/Fakaofo Pacific/Fiji Pacific/Funafuti Pacific/Galapagos Pacific/Gambier Pacific/Guadalcanal Pacific/Guam Pacific/Honolulu Pacific/Kiritimati Pacific/Kosrae Pacific/Majuro Pacific/Marquesas Pacific/Nauru Pacific/Niue Pacific/Norfolk Pacific/Noumea Pacific/Pago_Pago Pacific/Palau Pacific/Pitcairn Pacific/Ponape Pacific/Port_Moresby Pacific/Rarotonga Pacific/Saipan Pacific/Tahiti Pacific/Tarawa Pacific/Tongatapu Pacific/Truk Pacific/Wake Pacific/Wallis ``` ------ Sie können das Suffixfeld nur ändern.** Wenn Sie die Konvertierung oder Komprimierung von Datenformaten aktivieren, hängt Firehose eine auf der Konfiguration basierende Dateierweiterung an. In der folgenden Tabelle wird die von Firehose angehängte Standarddateierweiterung erklärt: | Konfiguration | Dateierweiterung | | --- | --- | | Konvertierung von Datenformaten: Parquet | .parquet | | Konvertierung von Datenformaten: ORC | .orc | | Komprimierung: Gzip | .gz | | Komprimierung: Zip | .zip | | Komprimierung: Snappy | .snappy | | Komprimierung: Hadoop-Snappy | .hsnappy | Sie können auch eine von Ihnen bevorzugte Dateierweiterung in der Firehose-Konsole oder -API angeben. Die Dateierweiterung muss mit einem Punkt (.) beginnen und kann die zulässigen Zeichen enthalten: 0-9a-z\$1 -\$1.\$1' (). Die Dateierweiterung darf 128 Zeichen nicht überschreiten. **Anmerkung** Wenn Sie eine Dateierweiterung angeben, überschreibt diese die Standarddateierweiterung, die Firehose hinzufügt, wenn die [Datenformatkonvertierung](https://docs.aws.amazon.com/firehose/latest/dev/record-format-conversion.html) oder -komprimierung aktiviert ist. # Verstehen Sie benutzerdefinierte Präfixe für Amazon S3 S3-Objekte Objekte, die an Amazon S3 geliefert werden, folgen dem [Namensformat](https://docs.aws.amazon.com/firehose/latest/dev/basic-deliver.html#s3-object-namekey) von . Sie können Ihr benutzerdefiniertes Präfix angeben, das Ausdrücke enthält, die zur Laufzeit ausgewertet werden. Das von Ihnen angegebene benutzerdefinierte Präfix überschreibt das Standardpräfix von`yyyy/MM/dd/HH`. Sie können Ausdrücke der folgenden Formen in Ihrem benutzerdefinierten Präfix verwenden: `!{namespace:value}`, wobei `namespace` einer von den beiden sein kann, wie in den folgenden Abschnitten erläutert. + `firehose` + `timestamp` + `partitionKeyFromQuery` + `partitionKeyFromLambda` Wenn ein Präfix mit einem Schrägstrich endet, wird es als Ordner im Amazon-S3-Bucket angezeigt. Weitere Informationen finden Sie unter [Amazon S3 Object Name Format](https://docs.aws.amazon.com/firehose/latest/dev/basic-deliver.html#s3-object-name) im *Amazon Data FirehoseDeveloper Guide*. ## Namespace `timestamp` Gültige Werte für diesen Namespace sind Zeichenketten, die gültige [ DateTimeFormatterJava-Zeichenketten](https://docs.oracle.com/javase/8/docs/api/java/time/format/DateTimeFormatter.html) sind. Beispiel: Im Jahr 2018 wird der Ausdruck `!{timestamp:yyyy}` als `2018` ausgewertet. Bei der Auswertung von Zeitstempeln verwendet Firehose den ungefähren Ankunftszeitstempel des ältesten Datensatzes, der in dem zu schreibenden Amazon S3 S3-Objekt enthalten ist. Standardmäßig ist der Zeitstempel in UTC. Sie können jedoch eine Zeitzone angeben, die Sie bevorzugen. Sie können die Zeitzone beispielsweise in der AWS-Managementkonsole oder Asia/Tokyo in der API-Parametereinstellung ([CustomTimeZone](https://docs.aws.amazon.com/firehose/latest/APIReference/API_ExtendedS3DestinationConfiguration.html)) so konfigurieren, wenn Sie Japan Standard Time anstelle von UTC verwenden möchten. Eine Liste der unterstützten Zeitzonen finden Sie unter [Amazon S3 Object Name Format](https://docs.aws.amazon.com/firehose/latest/dev/basic-deliver.html#s3-object-name). Wenn Sie den Namespace `timestamp` mehr als einmal in demselben Präfixausdruck verwenden, werden alle Instances mit demselben Zeitpunkt ausgewertet. ## Namespace `firehose` Es gibt zwei Werte, die Sie mit diesem Namespace verwenden können: `error-output-type` und `random-string`. In der folgenden Tabelle wird beschrieben, wie Sie diese verwenden. **Die `firehose`-Namespace-Werte** | Konvertierung | Description | Beispieleingabe | Beispielausgabe | Hinweise | | --- | --- | --- | --- | --- | | error-output-type | Ergibt je nach Konfiguration Ihres Firehose-Streams und der Ursache des Fehlers eine der folgenden Zeichenketten: \$1processing-failed, -failed, AmazonOpenSearchService splunk-failed,,\$1. format-conversion-failed http-endpoint-failedWenn Sie ihn mehr als einmal in demselben Ausdruck verwenden, werden alle Instances als dieselbe Fehlerzeichenfolge ausgewertet. | myPrefix/result=\$1\$1firehose:error-output-type\$1/\$1\$1timestamp:yyyy/MM/dd\$1 | myPrefix/result=processing-failed/2018/08/03 | Der error-output-type Wert kann nur in dem Feld verwendet werden. ErrorOutputPrefix | | random-string | Wird als zufällige Zeichenfolge von 11 Zeichen ausgewertet. Wenn Sie ihn mehr als einmal in demselben Ausdruck verwenden, werden alle Instances als neue zufällige Zeichenfolge ausgewertet. | myPrefix/\$1\$1firehose:random-string\$1/ | myPrefix/046b6c7f-0b/ | Sie können ihn mit beiden Präfixtypen verwenden.Sie können ihn an den Anfang der Formatzeichenfolge setzen, um ein zufälliges Präfix abzurufen. Dies ist manchmal erforderlich, wenn sie einen extrem hohen Durchsatz mit Amazon S3 erreichen möchten. | ## `partitionKeyFromLambda`- und `partitionKeyFromQuery`-Namespaces Für die [dynamische Partitionierung](dynamic-partitioning.md) müssen Sie das folgende Ausdrucksformat in Ihrem S3-Bucket-Präfix verwenden: `!{namespace:value}`, wobei Namespace entweder `partitionKeyFromQuery`, `partitionKeyFromLambda` oder beides sein kann. Wenn Sie Inline-Parsing verwenden, um die Partitionierungsschlüssel für Ihre Quelldaten zu erstellen, müssen Sie einen S3-Bucket-Präfixwert angeben, der aus Ausdrücken besteht, die im folgenden Format angegeben sind: `"partitionKeyFromQuery:keyID"`. Wenn Sie AWS -Lambda-Funktion verwenden, um die Partitionierungsschlüssel für Ihre Quelldaten zu erstellen, müssen Sie einen S3-Bucket-Präfixwert angeben, der aus Ausdrücken besteht, die im folgenden Format angegeben sind: `"partitionKeyFromLambda:keyID"`. Weitere Informationen finden Sie unter „Wählen Sie Amazon S3 für Ihr Ziel“ unter [Erstellen eines Amazon Firehose-Streams](basic-create.md#basic-create.title). ## Semantische Regeln Folgende Regeln gelten für die Ausdrücke `Prefix` und `ErrorOutputPrefix`. + Für den Namespace `timestamp` wird jedes Zeichen ausgewertet, das nicht in einfache Anführungszeichen gesetzt ist. Anders ausgedrückt: Alle Zeichenfolgen mit durch Escape-Zeichen geschützten einfachen Anführungszeichen im Wertefeld werden unverändert übernommen. + Wenn Sie ein Präfix angeben, das keinen Timestamp-Namespace-Ausdruck enthält, hängt Firehose den Ausdruck an den Wert im `!{timestamp:yyyy/MM/dd/HH/}` Feld an. `Prefix` + Die Sequenz `!{` kann nur in `!{namespace:value}`-Ausdrücken angezeigt werden. + `ErrorOutputPrefix` kann nur dann Null sein, wenn `Prefix` keine Ausdrücke enthält. In diesem Fall wird `Prefix` als `yyyy/MM/DDD/HH/` und `ErrorOutputPrefix` als `yyyy/MM/DDD/HH/` ausgewertet. `DDD` repräsentiert den Tag des Jahres. + Wenn Sie einen Ausdruck für `ErrorOutputPrefix` angeben, müssen Sie mindestens eine Instance von `!{firehose:error-output-type}` einschließen. + `Prefix` kann nicht `!{firehose:error-output-type}` enthalten. + Weder `Prefix` noch `ErrorOutputPrefix` können nach der Auswertung länger als 512 Zeichen sein. + Wenn das Ziel Amazon Redshift ist, darf `Prefix` keine Ausdrücke enthalten und `ErrorOutputPrefix` muss Null sein. + Wenn das Ziel Amazon OpenSearch Service oder Splunk ist und kein Ziel angegeben `ErrorOutputPrefix` ist, verwendet Firehose das `Prefix` Feld für fehlgeschlagene Datensätze. + Wenn das Ziel Amazon S3 ist, werden das `Prefix` und `ErrorOutputPrefix` in der Amazon-S3-Zielkonfiguration für erfolgreiche Datensätze bzw. fehlgeschlagene Datensätze verwendet. Wenn Sie die AWS CLI oder die API verwenden, können Sie mit der `ExtendedS3DestinationConfiguration` eine Amazon-S3-*Backup*-Konfiguration mit einem eigenen `Prefix` und `ErrorOutputPrefix` angeben. + Wenn Sie Amazon S3 verwenden AWS-Managementkonsole und das Ziel auf Amazon S3 setzen, verwendet Firehose das `Prefix` und `ErrorOutputPrefix` in der Zielkonfiguration für erfolgreiche bzw. fehlgeschlagene Datensätze. Wenn Sie ein Präfix mithilfe von Ausdrücken angeben, müssen Sie das Fehlerpräfix einschließlich `!{firehose:error-output-type}` angeben. + Wenn Sie `ExtendedS3DestinationConfiguration` mit der AWS CLI, der API oder, wenn Sie eine angeben CloudFormation, Firehose verwenden`S3BackupConfiguration`, stellt Firehose keinen Standard `ErrorOutputPrefix` bereit. + Sie können beim Erstellen von `partitionKeyFromLambda` Ausdrücken keine `partitionKeyFromQuery` Namespaces verwenden. ErrorOutputPrefix ## Beispielpräfixe **Beispiele für `Prefix` und `ErrorOutputPrefix`** | Input | Ausgewertetes Präfix (10:30 UTC am 27. August 2018) | | --- | --- | | `Prefix`: Nicht angegeben `ErrorOutputPrefix`: `myFirehoseFailures/!{firehose:error-output-type}/` | `Prefix`: `2018/08/27/10` `ErrorOutputPrefix`: `myFirehoseFailures/processing-failed/` | | `Prefix`: `!{timestamp:yyyy/MM/dd}` `ErrorOutputPrefix`: Nicht angegeben | Ungültige Eingabe: ErrorOutputPrefix kann nicht Null sein, wenn Präfix Ausdrücke enthält | | `Prefix`: `myFirehose/DeliveredYear=!{timestamp:yyyy}/anyMonth/rand=!{firehose:random-string}` `ErrorOutputPrefix`: `myFirehoseFailures/!{firehose:error-output-type}/!{timestamp:yyyy}/anyMonth/!{timestamp:dd}` | `Prefix`: `myFirehose/DeliveredYear=2018/anyMonth/rand=5abf82daaa5` `ErrorOutputPrefix`: `myFirehoseFailures/processing-failed/2018/anyMonth/10` | | `Prefix`: `myPrefix/year=!{timestamp:yyyy}/month=!{timestamp:MM}/day=!{timestamp:dd}/hour=!{timestamp:HH}/` `ErrorOutputPrefix`: `myErrorPrefix/year=!{timestamp:yyyy}/month=!{timestamp:MM}/day=!{timestamp:dd}/hour=!{timestamp:HH}/!{firehose:error-output-type}` | `Prefix`: `myPrefix/year=2018/month=07/day=06/hour=23/` `ErrorOutputPrefix`: `myErrorPrefix/year=2018/month=07/day=06/hour=23/processing-failed` | | `Prefix`: `myFirehosePrefix/` `ErrorOutputPrefix`: Nicht angegeben | `Prefix`: `myFirehosePrefix/2018/08/27/` `ErrorOutputPrefix`: `myFirehosePrefix/processing-failed/2018/08/27/` | # Konfigurieren Sie die Indexrotation für Service OpenSearch Für das OpenSearch Serviceziel können Sie eine zeitbasierte Indexrotationsoption aus einer der folgenden fünf Optionen angeben:**NoRotation**,, **OneHour** **OneDay****OneWeek**, oder. **OneMonth** Abhängig von der von Ihnen gewählten Rotationsoption hängt Amazon Data Firehose einen Teil des UTC-Ankunftszeitstempels an Ihren angegebenen Indexnamen an. Es rotiert den angefügten Zeitstempel entsprechend. Das folgende Beispiel zeigt den resultierenden Indexnamen in OpenSearch Service für jede Indexrotationsoption, wobei sich der angegebene Indexname **myindex** und der Ankunftszeitstempel befinden. `2016-02-25T13:00:00Z` | RotationPeriod | IndexName | | --- | --- | | NoRotation | myindex | | OneHour | myindex-2016-02-25-13 | | OneDay | myindex-2016-02-25 | | OneWeek | myindex-2016-w08 | | OneMonth | myindex-2016-02 | **Anmerkung** Mit der `OneWeek`-Option erstellt Data Firehose automatisch Indizes im Format -w (z. B. `2020-w33`), wobei die Wochennummer anhand der UTC-Zeit und gemäß den folgenden US-Konventionen berechnet wird: Eine Woche beginnt am Sonntag Die erste Woche des Jahres ist die erste Woche, die in diesem Jahr einen Samstag enthält # Die Datenübermittlung unterbrechen und fortsetzen Nachdem Sie einen Firehose-Stream eingerichtet haben, werden die in der Stream-Quelle verfügbaren Daten kontinuierlich an das Ziel übermittelt. Wenn Sie auf Situationen stoßen, in denen Ihr Stream-Ziel vorübergehend nicht verfügbar ist (z. B. bei geplanten Wartungsarbeiten), sollten Sie die Datenübermittlung vorübergehend unterbrechen und fortsetzen, sobald das Ziel wieder verfügbar ist. **Wichtig** Wenn Sie den unten beschriebenen Ansatz verwenden, um einen Stream anzuhalten und fortzusetzen, werden Sie nach der Wiederaufnahme des Streams feststellen, dass nur wenige Datensätze in den Fehler-Bucket in Amazon S3 zugestellt werden, während der Rest des Streams weiterhin an das Ziel zugestellt wird. Dies ist eine bekannte Einschränkung dieses Ansatzes, die darauf zurückzuführen ist, dass eine kleine Anzahl von Datensätzen, die zuvor nach mehreren Wiederholungen nicht an das Ziel zugestellt werden konnten, als fehlgeschlagen eingestuft werden. ## Einen Firehose-Stream anhalten Um die Stream-Übertragung in Firehose zu unterbrechen, entfernen Sie zunächst die Berechtigungen für Firehose, für fehlgeschlagene Lieferungen in den S3-Backup-Speicherort zu schreiben. Wenn Sie beispielsweise den Firehose-Stream mit einem OpenSearch Ziel pausieren möchten, können Sie dies tun, indem Sie die Berechtigungen aktualisieren. Weitere Informationen finden Sie unter [Firehose Access to a Public OpenSearch Service Destination gewähren](https://docs.aws.amazon.com/firehose/latest/dev/controlling-access.html#using-iam-es). Entfernen Sie die `"Effect": "Allow"`-Berechtigung für die `s3:PutObject`-Aktion und fügen Sie explizit eine Anweisung hinzu, die die `Effect": "Deny"`-Berechtigung auf die `s3:PutObject`-Aktion für den S3-Bucket anwendet, der für die Sicherung fehlgeschlagener Lieferungen verwendet wird. Schalten Sie als Nächstes das Stream-Ziel aus (z. B. indem Sie die OpenSearch Zieldomäne ausschalten) oder entfernen Sie Firehose die Schreibberechtigungen für das Ziel. Um die Berechtigungen für andere Ziele zu aktualisieren, überprüfen Sie den Abschnitt für Ihr Ziel unter [Zugriffskontrolle mit Amazon Data Firehose](https://docs.aws.amazon.com/firehose/latest/dev/controlling-access.html). Nachdem Sie diese beiden Aktionen abgeschlossen haben, stellt Firehose die Bereitstellung von Streams ein, und Sie können dies mithilfe von [CloudWatch Metriken für Firehose](https://docs.aws.amazon.com/firehose/latest/dev/cloudwatch-metrics.html) überwachen. **Wichtig** Wenn Sie die Stream-Übertragung in Firehose unterbrechen, müssen Sie sicherstellen, dass die Quelle des Streams (z. B. in Kinesis Data Streams oder in Managed Service for Kafka) so konfiguriert ist, dass Daten beibehalten werden, bis die Stream-Zustellung wieder aufgenommen wird und die Daten an das Ziel geliefert werden. Wenn die Quelle DirectPut ist, speichert Firehose die Daten 24 Stunden lang. Es kann zu Datenverlusten kommen, wenn Sie den Stream nicht fortsetzen und die Daten nicht vor Ablauf der Datenaufbewahrungsfrist bereitstellen. ## Einen Firehose-Stream fortsetzen Um die Zustellung fortzusetzen, machen Sie zunächst die zuvor am Stream-Ziel vorgenommene Änderung rückgängig, indem Sie das Ziel aktivieren und sicherstellen, dass Firehose über die Berechtigungen verfügt, den Stream an das Ziel zu senden. Machen Sie als Nächstes die zuvor vorgenommenen Änderungen an den Berechtigungen rückgängig, die auf den S3-Bucket angewendet wurden, um fehlgeschlagene Lieferungen zu sichern. Wenden Sie die `"Effect": "Allow"`-Berechtigung für die `s3:PutObject`-Aktion an und entfernen Sie die `"Effect": "Deny"`-Berechtigung für die `s3:PutObject`-Aktion für den S3-Bucket, der für die Sicherung fehlgeschlagener Lieferungen verwendet wird. Überwachen Sie abschließend mithilfe von [CloudWatch Metriken für Firehose](https://docs.aws.amazon.com/firehose/latest/dev/cloudwatch-metrics.html), ob der Stream an das Ziel geliefert wird. Verwenden Sie [Amazon CloudWatch Logs Monitoring for Firehose](https://docs.aws.amazon.com/firehose/latest/dev/monitoring-with-cloudwatch-logs.html), um Fehler anzuzeigen und zu beheben.