Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra. # Comprendre la diffusion des données dans Amazon Data Firehose Lorsque vous envoyez des données vers votre stream Firehose, elles sont automatiquement transmises à la destination que vous avez choisie. Le tableau suivant explique la livraison des données vers différentes destinations. | Destination | Détails | | --- | --- | | Amazon S3 | Pour la livraison de données à Amazon S3, Firehose concatène plusieurs enregistrements entrants en fonction de la configuration de mise en mémoire tampon de votre flux Firehose. Il diffuse ensuite les enregistrements vers Amazon S3 en tant qu'objet Amazon S3. Par défaut, Firehose concatène les données sans aucun délimiteur. [Si vous souhaitez avoir de nouveaux délimiteurs de ligne entre les enregistrements, vous pouvez ajouter de nouveaux délimiteurs de ligne en activant cette fonctionnalité dans la [configuration de la console Firehose ou](https://docs.aws.amazon.com/firehose/latest/dev/create-destination.html#create-destination-s3) dans le paramètre API.](https://docs.aws.amazon.com/firehose/latest/APIReference/API_Processor.html) La transmission des données entre Firehose et la destination Amazon S3 est cryptée avec le protocole TLS (HTTPS). | | Amazon Redshift | Pour la livraison de données à Amazon Redshift, Firehose envoie d'abord les données entrantes à votre compartiment S3 dans le format décrit précédemment. Firehose émet ensuite une commande Amazon **COPY** Redshift pour charger les données de votre compartiment S3 vers votre cluster provisionné Amazon Redshift ou votre groupe de travail Amazon Redshift Serverless. Assurez-vous qu'une fois qu'Amazon Data Firehose a concaténé plusieurs enregistrements entrants dans un objet Amazon S3, celui-ci peut être copié sur votre cluster provisionné Amazon Redshift ou votre groupe de travail Amazon Redshift Serverless. Pour plus d'informations, consultez [Paramètres du format de données de la commande COPY Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/dg/copy-parameters-data-format.html). | | OpenSearch Service et OpenSearch sans serveur | Pour la livraison de données vers OpenSearch Service et OpenSearch Serverless, Amazon Data Firehose met en mémoire tampon les enregistrements entrants en fonction de la configuration de mise en mémoire tampon de votre flux Firehose. Il génère ensuite une demande OpenSearch groupée Service ou OpenSearch Serverless pour indexer plusieurs enregistrements dans votre cluster de OpenSearch services ou votre collection OpenSearch Serverless. Assurez-vous que votre enregistrement est codé en UTF-8 et aplati en un objet JSON d'une seule ligne avant de l'envoyer à Amazon Data Firehose. En outre, l'rest.action.multi.allow\$1explicit\$1indexoption de votre cluster de OpenSearch services doit être définie sur true (par défaut) pour prendre en charge les demandes groupées avec un index explicite défini par enregistrement. Pour plus d'informations, consultez les [options avancées de configuration du OpenSearch service](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/es-createupdatedomains.html#es-createdomain-configure-advanced-options) dans le manuel Amazon OpenSearch Service Developer Guide. | | Splunk | Pour la livraison des données à Splunk, Amazon Data Firehose concatène les octets que vous envoyez. Si vous voulez des délimiteurs dans vos données, tels qu'un caractère de nouvelle ligne, vous devez les insérer par vous-même. Vérifiez que Splunk est configuré pour analyser ces délimiteurs. Pour rediriger les données qui ont été envoyées vers le compartiment d'erreur S3 (sauvegarde S3) vers Splunk, suivez les étapes mentionnées dans la documentation [Splunk](https://www.splunk.com/en_us/blog/tips-and-tricks/aws-technical-add-on-simplifying-error-data-re-ingestion.html). | | Point de terminaison HTTP | Pour la livraison de données à un point de terminaison HTTP appartenant à un fournisseur de services tiers pris en charge, vous pouvez utiliser le service intégré Amazon Lambda pour créer une fonction permettant de transformer le ou les enregistrements entrants au format correspondant au format attendu par l'intégration du fournisseur de services. Contactez le fournisseur de services tiers dont vous avez choisi le point de terminaison HTTP pour votre destination pour en savoir plus sur son format d'enregistrement accepté. | | Snowflake | Pour la transmission des données à Snowflake, Amazon Data Firehose met en mémoire tampon les données en interne pendant une seconde et utilise les opérations de l'API de streaming Snowflake pour insérer des données dans Snowflake. Par défaut, les enregistrements que vous insérez sont vidés et validés dans la table Snowflake toutes les secondes. Une fois que vous avez effectué l'appel d'insertion, Firehose émet une CloudWatch métrique qui mesure le temps nécessaire pour que les données soient validées dans Snowflake. Firehose ne prend actuellement en charge qu'un seul élément JSON comme charge utile d'enregistrement et ne prend pas en charge les tableaux JSON. Assurez-vous que votre charge utile d'entrée est un objet JSON valide et qu'elle est bien formée sans guillemets, guillemets ou caractères d'échappement supplémentaires. | Chaque destination Firehose possède sa propre fréquence de livraison des données. Pour de plus amples informations, veuillez consulter [Configurer les conseils de mise en mémoire tampon](create-configure-backup.md#buffering-hints). **Enregistrements en double** Amazon Data Firehose utilise la at-least-once sémantique pour la diffusion des données. Dans certains cas, par exemple en cas d'expiration des délais de livraison des données, les nouvelles tentatives de livraison effectuées par Amazon Data Firehose peuvent entraîner des doublons si la demande de livraison de données d'origine est finalement acceptée. Cela s'applique à tous les types de destinations pris en charge par Amazon Data Firehose, à l'exception des destinations Amazon S3, des tables Apache Iceberg et des destinations Snowflake. **Topics** + [Comprenez la livraison entre AWS les comptes et les régions](across.md) + [Comprendre les spécifications de demande et de réponse des points de terminaison HTTP](httpdeliveryrequestresponse.md) + [Gérez les défaillances de livraison de données](retry.md) + [Configurer le format du nom d'objet Amazon S3](s3-object-name.md) + [Configurer la rotation de l'index pour le OpenSearch service](es-index-rotation.md) + [Suspendre et reprendre la livraison des données](pause-restart-stream.md) # Comprenez la livraison entre AWS les comptes et les régions Amazon Data Firehose prend en charge la diffusion de données vers des destinations de point de terminaison HTTP pour tous les AWS comptes. Le flux Firehose et le point de terminaison HTTP que vous choisissez comme destination peuvent appartenir à des comptes différents AWS . Amazon Data Firehose prend également en charge la livraison de données vers des destinations de point de terminaison HTTP dans toutes les régions AWS . Vous pouvez transmettre les données d'un flux Firehose d'une AWS région à un point de terminaison HTTP d'une autre AWS région. Vous pouvez également transmettre des données d'un flux Firehose vers une destination de point de terminaison HTTP située en dehors des AWS régions, par exemple vers votre propre serveur local en définissant l'URL du point de terminaison HTTP sur la destination souhaitée. Pour ces scénarios, des frais supplémentaires de transfert de données sont ajoutés à vos frais de diffusion. Pour plus d'informations, consultez la section [Transfert de données](https://aws.amazon.com/ec2/pricing/on-demand/#Data_Transfer) sur la page « Tarification à la demande ». # Comprendre les spécifications de demande et de réponse des points de terminaison HTTP Pour qu'Amazon Data Firehose puisse transmettre des données à des points de terminaison HTTP personnalisés, ces points de terminaison doivent accepter les demandes et envoyer des réponses en utilisant certains formats de demande et de réponse Amazon Data Firehose. Cette section décrit les spécifications de format des requêtes HTTP que le service Amazon Data Firehose envoie aux points de terminaison HTTP personnalisés, ainsi que les spécifications de format des réponses HTTP attendues par le service Amazon Data Firehose. Les points de terminaison HTTP disposent de 3 minutes pour répondre à une demande avant qu'Amazon Data Firehose n'expire cette demande. Amazon Data Firehose considère les réponses qui ne respectent pas le format approprié comme des échecs de livraison. ## Format des demandes **Paramètres de chemin d'accès et d'URL** Ils sont configurés directement par vous dans le cadre d'un champ d'URL unique. Amazon Data Firehose les envoie tels que configurés, sans modification. Seules les destinations HTTPS sont prises en charge. Les restrictions d'URL sont appliquées lors de la configuration du flux de diffusion. Actuellement, seul le port 443 est pris en charge pour la diffusion des données des points de terminaison HTTP. **En-têtes HTTP - -Version X-Amz-Firehose-Protocol** Cet en-tête est utilisé pour indiquer la version des formats de demande et de réponse. Actuellement, la seule version est la version 1.0. **En-têtes HTTP - X-Amz-Firehose-Request -Id** La valeur de cet en-tête est un GUID opaque qui peut être utilisé à des fins de débogage et de déduplication. Les implémentations des points de terminaison doivent enregistrer la valeur de cet en-tête si possible, à la fois pour les requêtes réussies et pour celles qui ont échoué. L'ID de la demande reste le même entre plusieurs tentatives de la même demande. **En-têtes HTTP : Content-Type** La valeur de l'en-tête Content-Type est toujours `application/json`. **En-têtes HTTP : Content-Encoding** Un flux Firehose peut être configuré pour utiliser GZIP afin de compresser le corps lors de l'envoi de requêtes. Lorsque cette compression est activée, la valeur de l'en-tête Content-Encoding est définie sur gzip, conformément à la pratique standard. Si la compression n'est pas activée, l'en-tête Content-Encoding est totalement absent. **En-têtes HTTP : Content-Length** Ces en-têtes sont utilisés de manière standard. **En-têtes HTTP - X-Amz-Firehose-Source -Arn :** L'ARN du flux Firehose représenté au format de chaîne ASCII. L'ARN code la région, l'ID de AWS compte et le nom du flux. Par exemple, `arn:aws:firehose:us-east-1:123456789:deliverystream/testStream`. **En-têtes HTTP - -Key X-Amz-Firehose-Access** Cet en-tête contient une clé d'API ou d'autres informations d'identification. Vous avez la possibilité de créer ou de mettre à jour la clé API (ou jeton d'autorisation) lors de la création ou de la mise à jour de votre flux de diffusion. Amazon Data Firehose limite la taille de la clé d'accès à 4 096 octets. Amazon Data Firehose n'essaie en aucun cas d'interpréter cette clé. La clé configurée est copiée exactement dans la valeur de cet en-tête. Toutefois, si vous utilisez Secrets Manager pour configurer la clé, le secret doit suivre un format d'objet JSON spécifique :`{"api_key": "..."}`. Le contenu peut être arbitraire et peut potentiellement représenter un jeton JWT ou un ACCESS\$1KEY. Si un point de terminaison nécessite des informations d'identification à champs multiples (par exemple, le nom d'utilisateur et le mot de passe), les valeurs de tous les champs doivent être stockées ensemble dans une seule clé d'accès dans un format que le point de terminaison comprend (JSON ou CSV). Ce champ peut être codé en base 64 si le contenu d'origine est binaire. Amazon Data Firehose ne modifie pas le and/or code de la valeur configurée et utilise le contenu tel quel. **En-têtes HTTP - X-Amz-Firehose-Common -Attributs** Cet en-tête contient les attributs communs (métadonnées) relatifs à l'ensemble de la demande, and/or à tous les enregistrements de la demande. Vous les configurez directement lors de la création d'un stream Firehose. La valeur de cet attribut est codée sous la forme d'un objet JSON avec le schéma suivant : ``` "$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 ``` Voici un exemple : ``` "commonAttributes": { "deployment -context": "pre-prod-gamma", "device-types": "" } ``` **Corps : taille maximale** Vous définissez vous-même la taille maximale du corps, qui peut aller jusqu'à 64 Mio, avant compression. **Corps : schéma** Le corps contient un seul document JSON avec le schéma JSON suivant (écrit en YAML) : ``` "$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 ``` Voici un exemple : ``` { "requestId": "ed4acda5-034f-9f42-bba1-f29aea6d7d8f", "timestamp": 1578090901599 "records": [ { "data": "aGVsbG8=" }, { "data": "aGVsbG8gd29ybGQ=" } ] } ``` ## Format de la réponse **Comportement par défaut en cas d'erreur** Si une réponse n'est pas conforme aux exigences ci-dessous, le serveur Firehose la traite comme si elle avait un code d'état 500 sans corps. **Code d'état** Le code d'état HTTP DOIT être dans la plage 2XX, 4XX ou 5XX. Le serveur Amazon Data Firehose ne suit PAS les redirections (codes d'état 3XX). Seul le code de réponse 200 est considéré comme une diffusion réussie des enregistrements vers HTTP/EP. Le code de réponse 413 (taille dépassée) est considéré comme une défaillance permanente et le lot d'enregistrements n'est pas envoyé au compartiment d'erreurs s'il est configuré. Tous les autres codes de réponse sont considérés comme des erreurs réitérables et sont soumis à l'algorithme de tentative de retardement expliqué plus loin. **En-têtes HTTP : type de contenu** Le seul type de contenu acceptable est application/json. **En-têtes HTTP : Content-Encoding** Content-Encoding NE DOIT PAS être utilisé. Le corps DOIT être décompressé. **En-têtes HTTP : Content-Length** L'en-tête Content-Length DOIT être présent si la réponse a un corps. **Corps : taille maximale** La taille du corps de la réponse doit être inférieure ou égale à 1 Mio. ``` "$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 ``` Voici un exemple : ``` 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 } ``` **Gestion des réponses d'erreur** Dans tous les cas d'erreur, le serveur Amazon Data Firehose tente à nouveau de livrer le même lot d'enregistrements à l'aide d'un algorithme de réduction exponentielle. Les nouvelles tentatives sont annulées en utilisant un temps d'attente initial (1 seconde) avec un facteur de gigue de (15 %) et chaque nouvelle tentative suivante est annulée en utilisant la formule (initial-backoff-time \$1 (multiplicateur (2) ^ retry\$1count)) avec une instabilité ajoutée. Le temps de retard est limité à un intervalle maximal de deux minutes. Par exemple, lors de la neuvième tentative, le temps de retour est = MAX (120, 2^n) \$1 random (0,85, 1,15). Les paramètres spécifiés dans l'équation précédente sont susceptibles d'être modifiés. Reportez-vous à la documentation de AWS Firehose pour connaître le temps d'arrêt initial exact, le temps d'arrêt maximal, le multiplicateur et les pourcentages de gigue utilisés dans l'algorithme de ralentissement exponentiel. À chaque nouvelle tentative suivante, la and/or destination de la clé d'accès à laquelle les enregistrements sont livrés peut changer en fonction de la configuration mise à jour du flux Firehose. Le service Amazon Data Firehose utilise le même identifiant de demande pour chaque nouvelle tentative, dans le meilleur des cas. Cette dernière fonctionnalité peut être utilisée à des fins de déduplication par le serveur de point de terminaison HTTP. Si la demande n'est toujours pas livrée après le délai maximum autorisé (selon la configuration du flux Firehose), le lot d'enregistrements peut éventuellement être envoyé vers un compartiment d'erreur basé sur la configuration du flux. ## Exemples Exemple de demande CWLog provenant d'une source. ``` { "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" } ] } } ] } ``` # Gérez les défaillances de livraison de données Chaque destination Amazon Data Firehose dispose de sa propre gestion des défaillances de livraison de données. Lorsque vous configurez un flux Firehose, pour de nombreuses destinations telles que OpenSearch Splunk et les points de terminaison HTTP, vous configurez également un compartiment S3 dans lequel les données qui ne sont pas livrées peuvent être sauvegardées. Pour plus d'informations sur la façon dont Firehose sauvegarde les données en cas d'échec de livraison, consultez les sections de destination correspondantes sur cette page. Pour plus d'informations sur la façon d'accorder l'accès aux compartiments S3 dans lesquels les données qui ne sont pas livrées peuvent être sauvegardées, consultez [Accorder l'accès à Firehose à une destination Amazon S3](https://docs.aws.amazon.com/firehose/latest/dev/controlling-access.html#using-iam-s3). Lorsque Firehose (a) ne parvient pas à fournir les données à la destination du flux et (b) ne parvient pas à écrire les données dans le compartiment S3 de sauvegarde en cas d'échec des livraisons, il suspend effectivement la diffusion du flux jusqu'à ce que les données puissent être livrées à la destination ou écrites sur l'emplacement de sauvegarde S3. ## Amazon S3 La diffusion de données à votre compartiment S3 peut échouer pour plusieurs raisons. Par exemple, il se peut que le compartiment n'existe plus, que le rôle IAM assumé par Amazon Data Firehose n'ait pas accès au compartiment, que le réseau soit défaillant ou que des événements similaires se produisent. Dans ces conditions, Amazon Data Firehose continue de réessayer pendant 24 heures au maximum jusqu'à ce que la livraison aboutisse. La durée maximale de stockage des données d'Amazon Data Firehose est de 24 heures. En cas de défaillance de leur diffusion pendant plus de 24 heures, vos données sont perdues. La livraison des données vers votre compartiment S3 peut échouer pour diverses raisons, telles que : + Le bucket n'existe plus. + Le rôle IAM assumé par Amazon Data Firehose n'a pas accès au compartiment. + Problèmes liés au réseau. + Des erreurs S3, telles que des erreurs HTTP 500 ou d'autres défaillances d'API. Dans ces cas, Amazon Data Firehose essaiera à nouveau de livrer : + **DirectPut sources : Les** nouvelles tentatives se poursuivent pendant 24 heures au maximum. + **Sources Kinesis Data Streams ou Amazon MSK** : les nouvelles tentatives se poursuivent indéfiniment, dans la limite de la politique de rétention définie dans le flux. Amazon Data Firehose envoie les enregistrements défaillants à un compartiment d'erreur S3 uniquement en cas d'échec du traitement Lambda ou de la conversion du parquet. D'autres scénarios d'échec entraîneront des tentatives continues de réessayer S3 jusqu'à ce que la période de rétention soit atteinte. Lorsque Firehose livre avec succès des enregistrements à S3, il crée un fichier objet S3, et en cas d'échec partiel des enregistrements, il tente automatiquement de le livrer à nouveau et met à jour le même fichier objet S3 avec les enregistrements traités avec succès. ## Amazon Redshift Pour une destination Amazon Redshift, vous pouvez spécifier une durée de nouvelle tentative (0 à 7 200 secondes) lors de la création d'un flux Firehose. La diffusion des données à votre cluster Amazon Redshift ou à votre groupe de travail Amazon Redshift sans serveur peut échouer pour plusieurs raisons. Par exemple, vous pouvez avoir une configuration de cluster incorrecte pour votre flux Firehose, un cluster ou un groupe de travail en maintenance, ou une panne réseau. Dans ces conditions, Amazon Data Firehose réessaie pendant la durée spécifiée et ignore ce lot spécifique d'objets Amazon S3. Les informations concernant les documents ignorés sont transmises à votre compartiment S3 en tant que fichier manifeste dans le dossier `errors/` que vous pouvez utiliser pour le renvoi manuel. Pour plus d'informations sur la manière de COPIER manuellement des données à l'aide de fichiers manifestes, consultez [Utilisation d'un manifeste pour spécifier les fichiers de données](https://docs.aws.amazon.com/redshift/latest/dg/loading-data-files-using-manifest.html). ## Amazon OpenSearch Service et OpenSearch Serverless Pour la destination OpenSearch Service et OpenSearch Serverless, vous pouvez spécifier une durée de nouvelle tentative (0 à 7 200 secondes) lors de la création du stream Firehose. La livraison des données à votre cluster OpenSearch de services ou à votre collecte OpenSearch sans serveur peut échouer pour plusieurs raisons. Par exemple, vous pouvez avoir une configuration de cluster de OpenSearch services ou de collecte OpenSearch sans serveur incorrecte pour votre flux Firehose, OpenSearch un cluster de services OpenSearch ou une collection sans serveur en cours de maintenance, une panne réseau ou des événements similaires. Dans ces conditions, Amazon Data Firehose réessaie pendant la durée spécifiée, puis ignore cette demande d'index en particulier. Les documents ignorés sont transmis à votre compartiment S3 dans le dossier `AmazonOpenSearchService_failed/` que vous pouvez utiliser pour le renvoi manuel. Pour le OpenSearch service, chaque document possède le format JSON suivant : ``` { "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)" } ``` Pour OpenSearch Serverless, chaque document possède le format JSON suivant : ``` { "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 Lorsqu'Amazon Data Firehose envoie des données à Splunk, il attend un accusé de réception de Splunk. En cas d'erreur ou si l'accusé de réception n'arrive pas dans le délai imparti, Amazon Data Firehose lance le compteur de durée des nouvelles tentatives. Il continue de réessayer jusqu'à ce que la durée de la nouvelle tentative expire. Après cela, Amazon Data Firehose considère qu'il s'agit d'un échec de livraison des données et sauvegarde les données dans votre compartiment Amazon S3. Chaque fois qu'Amazon Data Firehose envoie des données à Splunk, qu'il s'agisse d'une première tentative ou d'une nouvelle tentative, il redémarre le compteur de délais d'accusé de réception. Ensuite, il attend un accusé de réception de la part de Splunk. Même si la durée de la nouvelle tentative expire, Amazon Data Firehose attend toujours l'accusé de réception jusqu'à ce qu'il le reçoive ou que le délai d'expiration de l'accusé de réception soit atteint. Si l'accusé de réception expire, Amazon Data Firehose vérifie s'il reste du temps dans le compteur de nouvelles tentatives. Si c'est le cas, il réitère les tentatives et répète la logique jusqu'à ce qu'il reçoive un accusé de réception ou qu'il détermine que le délai imparti pour les nouvelles tentatives est arrivé à son terme. Le défaut de réception d'un accusé de réception n'est pas le seul type d'erreur de remise de données possible. Pour en savoir plus sur les autres types d'erreurs de remise de données, consultez [Erreurs de livraison de données Splunk](https://docs.aws.amazon.com/firehose/latest/dev/monitoring-with-cloudwatch-logs.html#monitoring-splunk-errors). Les erreurs de remise de données déclenchent la logique de relance si votre durée des nouvelles tentatives est supérieure à 0. Voici un exemple d'enregistrement d'erreur. ``` { "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" } ``` ## Destination du point de terminaison HTTP Lorsqu'Amazon Data Firehose envoie des données vers une destination de point de terminaison HTTP, il attend une réponse de cette destination. En cas d'erreur ou si la réponse n'arrive pas dans le délai imparti, Amazon Data Firehose lance le compteur de durée des nouvelles tentatives. Il continue de réessayer jusqu'à ce que la durée de la nouvelle tentative expire. Après cela, Amazon Data Firehose considère qu'il s'agit d'un échec de livraison des données et sauvegarde les données dans votre compartiment Amazon S3. Chaque fois qu'Amazon Data Firehose envoie des données vers une destination de point de terminaison HTTP, qu'il s'agisse d'une tentative initiale ou d'une nouvelle tentative, il redémarre le compteur de délais de réponse. Il attend ensuite qu'une réponse arrive de la destination du point de terminaison HTTP. Même si le délai de réessai expire, Amazon Data Firehose attend toujours la réponse jusqu'à ce qu'il la reçoive ou que le délai de réponse soit atteint. Si le délai de réponse est dépassé, Amazon Data Firehose vérifie s'il reste du temps dans le compteur de nouvelles tentatives. Si c'est le cas, il réitère les tentatives et répète la logique jusqu'à ce qu'il reçoive une réponse ou qu'il détermine que le délai imparti pour les nouvelles tentatives est arrivé à son terme. Le défaut de réception d'une réponse n'est pas le seul type d'erreur de remise de données possible. Pour en savoir plus sur les autres types d'erreurs de remise de données, consultez [HTTP Endpoint Data Delivery Errors](https://docs.aws.amazon.com/firehose/latest/dev/monitoring-with-cloudwatch-logs.html#monitoring-http-errors) Voici un exemple d'enregistrement d'erreur. ``` { "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 Pour la destination Snowflake, lorsque vous créez un stream Firehose, vous pouvez spécifier une durée de nouvelle tentative facultative (0 à 7 200 secondes). La valeur par défaut pour la durée des nouvelles tentatives est de 60 secondes. La livraison des données vers votre table Snowflake peut échouer pour plusieurs raisons, telles qu'une configuration de destination Snowflake incorrecte, une panne de Snowflake, une défaillance du réseau, etc. La politique de nouvelle tentative ne s'applique pas aux erreurs non récupérables. Par exemple, si Snowflake rejette votre charge utile JSON parce qu'une colonne supplémentaire est manquante dans le tableau, Firehose n'essaie pas de la livrer à nouveau. Il crée plutôt une sauvegarde pour tous les échecs d'insertion dus à des problèmes de charge utile JSON dans votre compartiment d'erreurs S3. De même, si la livraison échoue en raison d'un rôle, d'une table ou d'une base de données incorrects, Firehose ne réessaie pas et écrit les données dans votre compartiment S3. La durée de la nouvelle tentative ne s'applique qu'en cas d'échec dû à un problème de service Snowflake, à des problèmes réseau transitoires, etc. Dans ces conditions, Firehose réessaie pendant la durée spécifiée avant de les transmettre à S3. Les enregistrements défaillants sont livrés dans le dossier snowflake-failed/, que vous pouvez utiliser pour le remplissage manuel. Voici un exemple de JSON pour chaque enregistrement que vous transmettez à S3. ``` { "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" } ``` # Configurer le format du nom d'objet Amazon S3 Lorsque Firehose fournit des données à Amazon S3, le nom de la clé de l'objet S3 suit le format** , où le suffixe a le format *- - - - - - -* commence par 1 et augmente de 1 pour chaque changement de configuration du flux Firehose. Vous pouvez modifier les configurations de flux Firehose (par exemple, le nom du compartiment S3, les indications de mise en mémoire tampon, la compression et le chiffrement). Vous pouvez le faire à l'aide de la console Firehose ou de l'opération [UpdateDestination](https://docs.aws.amazon.com/firehose/latest/APIReference/API_UpdateDestination.html)API. Pour**, Firehose ajoute un préfixe d'heure par défaut au format. `YYYY/MM/dd/HH` Ce préfixe crée une hiérarchie logique dans le compartiment, où chaque barre oblique (/) crée un niveau dans la hiérarchie. Vous pouvez modifier cette structure en spécifiant un préfixe personnalisé qui inclut les expressions évaluées lors de l'exécution. Pour plus d'informations sur la manière de spécifier un préfixe personnalisé, consultez la section [Préfixes personnalisés pour les objets Amazon Simple Storage Service](https://docs.aws.amazon.com/firehose/latest/dev/s3-prefixes.html). Par défaut, le fuseau horaire utilisé pour le préfixe et le suffixe est en UTC, mais vous pouvez le modifier pour le fuseau horaire de votre choix. Par exemple, pour utiliser l'heure normale du Japon au lieu de l'heure UTC, vous pouvez configurer le fuseau horaire Asia/Tokyo dans AWS Management Console le [paramètre ou dans l'API CustomTimeZone (](https://docs.aws.amazon.com/firehose/latest/APIReference/API_ExtendedS3DestinationConfiguration.html)). La liste suivante contient les fuseaux horaires pris en charge par Firehose pour la configuration du préfixe S3. ## Fuseaux horaires pris en charge Voici une liste des fuseaux horaires pris en charge par Firehose pour la configuration du préfixe S3. ------ #### [ 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 ``` ------ Vous ne pouvez pas modifier le champ du suffixe sauf**. Lorsque vous activez la conversion ou la compression des formats de données, Firehose ajoute une extension de fichier en fonction de la configuration. Le tableau suivant explique l'extension de fichier par défaut ajoutée par Firehose : | Configuration | Extension de fichier | | --- | --- | | Conversion de format de données : parquet | .parquet | | Conversion de format de données : ORC | .orc | | Compression : Gzip | .gz | | Compression : fermeture éclair | .zip | | Compression : Snappy | .snappy | | Compression : Hadoop-Snappy | .hsnappy | Vous pouvez également spécifier l'extension de fichier que vous préférez dans la console ou l'API Firehose. L'extension de fichier doit commencer par un point (.) et peut contenir les caractères autorisés : 0-9a-z \$1 -\$1.\$1' (). L'extension de fichier ne peut pas dépasser 128 caractères. **Note** Lorsque vous spécifiez une extension de fichier, elle remplace l'extension de fichier par défaut ajoutée par Firehose [lorsque la conversion ou la compression des formats de données sont](https://docs.aws.amazon.com/firehose/latest/dev/record-format-conversion.html) activées. # Comprendre les préfixes personnalisés pour les objets Amazon S3 Les objets livrés à Amazon S3 suivent le [format de nom](https://docs.aws.amazon.com/firehose/latest/dev/basic-deliver.html#s3-object-namekey) de . Vous pouvez spécifier votre préfixe personnalisé qui inclut les expressions évaluées lors de l'exécution. Le préfixe personnalisé que vous spécifiez remplacera le préfixe par défaut de. `yyyy/MM/dd/HH` Vous pouvez utiliser les expressions ayant le format suivant dans votre préfixe personnalisé : `!{namespace:value}`, où `namespace` peut être l'un des éléments suivants, comme expliqué dans les sections suivantes. + `firehose` + `timestamp` + `partitionKeyFromQuery` + `partitionKeyFromLambda` Si un préfixe se termine par une barre oblique, il apparaît comme dossier dans le compartiment Amazon S3. Pour plus d'informations, consultez le [format du nom d'objet Amazon S3](https://docs.aws.amazon.com/firehose/latest/dev/basic-deliver.html#s3-object-name) dans le *Amazon Data FirehoseDeveloper Guide*. ## Espace de noms `timestamp` Les valeurs valides pour cet espace de noms sont des DateTimeFormatter chaînes [Java](https://docs.oracle.com/javase/8/docs/api/java/time/format/DateTimeFormatter.html) valides. Par exemple, au cours de l'année 2018, l'expression `!{timestamp:yyyy}` est évaluée sur `2018`. Lors de l'évaluation des horodatages, Firehose utilise l'horodatage d'arrivée approximatif du plus ancien enregistrement contenu dans l'objet Amazon S3 en cours d'écriture. Par défaut, l'horodatage est en UTC. Mais vous pouvez spécifier le fuseau horaire que vous préférez. Par exemple, vous pouvez configurer le fuseau horaire dans AWS Management Console ou Asia/Tokyo dans le réglage des paramètres de l'API ([CustomTimeZone](https://docs.aws.amazon.com/firehose/latest/APIReference/API_ExtendedS3DestinationConfiguration.html)) si vous souhaitez utiliser l'heure normale du Japon au lieu de l'heure UTC. Pour consulter la liste des fuseaux horaires pris en charge, consultez [Amazon S3 Object Name Format](https://docs.aws.amazon.com/firehose/latest/dev/basic-deliver.html#s3-object-name). Si vous utilisez l'espace de noms `timestamp` plusieurs fois dans la même expression de préfixe, chaque instance est évaluée sur le même instantané dans le temps. ## Espace de noms `firehose` Il existe deux valeurs que vous pouvez utiliser avec cet espace de noms : `error-output-type` et `random-string`. Le tableau suivant explique comment les utiliser. **Les valeurs de l'espace de noms `firehose`** | Conversion | Description | Exemple d'entrée | Exemple de sortie | Remarques | | --- | --- | --- | --- | --- | | error-output-type | Évalue l'une des chaînes suivantes, en fonction de la configuration de votre stream Firehose et de la raison de l'échec : \$1processing-failed, -failed, splunk-failed AmazonOpenSearchService,,\$1. format-conversion-failed http-endpoint-failedSi vous utilisez l'espace de noms plusieurs fois dans la même expression, chaque instance est évaluée sur la même chaîne d'erreur. | myPrefix/result=\$1\$1firehose:error-output-type\$1/\$1\$1timestamp:yyyy/MM/dd\$1 | myPrefix/result=processing-failed/2018/08/03 | La error-output-type valeur ne peut être utilisée que dans le ErrorOutputPrefix champ. | | random-string | Évaluation sur une chaîne aléatoire de 11 caractères. Si vous utilisez l'espace de noms plusieurs fois dans la même expression, chaque instance est évaluée sur une nouvelle chaîne aléatoire. | myPrefix/\$1\$1firehose:random-string\$1/ | myPrefix/046b6c7f-0b/ | Vous pouvez l'utiliser avec les deux types de préfixe.Vous pouvez le placer au début de la chaîne de format pour obtenir un préfixe aléatoire, ce qui est parfois nécessaire pour atteindre un débit extrêmement élevé avec Amazon S3. | ## Espaces de noms `partitionKeyFromLambda` et `partitionKeyFromQuery` Pour le [partitionnement dynamique](dynamic-partitioning.md), vous devez utiliser le format d'expression suivant dans le préfixe de votre compartiment S3 : `!{namespace:value}`, où l'espace de noms peut être `partitionKeyFromQuery` ou `partitionKeyFromLambda`, ou les deux. Si vous utilisez l'analyse en ligne pour créer les clés de partitionnement de vos données sources, vous devez spécifier une valeur de préfixe de compartiment S3 qui consiste en des expressions spécifiées dans le format suivant : `"partitionKeyFromQuery:keyID"`. Si vous utilisez une fonction AWS Lambda pour créer les clés de partitionnement de vos données sources, vous devez spécifier une valeur de préfixe de compartiment S3 qui consiste en des expressions spécifiées dans le format suivant : `"partitionKeyFromLambda:keyID"`. Pour plus d'informations, consultez la section « Choisissez Amazon S3 pour votre destination » dans [Création d'un flux Amazon Firehose](basic-create.md#basic-create.title). ## Règles sémantiques Les règles suivantes s'appliquent aux expressions `Prefix` et `ErrorOutputPrefix`. + Pour l'espace de noms `timestamp`, n'importe quel caractère autre que des guillemets simples est évalué. En d'autres termes, n'importe quelle chaîne dans une séquence d'échappement avec des guillemets simples dans le champ value est prise littéralement. + Si vous spécifiez un préfixe qui ne contient pas d'expression d'espace de noms d'horodatage, Firehose ajoute l'expression `!{timestamp:yyyy/MM/dd/HH/}` à la valeur du champ. `Prefix` + La séquence `!{` peut uniquement apparaître dans les expressions `!{namespace:value}`. + `ErrorOutputPrefix` peut être null uniquement si `Prefix` ne contient pas d'expressions. Dans ce cas, `Prefix` correspond à `yyyy/MM/DDD/HH/` et `ErrorOutputPrefix` correspond à `yyyy/MM/DDD/HH/`. `DDD` représente le jour de l'année. + Si vous spécifiez une expression pour `ErrorOutputPrefix`, vous devez inclure au moins une instance de `!{firehose:error-output-type}`. + `Prefix` ne peut pas contenir `!{firehose:error-output-type}`. + Ni `Prefix` ni `ErrorOutputPrefix` ne peuvent être supérieurs à 512 caractères après leur évaluation. + Si la destination est Amazon Redshift, `Prefix` ne doit pas contenir d'expressions et `ErrorOutputPrefix` doit être null. + Lorsque la destination est Amazon OpenSearch Service ou Splunk, et qu'aucune n'`ErrorOutputPrefix`est spécifiée, Firehose utilise `Prefix` le champ pour les enregistrements ayant échoué. + Lorsque la destination est Amazon S3, les préfixes `Prefix` et `ErrorOutputPrefix` dans la configuration de destination Amazon S3 sont utilisés pour les enregistrements ayant réussi et les enregistrements ayant échoué, respectivement. Si vous utilisez AWS CLI ou l'API, vous pouvez utiliser `ExtendedS3DestinationConfiguration` pour spécifier une configuration de *sauvegarde* Amazon S3 avec ses propres préfixes `Prefix` et `ErrorOutputPrefix`. + Lorsque vous utilisez le AWS Management Console et définissez la destination sur Amazon S3, Firehose utilise le `Prefix` et `ErrorOutputPrefix` dans la configuration de destination pour les enregistrements réussis et les enregistrements échoués, respectivement. Si vous spécifiez un préfixe à l'aide d'expressions, vous devez spécifier le préfixe d'erreur, y compris. `!{firehose:error-output-type}` + Lorsque vous utilisez `ExtendedS3DestinationConfiguration` l'API ou AWS CLI, si vous spécifiez une CloudFormation`S3BackupConfiguration`, Firehose ne fournit pas de valeur par défaut. `ErrorOutputPrefix` + Vous ne pouvez pas utiliser `partitionKeyFromLambda` d'`partitionKeyFromQuery`espaces de noms lorsque vous créez des ErrorOutputPrefix expressions. ## Exemples de préfixe **Exemples de préfixes `Prefix` et `ErrorOutputPrefix`** | Input | Préfixe évalué (à 10:30 AM UTC le 27août2018) | | --- | --- | | `Prefix` : non spécifié `ErrorOutputPrefix`: `myFirehoseFailures/!{firehose:error-output-type}/` | `Prefix`: `2018/08/27/10` `ErrorOutputPrefix`: `myFirehoseFailures/processing-failed/` | | `Prefix`: `!{timestamp:yyyy/MM/dd}` `ErrorOutputPrefix` : non spécifié | Saisie non valide : ErrorOutputPrefix ne peut pas être vide si le préfixe contient des expressions | | `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` : non spécifié | `Prefix`: `myFirehosePrefix/2018/08/27/` `ErrorOutputPrefix`: `myFirehosePrefix/processing-failed/2018/08/27/` | # Configurer la rotation de l'index pour le OpenSearch service Pour la destination du OpenSearch service, vous pouvez spécifier une option de rotation d'index basée sur le temps parmi l'une des cinq options suivantes : **NoRotation****OneHour**,, **OneDay****OneWeek**, ou**OneMonth**. En fonction de l'option de rotation que vous choisissez, Amazon Data Firehose ajoute une partie de l'horodatage d'arrivée UTC au nom d'index que vous avez spécifié. Il effectue une rotation de cet horodatage en conséquence. L'exemple suivant montre le nom d'index obtenu dans OpenSearch Service pour chaque option de rotation d'index, où le nom d'index spécifié est **myindex** et l'horodatage d'arrivée est. `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 | **Note** Avec l'option `OneWeek`, Data Firehose crée automatiquement des index au format -w (par exemple, `2020-w33`), où le numéro de semaine est calculé en utilisant l'heure universelle coordonnées (UTC) et selon les conventions américaines suivantes : Une semaine commence le dimanche La première semaine de l'année est la première semaine de l'année qui contient un samedi. # Suspendre et reprendre la livraison des données Une fois que vous avez configuré un flux Firehose, les données disponibles dans la source du flux sont continuellement transmises à la destination. Si la destination de votre flux est temporairement indisponible (par exemple, lors d'opérations de maintenance planifiées), vous pouvez interrompre temporairement la transmission des données et la reprendre lorsque la destination redevient disponible. **Important** Lorsque vous utilisez l'approche décrite ci-dessous pour suspendre et reprendre un flux, après la reprise du flux, vous constaterez que peu d'enregistrements sont envoyés au compartiment d'erreur d'Amazon S3, tandis que le reste du flux continue d'être livré à destination. Il s'agit d'une limite connue de l'approche, qui se produit parce qu'un petit nombre d'enregistrements qui n'ont pas pu être livrés à destination auparavant après plusieurs tentatives sont considérés comme ayant échoué. ## Suspendre un stream Firehose Pour suspendre la diffusion de flux dans Firehose, supprimez d'abord les autorisations permettant à Firehose d'écrire sur l'emplacement de sauvegarde S3 en cas d'échec de diffusion. Par exemple, si vous souhaitez suspendre le stream Firehose avec une OpenSearch destination, vous pouvez le faire en mettant à jour les autorisations. Pour plus d'informations, voir [Accorder à Firehose l'accès à une destination de OpenSearch service public](https://docs.aws.amazon.com/firehose/latest/dev/controlling-access.html#using-iam-es). Supprimez l'autorisation `"Effect": "Allow"` pour l'action `s3:PutObject`, et ajoutez explicitement une instruction qui applique l'autorisation `Effect": "Deny"` sur l'action `s3:PutObject` pour le compartiment S3 utilisé pour sauvegarder les diffusions qui ont échoué. Ensuite, désactivez la destination du flux (par exemple, désactivez le OpenSearch domaine de destination) ou supprimez les autorisations permettant à Firehose d'écrire sur la destination. Pour mettre à jour les autorisations pour d'autres destinations, consultez la section relative à votre destination dans [Contrôler l'accès avec Amazon Data Firehose](https://docs.aws.amazon.com/firehose/latest/dev/controlling-access.html). Une fois ces deux actions effectuées, Firehose cessera de diffuser des streams, et vous pourrez surveiller cela à l'aide des [CloudWatch métriques de Firehose](https://docs.aws.amazon.com/firehose/latest/dev/cloudwatch-metrics.html). **Important** Lorsque vous suspendez la diffusion d'un flux dans Firehose, vous devez vous assurer que la source du flux (par exemple, dans Kinesis Data Streams ou dans Managed Service for Kafka) est configurée pour conserver les données jusqu'à ce que la diffusion du flux reprenne et que les données soient livrées à la destination. Si la source est DirectPut, Firehose conservera les données pendant 24 heures. Une perte de données peut se produire si vous ne reprenez pas le flux et ne diffusez pas les données avant l'expiration de la période de conservation des données. ## Reprendre un stream Firehose Pour reprendre la diffusion, annulez d'abord la modification apportée précédemment à la destination du flux en activant la destination et en vous assurant que Firehose dispose des autorisations nécessaires pour diffuser le flux vers la destination. Ensuite, annulez les modifications apportées précédemment aux autorisations appliquées au compartiment S3 pour la sauvegarde des diffusions ayant échoué. En d'autres termes, appliquez l'autorisation `"Effect": "Allow"` pour l'action `s3:PutObject`, et supprimez l'autorisation `"Effect": "Deny"` sur l'action `s3:PutObject` pour le compartiment S3 utilisé pour sauvegarder les diffusions qui ont échoué. Enfin, surveillez l'utilisation de [CloudWatch métriques pour Firehose](https://docs.aws.amazon.com/firehose/latest/dev/cloudwatch-metrics.html) afin de confirmer que le flux est envoyé à destination. Pour consulter et résoudre les erreurs, utilisez le système de [surveillance Amazon CloudWatch Logs pour Firehose](https://docs.aws.amazon.com/firehose/latest/dev/monitoring-with-cloudwatch-logs.html).