La entrega de transmisiones de Amazon Data Firehose a Apache Iceberg Tables en Amazon S3 está en versión preliminar y está sujeta a cambios.

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Gestione los errores en la entrega de datos

Cada destino de Amazon Data Firehose tiene su propia gestión de errores en la entrega de datos.

Cuando configuras una transmisión de Firehose, para muchos destinos, como OpenSearch Splunk y HTTP endpoints, también configuras un bucket de S3 donde se pueden hacer copias de seguridad de los datos que no se pueden entregar. Para obtener más información sobre cómo Firehose hace copias de seguridad de los datos en caso de entregas fallidas, consulta las secciones de destino correspondientes de esta página. Para obtener más información sobre cómo conceder acceso a los buckets de S3 donde se pueden hacer copias de seguridad de los datos que no se entreguen, consulte Otorgar a Firehose Access to an Amazon S3 Destination. Cuando Firehose (a) no entrega los datos al destino de la transmisión y (b) no escribe los datos en el depósito S3 de respaldo en caso de entregas fallidas, detiene la entrega de la transmisión hasta que los datos puedan entregarse al destino o escribirse en la ubicación de S3 de respaldo.

Amazon S3

La entrega de datos al bucket de S3 podría generar errores por varias razones. Por ejemplo, es posible que el bucket ya no exista, que la IAM función que Amazon Data Firehose asume no tenga acceso al bucket, que la red haya fallado o que se produzcan eventos similares. En estas condiciones, Amazon Data Firehose volverá a intentarlo durante un máximo de 24 horas hasta que la entrega se realice correctamente. El tiempo máximo de almacenamiento de datos de Amazon Data Firehose es de 24 horas. Si, una vez transcurridas esas 24 horas, no se pueden entregar los datos, estos se pierden.

Amazon Redshift

Para un destino de Amazon Redshift, puede especificar una duración de reintento (de 0 a 7200 segundos) al crear una transmisión de Firehose.

La entrega de datos en su clúster aprovisionado de Amazon Redshift o grupo de trabajo de Amazon Redshift sin servidor puede fallar por varios motivos. Por ejemplo, es posible que tengas una configuración de clúster incorrecta en tu transmisión de Firehose, un clúster o grupo de trabajo en mantenimiento o un fallo de red. En estas condiciones, Amazon Data Firehose lo vuelve a intentar durante el tiempo especificado y omite ese lote concreto de objetos de Amazon S3. La información de los objetos ignorados se entrega al bucket de S3 en forma de archivo de manifiesto, en la carpeta errors/, que puede utilizar para reposiciones manuales. Para obtener información sobre cómo generar COPY datos manualmente con archivos de manifiesto, consulte Uso de un manifiesto para especificar archivos de datos.

Amazon OpenSearch Service y OpenSearch Serverless

Para el destino OpenSearch Service y OpenSearch Serverless, puedes especificar una duración de reintento (de 0 a 7200 segundos) durante la creación de la transmisión de Firehose.

La entrega de datos al clúster de OpenSearch servicios o a la recopilación OpenSearch sin servidor puede fallar por varios motivos. Por ejemplo, es posible que tengas una configuración incorrecta de un clúster de OpenSearch servicio o colección OpenSearch sin servidor de tu transmisión de Firehose, OpenSearch un clúster de servicio OpenSearch o una colección sin servidor en mantenimiento, un fallo de red o eventos similares. En estas condiciones, Amazon Data Firehose lo vuelve a intentar durante el tiempo especificado y, a continuación, omite esa solicitud de índice concreta. Los documentos ignorados se entregan al bucket de S3 en forma de archivo de manifiesto, en la carpeta AmazonOpenSearchService_failed/, que puede utilizar para reposiciones manuales.

En el OpenSearch caso del servicio, cada documento tiene el siguiente formato: JSON

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

En el OpenSearch caso de Serverless, cada documento tiene el siguiente JSON formato:

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

Cuando Amazon Data Firehose envía datos a Splunk, espera el acuse de recibo de Splunk. Si se produce un error o el acuse de recibo no llega dentro del tiempo de espera del acuse de recibo, Amazon Data Firehose inicia el contador de duración de los reintentos. Continúa intentándolo hasta que se agota el tiempo de reintento. Después de eso, Amazon Data Firehose considera que se trata de un error en la entrega de datos y realiza una copia de seguridad de los datos en su bucket de Amazon S3.

Cada vez que Amazon Data Firehose envía datos a Splunk, ya sea en el intento inicial o en un reintento, reinicia el contador de tiempo de espera de confirmación. A continuación, espera a que llegue una confirmación desde Splunk. Incluso si la duración del reintento vence, Amazon Data Firehose seguirá esperando el acuse de recibo hasta que lo reciba o se agote el tiempo de espera del acuse de recibo. Si se agota el tiempo de espera de la confirmación, Amazon Data Firehose comprueba si queda tiempo en el contador de reintentos. Si queda tiempo, vuelve a intentarlo y repite la lógica hasta que recibe una confirmación o determina que el tiempo de reintento se ha agotado.

Un error de recepción de una confirmación no es el único tipo de error de entrega de datos que puede producirse. Para obtener información sobre los demás tipos de errores de entrega de datos, consulte Errores de entrega de datos relacionados con Splunk. Cualquier error de entrega de datos desencadenará la lógica de reintentos si el tiempo de reintento es mayor que 0.

A continuación se muestra un ejemplo de registro de error.

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

HTTPdestino del punto final

Cuando Amazon Data Firehose envía datos a un destino de HTTP punto final, espera una respuesta de este destino. Si se produce un error o la respuesta no llega dentro del tiempo de espera de la respuesta, Amazon Data Firehose inicia el contador de duración de los reintentos. Continúa intentándolo hasta que se agota el tiempo de reintento. Después de eso, Amazon Data Firehose considera que se trata de un error en la entrega de datos y realiza una copia de seguridad de los datos en su bucket de Amazon S3.

Cada vez que Amazon Data Firehose envía datos a un destino de HTTP punto final, ya sea el intento inicial o un reintento, reinicia el contador de tiempo de espera de respuesta. A continuación, espera a que llegue una respuesta desde el destino del punto final. HTTP Incluso si vence la duración del reintento, Amazon Data Firehose seguirá esperando la respuesta hasta que la reciba o se agote el tiempo de espera de la respuesta. Si se agota el tiempo de espera de la respuesta, Amazon Data Firehose comprueba si queda tiempo en el contador de reintentos. Si queda tiempo, vuelve a intentarlo y repite la lógica hasta que recibe una respuesta o determina que el tiempo de reintento se ha agotado.

Un error de recepción de una respuesta no es el único tipo de error de entrega de datos que puede producirse. Para obtener información sobre los otros tipos de errores de entrega de datos, consulte Errores de entrega de datos de HTTP Endpoint

A continuación se muestra un ejemplo de registro de error.

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

Para el destino Snowflake, al crear una transmisión de Firehose, puedes especificar una duración de reintento opcional (de 0 a 7200 segundos). El valor predeterminado para la duración del reintento es de 60 segundos.

La entrega de datos a la tabla de Snowflake puede fallar por varios motivos, como una configuración de destino incorrecta de Snowflake, un fallo de red, etc. La política de reintentos no se aplica a los errores no recuperables. Por ejemplo, si Snowflake rechaza tu JSON carga porque tiene una columna extra que falta en la tabla, Firehose no intentará volver a entregarla. En su lugar, crea una copia de seguridad de todos los errores de inserción debidos a problemas de JSON carga en el depósito de errores de S3.

Del mismo modo, si se produce un error en la entrega debido a un rol, tabla o base de datos incorrectos, Firehose no lo vuelve a intentar y escribe los datos en el bucket de S3. La duración del reintento solo se aplica a los errores debidos a un problema con el servicio de Snowflake, a fallos transitorios de la red, etc. En estas condiciones, Firehose vuelve a intentarlo durante el tiempo especificado antes de entregarlos a S3. Los registros fallidos se entregan en la carpeta snowflake-failed/, que puede utilizar para rellenarlos manualmente.

El siguiente es un ejemplo de cada registro que JSON entregue a 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"
}