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.
Cada destino de Amazon Data Firehose tiene su propia gestión de errores en la entrega de datos.
Cuando configuras una transmisión Firehose, para muchos destinos, como OpenSearch Splunk y puntos de conexión HTTP, también configuras un bucket de S3 en el que se pueden hacer copias de seguridad de los datos que no se puedan entregar. Para obtener más información sobre cómo Firehose hace copias de seguridad de los datos en caso de errores de entrega, consulte 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 pueden entregar, consulte Concesión a Firehose de acceso a un destino de Amazon S3. Cuando Firehose (a) no puede entregar los datos en el destino del flujo y (b) no puede escribir los datos en el bucket de S3 de copias de seguridad en caso de entregas con errores, pausa de forma efectiva la entrega del flujo hasta que los datos puedan entregarse en el destino o escribirse en la ubicación de S3 de copias de seguridad.
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 el rol de IAM adoptado por Amazon Data Firehose no tenga acceso al bucket, que se haya producido un error de red o cualquier otro evento parecido. En esos casos, Amazon Data Firehose intenta llevar a cabo de nuevo la entrega durante un máximo de 24 horas hasta que se completa. 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.
La entrega de datos a tu depósito de S3 puede fallar por varios motivos, como los siguientes:
-
El depósito ya no existe.
-
La función de IAM que asume Amazon Data Firehose carece de acceso al bucket.
-
Problemas de red.
-
Errores de S3, como errores de HTTP 500 u otros errores de API.
En estos casos, Amazon Data Firehose volverá a intentar la entrega:
-
DirectPut fuentes: los reintentos continúan durante un máximo de 24 horas.
-
Fuentes de Kinesis Data Streams o Amazon MSK: los reintentos continúan indefinidamente, hasta cumplir con la política de retención definida en la transmisión.
Amazon Data Firehose envía los registros fallidos a un depósito de errores de S3 solo cuando se produce un error en el procesamiento de Lambda o en la conversión de parquet. Otros escenarios de error provocarán reintentos continuos con S3 hasta que se alcance el período de retención. Cuando Firehose entrega correctamente los registros a S3, crea un archivo de objetos de S3 y, en caso de errores parciales en los registros, vuelve a intentar la entrega automáticamente y actualiza el mismo archivo de objetos de S3 con los registros procesados correctamente.
Amazon Redshift
Si el destino es Amazon Redshift, puede especificar durante cuánto tiempo reintentar la entrega (entre 0 y 7200 segundos) al crear un flujo 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, puede que haya una configuración de clúster incorrecta en el flujo de Firehose, que un clúster o grupo de trabajo esté en mantenimiento o que se haya producido un error de red. En estos casos, Amazon Data Firehose reintenta la entrega durante el tiempo especificado e ignora 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 más información acerca de cómo usar el comando COPY para copiar 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 estos casos, Amazon Data Firehose reintenta la entrega durante el tiempo especificado e ignora esa solicitud de indexación 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 de Service, 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 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 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 recibir una confirmación de Splunk. Si se produce un error o la confirmación no llega dentro del periodo de tiempo de espera de confirmación, Amazon Data Firehose pone en marcha el contador de tiempo de reintento. 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 de entrega de datos y crea una copia de seguridad de los datos en el 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. Aunque se agote el tiempo de reintento, Amazon Data Firehose sigue esperando la confirmación hasta que la recibe o hasta que finaliza el tiempo de espera de confirmación. Si se agota el tiempo de espera de confirmación, Amazon Data Firehose comprueba para determinar si queda tiempo en el contador de reintento. 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"
}Destino de punto de conexión HTTP
Cuando Amazon Data Firehose envía datos a un destino de punto de conexión HTTP, espera una respuesta de este destino. Si se produce un error o la respuesta no llega dentro del periodo de tiempo de espera de respuesta, Amazon Data Firehose pone en marcha el contador de tiempo de reintento. 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 de entrega de datos y crea una copia de seguridad de los datos en el bucket de Amazon S3.
Cada vez que Amazon Data Firehose envía datos a un destino de punto de conexión HTTP, ya sea en el intento inicial o en un reintento, reinicia el contador de tiempo de espera de respuesta. A continuación, espera a que llegue una respuesta del destino de punto de conexión HTTP. Aunque se agote el tiempo de reintento, Amazon Data Firehose sigue esperando la respuesta hasta que la recibe o hasta que finaliza el tiempo de espera de respuesta. Si se agota el tiempo de espera de respuesta, Amazon Data Firehose determina si queda tiempo en el contador de reintento. 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 demás tipos de errores de entrega de datos, consulte HTTP Endpoint Data Delivery Errors.
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
Si el destino es Snowflake, puede especificar una duración de reintento opcional (de 0 a 7200 segundos) cuando crea un flujo de Firehose. El valor de predeterminado para la duración de 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 de Snowflake incorrecta, una interrupción 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 su carga útil de JSON porque hay una columna adicional 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 carga útil de JSON en el bucket 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 estos casos, Firehose aplica el reintento durante el tiempo especificado antes de entregarlo en S3. Los registros fallidos se entregan en la carpeta snowflake-failed/, que se puede utilizar para rellenarlos manualmente.
El siguiente es un ejemplo de JSON para cada registro que 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"
}