Gérez les défaillances de livraison de données

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.

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.

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

Dans ces cas, Amazon Data Firehose réessaiera de livrer :

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.

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 spécifique. 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 effectue de nouvelles tentatives jusqu'à ce que la durée des nouvelles tentatives arrive à expiration. 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. 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 effectue de nouvelles tentatives jusqu'à ce que la durée des nouvelles tentatives arrive à expiration. 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

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"
}