Problemas comunes - Amazon Data Firehose
flujo de Firehose no disponibleSin datos en el destinoMétrica de antigüedad de los datos incrementada o no emitidaError al convertir el formato de registro a Apache ParquetFaltan campos para el objeto transformado para Lambda

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.

Problemas comunes

A continuación, se ofrecen algunas sugerencias para solucionar problemas comunes al trabajar con un flujo de Firehose.

flujo de Firehose no disponible

La transmisión de Firehose no está disponible como destino para CloudWatch registros, CloudWatch eventos o acciones de AWS IoT, ya que algunos AWS servicios solo pueden enviar mensajes y eventos a una transmisión de Firehose que se encuentre en la misma. Región de AWS Compruebe que el flujo de Firehose está emplazado en la misma región que los demás servicios.

Sin datos en el destino

Si no hay problemas de ingesta de datos, y las métricas emitidas para el flujo de Firehose son correctas, pero no ve datos en el destino, compruebe la lógica del lector. Asegúrese de que su lector esté analizando correctamente todos los datos.

Métrica de antigüedad de los datos incrementada o no emitida

La antigüedad de los datos es una medida de lo actuales que son sus datos dentro del flujo de Firehose. Es la antigüedad del registro de datos más antiguo del flujo de Firehose, medida desde el momento en que Firehose ingirió los datos hasta el momento actual. Firehose proporciona métricas que puede utilizar para supervisar la actualización de los datos. Para identificar la métrica de antigüedad de los datos para un destino determinado, consulte Supervise Amazon Data Firehose con métricas CloudWatch.

Si habilita la copia de seguridad para todos los eventos o todos los documentos, monitorice dos métricas de antigüedad de los datos distintas: una para el destino principal y otra para la copia de seguridad.

Si no se emite la métrica de antigüedad de los datos, esto significa que no hay ninguna entrega activa para el flujo de Firehose. Esto sucede cuando la entrega de datos está completamente bloqueada o cuando no hay datos entrantes.

Si la métrica de antigüedad de los datos aumenta constantemente, esto significa que la entrega de los datos está retrasada. Esto puede suceder por una de las siguientes razones.

  • El destino no es capaz de soportar la velocidad de entrega. Si Firehose encuentra errores transitorios debido a un tráfico elevado, la entrega podría retrasarse. Esto puede ocurrir en destinos distintos de Amazon S3 (puede ocurrir en OpenSearch Service, Amazon Redshift o Splunk). Asegúrese de que su destino tiene suficiente capacidad para tratar el tráfico entrante.

  • El destino es lento. La entrega de datos puede retrasarse si Firehose encuentra una latencia alta. Monitorice la métrica de latencia del destino.

  • La función de Lambda es lenta. Esto podría dar lugar a una velocidad de entrega de datos inferior a la velocidad de ingesta de datos del flujo de Firehose. Si es posible, mejore la eficiencia de la función de Lambda. Por ejemplo, si la función realiza operaciones de E/S de red, use varios subprocesos o utilice operaciones de E/S asincrónicas para aumentar el paralelismo. Además, considere la posibilidad de aumentar el tamaño de memoria de la función de Lambda para que la asignación de CPU pueda aumentar en consecuencia. Esto podría producir invocaciones de Lambda más rápidas. Para obtener información sobre la configuración de las funciones de Lambda, consulte Configuración de funciones de Lambda AWS.

  • Hay errores durante la entrega de datos. Para obtener información sobre cómo supervisar los errores mediante Amazon CloudWatch Logs, consulteSupervise Amazon Data Firehose mediante registros CloudWatch.

  • Si el origen de datos del flujo de Firehose es un flujo de datos de Kinesis, es posible que se aplique una limitación. Compruebe las métricas ThrottledGetRecords, ThrottledGetShardIterator y ThrottledDescribeStream. Si hay varios consumidores asociados a la secuencia de datos de Kinesis, tenga en cuenta lo siguiente:

    • Si las métricas ThrottledGetShardIterator y ThrottledGetRecords son elevadas, le recomendamos que aumente el número de particiones aprovisionadas para la secuencia de datos.

    • Si el ThrottledDescribeStream valor es alto, le recomendamos que añada el kinesis:listshards permiso al rol configurado en KinesisStreamSourceConfiguration.

  • Sugerencias de almacenamiento en búfer bajo para el destino. Esto podría aumentar el número de viajes de ida y vuelta que Firehose tiene que hacer al destino, lo que podría causar un retraso en la entrega. Considere la posibilidad de aumentar el valor de las sugerencias de almacenamiento en búfer. Para obtener más información, consulte BufferingHints.

  • Una duración de reintentos alta podría hacer que la entrega se retrasara cuando los errores son frecuentes. Considere la posibilidad de reducir la duración de los reintentos. Además, monitorice los errores e intente reducirlos. Para obtener información sobre cómo supervisar los errores mediante Amazon CloudWatch Logs, consulteSupervise Amazon Data Firehose mediante registros CloudWatch.

  • Si el destino es Splunk y la métrica DeliveryToSplunk.DataFreshness es elevada pero DeliveryToSplunk.Success tiene un valor correcto, es posible que el clúster de Splunk esté ocupado. Libere el clúster de Splunk si es posible. También puede ponerse en contacto con AWS Support y solicitar un aumento del número de canales que Firehose utiliza para comunicarse con el clúster de Splunk.

Error al convertir el formato de registro a Apache Parquet

Esto ocurre si toma datos de DynamoDB que incluyen ese tipo, Set los transmite a través de Lambda a una transmisión de Firehose y utiliza AWS Glue Data Catalog an para convertir el formato de registro a Apache Parquet.

Cuando el AWS Glue rastreador indexa los tipos de datos del conjunto de DynamoDB (StringSet, yBinarySet)NumberSet, los almacena en el catálogo de datos comoSET<STRING>, y, respectivamente. SET<BIGINT> SET<BINARY> Sin embargo, para que Firehose convierta los registros de datos al formato Apache Parquet, requiere los tipos de datos de Apache Hive. Dado que los tipos de conjunto no son tipos de datos de Apache Hive válidos, la conversión produce un error. Para que la conversión funcione, actualice el catálogo de datos con los tipos de datos de Apache Hive. Puede hacerlo cambiando set a array en el catálogo de datos.

Para cambiar uno o más tipos de datos de a dentro de un catálogo set de array datos AWS Glue

  1. Inicie sesión en Consola de administración de AWS y abra la AWS Glue consola en https://console.aws.amazon.com/glue/.

  2. En el panel izquierdo, en el encabezado Catálogo de datos , elija Tablas.

  3. En la lista de tablas, elija el nombre de la tabla en la que desea modificar uno o varios tipos de datos. Esto le lleva a la página de detalles de la tabla.

  4. Elija el botón Editar esquema situado en la esquina superior derecha de la página de detalles.

  5. En la columna Tipo de datos , elija el primer tipo de datos set .

  6. En la lista desplegable Tipo de columna , cambie el tipo de set a array.

  7. En el ArraySchemacampo, introduzca array<string>array<int>, oarray<binary>, según el tipo de datos apropiado para su escenario.

  8. Elija Actualizar.

  9. Repita los pasos anteriores para convertir otros tipos set a tipos array .

  10. Seleccione Save.

Faltan campos para el objeto transformado para Lambda

Al utilizar la transformación de datos de Lambda para cambiar los datos JSON a un objeto Parquet, es posible que falten algunos campos después de la transformación. Esto ocurre si el objeto JSON tiene letras mayúsculas, y la distinción entre mayúsculas y minúsculas está configurada en false, lo que puede provocar una discordancia en las claves JSON tras la transformación de los datos y provocar que falten datos en el objeto Parquet resultante del bucket s3.

Para solucionar este problema, asegúrese de que la configuración del conducto tenga deserializationOption: case.insensitive configurado en true para que las claves JSON coincidan después de la transformación.