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. # Comprensión de la entrega de datos en Amazon Data Firehose Cuando envía datos al flujo de Firehose, se envían automáticamente al destino que elija. En la siguiente tabla, se explica la entrega de datos a diferentes destinos. | Destino | Details | | --- | --- | | Amazon S3 | Para la entrega de datos a Amazon S3, Firehose concatena varios registros entrantes en función de la configuración de almacenamiento en búfer del flujo de Firehose. A continuación, entrega los registros en Amazon S3 como un objeto de Amazon S3. De forma predeterminada, Firehose concatena los datos sin ningún delimitador. Si desea tener nuevos delimitadores de línea entre los registros, puede añadirlos activando la característica en la [configuración de la consola de Firehose](https://docs.aws.amazon.com/firehose/latest/dev/create-destination.html#create-destination-s3) o en el [parámetro de la API.](https://docs.aws.amazon.com/firehose/latest/APIReference/API_Processor.html) La entrega de datos entre Firehose y el destino de Amazon S3 se cifra con TLS (HTTPS). | | Amazon Redshift | Para entregar datos en Amazon Redshift, Firehose envía primero los datos de entrada al bucket de S3 en el formato descrito anteriormente. A continuación, Firehose emite un comando **COPY** de Amazon Redshift para cargar los datos del bucket de S3 en el clúster aprovisionado de Amazon Redshift o el grupo de trabajo de Amazon Redshift sin servidor. Asegúrese de que, después de que Amazon Data Firehose haya concatenado varios registros de entrada a un objeto de Amazon S3, este objeto se pueda copiar en el clúster aprovisionado de Amazon Redshift o en el grupo de trabajo de Amazon Redshift sin servidor. Para obtener más información, consulte [Amazon Redshift COPY Command Data Format Parameters](https://docs.aws.amazon.com/redshift/latest/dg/copy-parameters-data-format.html). | | OpenSearch Servicio y OpenSearch sin servidor | Para la entrega de datos a OpenSearch Service y OpenSearch Serverless, Amazon Data Firehose almacena en búfer los registros entrantes en función de la configuración de almacenamiento en búfer de la transmisión de Firehose. A continuación, genera una solicitud masiva de OpenSearch Service o OpenSearch Serverless para indexar varios registros en su clúster de servicios o en su colección Serverless. OpenSearch OpenSearch Asegúrese de que el registro esté codificado en UTF-8 y aplanado en un objeto JSON de una sola línea antes de enviarlo a Amazon Data Firehose. Además, la rest.action.multi.allow\$1explicit\$1index opción del clúster de OpenSearch servicios debe estar establecida en true (valor predeterminado) para aceptar solicitudes masivas con un índice explícito que se establezca por registro. Para obtener más información, consulta [las opciones avanzadas de configuración de OpenSearch servicios](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/es-createupdatedomains.html#es-createdomain-configure-advanced-options) en la Guía para desarrolladores de Amazon OpenSearch Service. | | Splunk | Para la entrega de datos en Splunk, Amazon Data Firehose concatena los bytes que se envían. Si desea delimitadores en los datos, como, por ejemplo, un carácter de nueva línea, debe insertarlos usted mismo. Asegúrese de que Splunk esté configurado para analizar dichos delimitadores. Para volver a enviar a Splunk los datos que se enviaron al bucket de errores de S3 (copia de seguridad de S3), siga los pasos que se mencionan en la [documentación de Splunk.](https://www.splunk.com/en_us/blog/tips-and-tricks/aws-technical-add-on-simplifying-error-data-re-ingestion.html) | | Punto de conexión HTTP | Para entregar datos en un punto de conexión HTTP que pertenece a un proveedor de servicios de terceros admitido, puede usar el servicio Amazon Lambda integrado para crear una función que transforme los registros de entrada en el formato que coincida con el formato que espera la integración del proveedor de servicios. Póngase en contacto con el proveedor de servicios de terceros cuyo punto de conexión HTTP haya elegido como destino para obtener más información sobre el formato de registro aceptado. | | Snowflake | Para la entrega de datos a Snowflake, Amazon Data Firehose almacena internamente los datos en búfer durante un segundo y utiliza las operaciones de la API de streaming de Snowflake para insertar datos en Snowflake. De forma predeterminada, los registros que se insertan se vacían y se archivan en la tabla de Snowflake cada segundo. Tras realizar la llamada de inserción, Firehose emite una CloudWatch métrica que mide el tiempo que tardaron los datos en enviarse a Snowflake. Firehose actualmente solo admite un elemento JSON como carga útil de registro y no admite matrices JSON. Asegúrese de que la carga útil de entrada sea un objeto JSON válido y esté bien formada sin comillas dobles, comillas ni caracteres de escape adicionales. | Cada destino de Firehose tiene su propia frecuencia de entrega de datos. Para obtener más información, consulte [Configuración de sugerencias de almacenamiento en búfer](create-configure-backup.md#buffering-hints). **Registros duplicados** Amazon Data Firehose utiliza la at-least-once semántica para la entrega de datos. En algunas circunstancias, como cuando se agota el tiempo de espera de la entrega de datos, los reintentos de entrega que Amazon Data Firehose lleva a cabo pueden generar duplicados si la solicitud de entrega de datos finalmente se procesa. Esto se aplica a todos los tipos de destino que admite Amazon Data Firehose, excepto los de destinos de Amazon S3, tablas de Apache Iceberg y destinos de Snowflake. **Topics** + [Comprenda la entrega en todas las AWS cuentas y regiones](across.md) + [Comprender las especificaciones de solicitudes y respuestas de entrega de puntos de conexión HTTP](httpdeliveryrequestresponse.md) + [Gestión de errores en la entrega de datos](retry.md) + [Configuración del formato de nombres de objetos de Amazon S3](s3-object-name.md) + [Configura la rotación del índice para el OpenSearch servicio](es-index-rotation.md) + [Pausa y reanudación de la entrega de datos](pause-restart-stream.md) # Comprenda la entrega en todas las AWS cuentas y regiones Amazon Data Firehose admite la entrega de datos a destinos de punto final HTTP en todas las AWS cuentas. La transmisión Firehose y el punto final HTTP que elijas como destino pueden pertenecer a cuentas diferentes AWS . Amazon Data Firehose también admite la entrega de datos a destinos de punto final HTTP en AWS todas las regiones. Puede entregar datos desde una transmisión de Firehose en una AWS región a un punto final HTTP en otra AWS región. También puede entregar datos desde una transmisión Firehose a un destino de punto final HTTP fuera de AWS las regiones, por ejemplo, a su propio servidor local, configurando la URL del punto de enlace HTTP en el destino deseado. En estos casos, se agregan cargos de transferencia de datos adicionales a los gastos de entrega. Para obtener más información, consulte la sección [Transferencia de datos](https://aws.amazon.com/ec2/pricing/on-demand/#Data_Transfer) de la página “Precios de las instancias bajo demanda”. # Comprender las especificaciones de solicitudes y respuestas de entrega de puntos de conexión HTTP Para que Amazon Data Firehose entregue los datos correctamente en los puntos de conexión HTTP personalizados, estos puntos de conexión deben aceptar solicitudes y enviar respuestas con determinados formatos de solicitud y respuesta de Amazon Data Firehose. En esta sección, se describen las especificaciones de formato de las solicitudes HTTP que el servicio Amazon Data Firehose envía a los puntos de conexión HTTP personalizados, así como las especificaciones de formato de las respuestas HTTP que espera el servicio Amazon Data Firehose. Los puntos de conexión HTTP tienen 3 minutos para responder a una solicitud antes de que Amazon Data Firehose agote el tiempo de espera de esa solicitud. Amazon Data Firehose trata las respuestas que no cumplen con el formato adecuado como errores de entrega. ## Formato de las solicitudes **Parámetros de ruta y URL** Los configura directamente como parte de un único campo de URL. Amazon Data Firehose los envía tal y como están configurados, sin modificarlos. Solo se admiten los destinos HTTPS. Las restricciones de URL se aplican durante la configuración del flujo de entrega. Actualmente, solo se admite el puerto 443 para la entrega de datos de puntos de conexión HTTP. **Encabezados HTTP: versión X-Amz-Firehose-Protocol** Este encabezado se usa para indicar la versión de los formatos de solicitudes o respuestas. Actualmente, la única versión es la 1.0. **Encabezados HTTP: -ID X-Amz-Firehose-Request** El valor de este encabezado es un GUID opaco que se puede utilizar con fines de depuración y eliminación de duplicados. Si es posible, las implementaciones de puntos de conexión deben registrar el valor de este encabezado, tanto para las solicitudes que son correctas como para las que no lo son. El ID de solicitud se mantiene igual durante varios intentos de la misma solicitud. **Encabezados HTTP: Content-Type** El valor del encabezado Content-Type es siempre `application/json`. **Encabezados HTTP: Content-Encoding** Se puede configurar un flujo de Firehose para que utilice GZIP a fin de comprimir el cuerpo al enviar solicitudes. Cuando esta compresión está habilitada, el valor del encabezado Content-Encoding se establece en gzip, según la práctica habitual. Si la compresión no está habilitada, el encabezado Content-Encoding no aparece. **Encabezados HTTP: Content-Length** Se usa de forma estándar. **Encabezados HTTP: -Arn: X-Amz-Firehose-Source** El ARN del flujo de Firehose se representa en formato de cadena ASCII. El ARN codifica la región, el ID de la AWS cuenta y el nombre de la transmisión. Por ejemplo, `arn:aws:firehose:us-east-1:123456789:deliverystream/testStream`. **Encabezados HTTP: clave X-Amz-Firehose-Access** Este encabezado contiene una clave de API u otras credenciales. Puede crear o actualizar la clave de API (también conocida como token de autorización) al crear o actualizar el flujo de entrega. Amazon Data Firehose restringe el tamaño de la clave de acceso a 4096 bytes. Amazon Data Firehose no intenta interpretar esta clave de ninguna manera. La clave configurada se copia palabra por palabra en el valor de este encabezado. Sin embargo, si utiliza Secrets Manager para configurar la clave, el secreto debe seguir un formato de objeto JSON específico: `{"api_key": "..."}`. El contenido puede ser arbitrario y, potencialmente, representar un token JWT o una ACCESS\$1KEY. Si un punto de conexión requiere credenciales de varios campos (por ejemplo, nombre de usuario y contraseña), los valores de todos los campos deben almacenarse juntos en una única clave de acceso en un formato que el punto de conexión comprenda (JSON o CSV). Este campo puede codificarse en base64 si el contenido original es binario. Amazon Data Firehose no modifica ni and/or codifica el valor configurado y utiliza el contenido tal cual. **Encabezados HTTP: -Atributos X-Amz-Firehose-Common** Este encabezado contiene los atributos comunes (metadatos) que pertenecen a toda la solicitud, and/or a todos los registros de la solicitud. Los configura directamente al crear un flujo de Firehose. El valor de este atributo está codificado como un objeto JSON con el siguiente esquema: ``` "$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 ``` A continuación se muestra un ejemplo: ``` "commonAttributes": { "deployment -context": "pre-prod-gamma", "device-types": "" } ``` **Cuerpo: tamaño máximo** Configura el tamaño máximo del cuerpo, que puede ser de hasta 64 MiB antes de la compresión. **Cuerpo: esquema** El cuerpo contiene un único documento JSON con el siguiente esquema JSON (escrito 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 ``` A continuación se muestra un ejemplo: ``` { "requestId": "ed4acda5-034f-9f42-bba1-f29aea6d7d8f", "timestamp": 1578090901599 "records": [ { "data": "aGVsbG8=" }, { "data": "aGVsbG8gd29ybGQ=" } ] } ``` ## Formato de las respuestas **Comportamiento predeterminado en caso de error** Si una respuesta no cumple con los requisitos que se indican a continuación, el servidor de Firehose la tratará como si tuviera un código de estado 500 sin cuerpo. **Código de estado** El código de estado HTTP DEBE estar en el rango 2XX, 4XX o 5XX. El servidor de Amazon Data Firehose NO sigue los redireccionamientos (códigos de estado 3XX). Solo el código de respuesta 200 se considera una entrega correcta de los registros a HTTP/EP. El código de respuesta 413 (tamaño excedido) se considera un error permanente y, si está configurado, el lote de registros no se envía al bucket de errores. Todos los demás códigos de respuesta se consideran errores recuperables y están sujetos a un algoritmo de reintentos de retroceso que se explica más adelante. **Encabezados: tipo de contenido** El único tipo de contenido aceptable es application/json. **Encabezados HTTP: Content-Encoding** NO SE DEBE utilizar Content-Encoding. El cuerpo DEBE estar descomprimido. **Encabezados HTTP: Content-Length** El encabezado Content-Length DEBE estar presente si la respuesta tiene un cuerpo. **Cuerpo: tamaño máximo** El cuerpo de la respuesta debe tener un tamaño de 1 MiB o menos. ``` "$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 ``` A continuación se muestra un ejemplo: ``` 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 } ``` **Gestión de las respuestas de errores** En todos los casos de error, el servidor de Amazon Data Firehose vuelve a intentar entregar el mismo lote de registros mediante un algoritmo de retroceso exponencial. Los reintentos se retrasan utilizando un tiempo de espera inicial (1 segundo) con un factor de fluctuación del (15%) y cada reintento posterior se retrasa mediante la fórmula (initial-backoff-time \$1 (multiplier (2) ^ retry\$1count)) con una fluctuación de fase adicional. El tiempo de retroceso está limitado a un intervalo máximo de 2 minutos. Por ejemplo, en el enésimo reintento, el tiempo de retroceso es = MAX(120, 2^n) \$1 random(0.85, 1.15). Los parámetros especificados en la ecuación anterior están sujetos a cambios. Consulte la documentación de AWS Firehose para conocer el tiempo de retroceso inicial exacto, el tiempo máximo de retroceso y los porcentajes de multiplicador y fluctuación utilizados en el algoritmo de retroceso exponencial. En cada reintento posterior, el and/or destino de la clave de acceso al que se envían los registros puede cambiar en función de la configuración actualizada de la transmisión Firehose. El servicio Amazon Data Firehose utiliza el mismo ID de solicitud en todos los reintentos de la mejor manera posible. El servidor de puntos de conexión HTTP puede utilizar esta última característica con fines de eliminación de duplicados. Si la solicitud sigue sin entregarse después del tiempo máximo permitido (según la configuración del flujo de Firehose), el lote de registros se puede entregar opcionalmente en un bucket de errores según la configuración del flujo. ## Ejemplos Ejemplo de una solicitud CWLog originada. ``` { "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" } ] } } ] } ``` # Gestión de 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 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](https://docs.aws.amazon.com/firehose/latest/dev/controlling-access.html#using-iam-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 al bucket de S3 puede generar errores por varias razones, como por ejemplo: + El bucket ya no existe. + El rol de IAM que asume Amazon Data Firehose carece de acceso al bucket. + Problemas de red. + Errores de S3, como 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 de forma indefinida, hasta cumplir con la política de retención del flujo. Amazon Data Firehose envía los registros fallidos a un bucket 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 periodo 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](https://docs.aws.amazon.com/redshift/latest/dg/loading-data-files-using-manifest.html). ## 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](https://docs.aws.amazon.com/firehose/latest/dev/monitoring-with-cloudwatch-logs.html#monitoring-splunk-errors). 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](https://docs.aws.amazon.com/firehose/latest/dev/monitoring-with-cloudwatch-logs.html#monitoring-http-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" } ``` # Configuración del formato de nombres de objetos de Amazon S3 Cuando Firehose entrega datos a Amazon S3, el nombre de la clave del objeto S3 sigue el formato**, donde el sufijo tiene el formato *-------- *, que comienza por 1 y aumenta en 1 por cada cambio de configuración del flujo de Firehose. Puede cambiar las configuraciones de flujos de Firehose (por ejemplo, el nombre del bucket de S3, las sugerencias de almacenamiento en búfer, la compresión y el cifrado). Puedes hacerlo mediante la consola Firehose o la operación [UpdateDestination](https://docs.aws.amazon.com/firehose/latest/APIReference/API_UpdateDestination.html)API. Para **, Firehose añade un prefijo de hora predeterminado en el formato `YYYY/MM/dd/HH`. Este prefijo crea una jerarquía lógica en el bucket, en la que cada barra inclinada (/) crea un nivel jerárquico. Puede modificar esta estructura especificando un prefijo personalizado que incluya expresiones que se evalúan en tiempo de ejecución. Para obtener información acerca de cómo especificar este prefijo, consulte [Prefijos personalizados para los objetos de Amazon Simple Storage Service](https://docs.aws.amazon.com/firehose/latest/dev/s3-prefixes.html). De forma predeterminada, la zona horaria utilizada como prefijo y sufijo es UTC, pero puede cambiarla por la zona horaria que prefiera. Por ejemplo, para usar la hora estándar de Japón en lugar de UTC, puede configurar la zona Asia/Tokyo horaria en o [en Consola de administración de AWS la configuración de parámetros de la API CustomTimeZone (](https://docs.aws.amazon.com/firehose/latest/APIReference/API_ExtendedS3DestinationConfiguration.html)). La siguiente lista contiene las zonas horarias que Firehose admite para la configuración del prefijo de S3. ## Zonas horarias admitidas La siguiente es una lista de las zonas horarias que Firehose admite para la configuración del prefijo de 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 ``` ------ No puede cambiar el campo de sufijo excepto **. Al habilitar la conversión o compresión de formatos de datos, Firehose añadirá una extensión de archivo en función de la configuración. En la siguiente tabla, se explica la extensión de archivo predeterminada que añade Firehose: | Configuración | Extensión de archivo | | --- | --- | | Conversión de formato de datos: Parquet | .parquet | | Conversión de formato de datos: ORC | .orc | | Compresión: Gzip | .gz | | Compresión: Zip | .zip | | Compresión: Snappy | .snappy | | Compresión: Hadoop-Snappy | .hsnappy | También puede especificar la extensión de archivo que prefiera en la consola o en la API de Firehose. La extensión del archivo debe empezar con un punto (.) y puede contener los caracteres permitidos: 0-9a-z\$1-\$1.\$1‘(). La extensión del archivo no puede superar los 128 caracteres. **nota** Al especificar una extensión de archivo, esta anulará la extensión de archivo predeterminada que Firehose añada cuando esté habilitada la [conversión o compresión de formato de datos](https://docs.aws.amazon.com/firehose/latest/dev/record-format-conversion.html). # Comprensión de los prefijos personalizados para los objetos de Amazon S3 Los objetos entregados a Amazon S3 siguen el [formato de nombre](https://docs.aws.amazon.com/firehose/latest/dev/basic-deliver.html#s3-object-namekey) de . Puede especificar un prefijo personalizado que incluya expresiones que se evalúan en tiempo de ejecución. El prefijo personalizado que especifique anulará el prefijo predeterminado de `yyyy/MM/dd/HH`. Puede utilizar expresiones de las siguientes formas en el prefijo personalizado: `!{namespace:value}`, donde `namespace` puede ser una de estas opciones, tal como se explica en las secciones siguientes. + `firehose` + `timestamp` + `partitionKeyFromQuery` + `partitionKeyFromLambda` Si un prefijo termina por una barra inclinada, aparece como una carpeta en el bucket de Amazon S3. Para obtener más información, consulte el [formato de nombre de objeto de Amazon S3](https://docs.aws.amazon.com/firehose/latest/dev/basic-deliver.html#s3-object-name) en la *Amazon Data FirehoseDeveloper Guide*. ## espacio de nombres `timestamp` Los valores válidos para este espacio de nombres son cadenas que son cadenas [Java DateTimeFormatter](https://docs.oracle.com/javase/8/docs/api/java/time/format/DateTimeFormatter.html) válidas. Por ejemplo, en el año 2018, la expresión `!{timestamp:yyyy}` se evalúa como `2018`. Cuando se evalúan marcas de tiempo, Firehose utiliza la marca de tiempo de llegada aproximada del registro más antiguo incluido en el objeto de Amazon S3 que se va a escribir. De forma predeterminada, la marca de tiempo está en UTC. Sin embargo, puede especificar la zona horaria que prefiera. Por ejemplo, puede configurar la zona horaria en Consola de administración de AWS o Asia/Tokyo en la configuración de parámetros de la API ([CustomTimeZone](https://docs.aws.amazon.com/firehose/latest/APIReference/API_ExtendedS3DestinationConfiguration.html)) si desea utilizar la hora estándar de Japón en lugar de UTC. Para ver la lista de zonas horarias compatibles, consulte [Formato de nombre de objeto de Amazon S3](https://docs.aws.amazon.com/firehose/latest/dev/basic-deliver.html#s3-object-name). Si se utiliza el espacio de nombres `timestamp` más de una vez en la misma expresión de prefijo, cada instancia se evalúa como el mismo instante en el tiempo. ## espacio de nombres `firehose` Hay dos valores que se pueden utilizar con este espacio de nombres: `error-output-type` y `random-string`. En la tabla siguiente, se explica cómo hacerlo. **Los valores del espacio de nombres `firehose`** | Conversión | Description (Descripción) | Ejemplo de entrada | Ejemplo de resultado de | Notas | | --- | --- | --- | --- | --- | | error-output-type | Da como resultado una de las siguientes cadenas, en función de la configuración de la transmisión de Firehose y del motivo del error: \$1processing-failed, -failed, splunk-failed AmazonOpenSearchService,\$1. format-conversion-failed http-endpoint-failedSi lo utiliza más de una vez en la misma expresión, cada instancia se evalúa como la misma cadena de error. | myPrefix/result=\$1\$1firehose:error-output-type\$1/\$1\$1timestamp:yyyy/MM/dd\$1 | myPrefix/result=processing-failed/2018/08/03 | El error-output-type valor solo se puede usar en el campo. ErrorOutputPrefix | | random-string | Se evalúa como una cadena aleatoria de 11 caracteres. Si lo utiliza más de una vez en la misma expresión, cada instancia se evalúa como una cadena aleatoria nueva. | myPrefix/\$1\$1firehose:random-string\$1/ | myPrefix/046b6c7f-0b/ | Puede utilizarlo con ambos tipos de prefijos.Puede colocarlo al principio de la cadena de formato para obtener un prefijo aleatorio, que a veces es necesario para alcanzar un rendimiento extremadamente alto con Amazon S3. | ## Espacios de nombres `partitionKeyFromLambda` y `partitionKeyFromQuery` En el caso del [particionamiento dinámico](dynamic-partitioning.md), debe usar el siguiente formato de expresión en el prefijo de bucket de S3: `!{namespace:value}`, donde el espacio de nombres puede ser `partitionKeyFromQuery`, `partitionKeyFromLambda` o ambos. Si utiliza el análisis en línea para crear las claves de particionamiento para sus datos de origen, debe especificar un valor de prefijo de bucket de S3 que conste de expresiones especificadas en el siguiente formato: `"partitionKeyFromQuery:keyID"`. Si utiliza una función de AWS Lambda para crear claves de particionamiento para sus datos de origen, debe especificar un valor de prefijo de bucket de S3 que conste de expresiones especificadas en el siguiente formato: `"partitionKeyFromLambda:keyID"`. Para obtener más información, consulte “Elección de Amazon S3 como destino” en [Creación de un flujo de Firehose](basic-create.md#basic-create.title). ## Reglas semánticas Las siguientes reglas se aplican a las expresiones `Prefix` y `ErrorOutputPrefix`. + En el espacio de nombres `timestamp`, se evalúa cualquier carácter que no esté entre comillas simples. En otras palabras, cualquier cadena encerrada entre comillas simples en el campo de valor se interpreta literalmente. + Si se especifica un prefijo que no contiene una expresión de espacio de nombres de marca de tiempo, Firehose agrega la expresión `!{timestamp:yyyy/MM/dd/HH/}` al valor del campo `Prefix`. + La secuencia `!{` solo puede aparecer en expresiones `!{namespace:value}`. + `ErrorOutputPrefix` únicamente puede ser null si `Prefix` no contiene ninguna expresión. En este caso, `Prefix` evalúa a `yyyy/MM/DDD/HH/` y `ErrorOutputPrefix` evalúa a `yyyy/MM/DDD/HH/`. `DDD` representa el día del año. + Si especifica una expresión para `ErrorOutputPrefix`, debe incluir al menos una instancia de `!{firehose:error-output-type}`. + `Prefix` no puede contener `!{firehose:error-output-type}`. + Una vez evaluados, ni `Prefix` ni `ErrorOutputPrefix` pueden tener una longitud superior a 512 caracteres. + Si el destino es Amazon Redshift, `Prefix` no debe contener expresiones y `ErrorOutputPrefix` debe ser null. + Cuando el destino es Amazon OpenSearch Service o Splunk y no `ErrorOutputPrefix` se especifica ningún, Firehose utiliza `Prefix` el campo para los registros fallidos. + Cuando el destino es Amazon S3, `Prefix` y `ErrorOutputPrefix` en la configuración de destino de Amazon S3 se utilizan para los registros correctos y los registros con errores, respectivamente. Si utiliza AWS CLI o la API, puede utilizar `ExtendedS3DestinationConfiguration` para especificar una configuración de *copia de seguridad* de Amazon S3 con sus propios valores de `Prefix` y `ErrorOutputPrefix`. + Al usar Amazon S3 Consola de administración de AWS y establecer el destino en Amazon S3, Firehose usa `Prefix` y `ErrorOutputPrefix` en la configuración de destino para los registros correctos y los registros fallidos, respectivamente. Si especifica un prefijo mediante expresiones, debe especificar el prefijo de error que incluye `!{firehose:error-output-type}`. + Cuando lo usas `ExtendedS3DestinationConfiguration` con la AWS CLI API o CloudFormation, si especificas una`S3BackupConfiguration`, Firehose no proporciona un valor predeterminado. `ErrorOutputPrefix` + No puedes usar `partitionKeyFromQuery` espacios de nombres `partitionKeyFromLambda` y al crear expresiones. ErrorOutputPrefix ## Ejemplos de prefijos **Ejemplos de `Prefix` y `ErrorOutputPrefix`** | Input | Prefijo evaluado (a las 10:30 h UTC del 27 de agosto de 2018) | | --- | --- | | `Prefix`: sin especificar `ErrorOutputPrefix`: `myFirehoseFailures/!{firehose:error-output-type}/` | `Prefix`: `2018/08/27/10` `ErrorOutputPrefix`: `myFirehoseFailures/processing-failed/` | | `Prefix`: `!{timestamp:yyyy/MM/dd}` `ErrorOutputPrefix`: sin especificar | Entrada no válida: ErrorOutputPrefix no puede ser null si Prefix contiene expresiones | | `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`: sin especificar | `Prefix`: `myFirehosePrefix/2018/08/27/` `ErrorOutputPrefix`: `myFirehosePrefix/processing-failed/2018/08/27/` | # Configura la rotación del índice para el OpenSearch servicio Para el destino del OpenSearch servicio, puede especificar una opción de rotación del índice basada en el tiempo entre una de las cinco opciones siguientes:**NoRotation**,**OneHour**, **OneDay****OneWeek**, o**OneMonth**. En función de la opción de rotación seleccionada, Amazon Data Firehose agregará una parte de la marca de tiempo de llegada en UTC al nombre de índice especificado. También rota la marca de tiempo añadida en consecuencia. El siguiente ejemplo muestra el nombre del índice resultante en OpenSearch Service para cada opción de rotación del índice, donde es el nombre del índice especificado **myindex** y la marca de tiempo de llegada. `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 | **nota** Con la opción `OneWeek`, Data Firehose crea índices automáticamente con el formato -w (por ejemplo, `2020-w33`), donde el número de la semana se calcula según la hora UTC y las siguientes convenciones de EE. UU.: Una semana comienza el domingo La primera semana del año es la primera semana que contiene un sábado de este año # Pausa y reanudación de la entrega de datos Tras configurar un flujo de Firehose, los datos disponibles en el origen del flujo se entregan de forma continua en el destino. Si se produce alguna situación en la que el destino del flujo no esté disponible temporalmente (por ejemplo, durante las operaciones de mantenimiento planificadas), puede que desee pausar temporalmente la entrega de datos y reanudarla cuando el destino vuelva a estar disponible. **importante** Si utiliza el enfoque que se describe a continuación para pausar y reanudar un flujo, después de reanudarlo, verá que se envían pocos registros al bucket de errores de Amazon S3, mientras que el resto del flujo continúa enviándose al destino. Esta es una limitación conocida de este enfoque y se debe a que se registra como fallido un número reducido de registros que no se podían entregar previamente al destino tras varios reintentos. ## Pausa de un flujo de Firehose Para pausar la entrega de un flujo en Firehose, primero elimine los permisos para que Firehose escriba en la ubicación de copias de seguridad de S3 en caso de entregas con errores. Por ejemplo, si quieres pausar la transmisión de Firehose con un OpenSearch destino, puedes hacerlo actualizando los permisos. Para obtener más información, consulte [Otorgar a Firehose acceso a un destino de OpenSearch servicio público](https://docs.aws.amazon.com/firehose/latest/dev/controlling-access.html#using-iam-es). Elimine el permiso `"Effect": "Allow"` de la acción `s3:PutObject` y agregue de forma explícita una declaración que aplique el permiso `Effect": "Deny"` en la acción `s3:PutObject` para el bucket de S3 que se utiliza para hacer copias de seguridad de las entregas con errores. A continuación, desactiva el destino de la transmisión (por ejemplo, desactiva el OpenSearch dominio de destino) o quita los permisos para que Firehose escriba en el destino. Para actualizar los permisos de otros destinos, consulte la sección correspondiente al destino en [Control del acceso con Amazon Data Firehose](https://docs.aws.amazon.com/firehose/latest/dev/controlling-access.html). Tras completar estas dos acciones, Firehose dejará de emitir transmisiones y podrás monitorizarlo mediante [CloudWatch las métricas de Firehose](https://docs.aws.amazon.com/firehose/latest/dev/cloudwatch-metrics.html). **importante** Al pausar la entrega del flujo en Firehose, debe asegurarse de que el origen del flujo (por ejemplo, Kinesis Data Streams o Managed Service para Kafka) esté configurado para retener los datos hasta que se reanude la entrega del flujo y los datos se entreguen en el destino. Si el origen es DirectPUT, Firehose retendrá los datos durante 24 horas. Se pueden producir pérdidas de datos si no se reanuda el flujo y no se entregan los datos antes de que venza el periodo de retención de datos. ## Reanudación de un flujo de Firehose Para reanudar la entrega, primero revierta el cambio llevado a cabo anteriormente en el destino del flujo; para ello, active el destino y asegúrese de que Firehose tenga permisos para entregar el flujo en el destino. A continuación, revierta los cambios llevados a cabo anteriormente en los permisos aplicados al bucket de S3 para hacer copias de seguridad de las entregas con errores. Es decir, aplique el permiso `"Effect": "Allow"` a la acción `s3:PutObject` y elimine el permiso `"Effect": "Deny"` de la acción `s3:PutObject` para el bucket de S3 que se utiliza para hacer copias de seguridad de las entregas con errores. Por último, monitorea [el uso de CloudWatch métricas de Firehose](https://docs.aws.amazon.com/firehose/latest/dev/cloudwatch-metrics.html) para confirmar que la transmisión se entrega al destino. Para ver y solucionar los errores, utiliza la [supervisión de Amazon CloudWatch Logs para Firehose](https://docs.aws.amazon.com/firehose/latest/dev/monitoring-with-cloudwatch-logs.html).