Solución de problemas de los consumidores de Kinesis Data Streams - Amazon Kinesis Data Streams
Error de compilación con el LeaseManagementConfig constructorAlgunos registros de Kinesis Data Streams se omiten al usar Kinesis Client LibraryRegistros que pertenecen a la misma partición se procesan en distintos procesadores de registros a la vezLa aplicación consumidora lee a una velocidad menor que lo esperadoGetRecords devuelve una matriz de registros vacía incluso cuando hay datos en la transmisiónEl iterador de particiones caduca de forma inesperadaEl procesamiento de registros del consumidor se queda atrásError de permiso de clave KMS maestra no autorizadoSolucionar otros problemas comunes para los consumidores

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.

Solución de problemas de los consumidores de Kinesis Data Streams

Error de compilación con el LeaseManagementConfig constructor

Al actualizar a la versión 3.x o posterior de la Biblioteca de clientes de Kinesis (KCL), es posible que se produzca un error de compilación relacionado con el constructor. LeaseManagementConfig Si está creando directamente un LeaseManagementConfig objeto para establecer las configuraciones en lugar de usarlo ConfigsBuilder en KCL las versiones 3.x o posteriores, es posible que aparezca el siguiente mensaje de error al compilar el código de la aplicación. KCL

Cannot resolve constructor 'LeaseManagementConfig(String, DynamoDbAsyncClient, KinesisAsyncClient, String)'

KCLen las versiones 3.x o posteriores, es necesario añadir un parámetro más applicationName (tipo: String) después del parámetro. tableName

  • Antes: leaseManagementConfig = new LeaseManagementConfig (tableName,,dynamoDBClient, kinesisClientstreamName,workerIdentifier)

  • Después de: leaseManagementConfig = nuevo LeaseManagementConfig (tableNameapplicationName,dynamoDBClient,kinesisClient,streamName,workerIdentifier)

En lugar de crear un LeaseManagementConfig objeto directamente, se recomienda utilizarlo ConfigsBuilder para establecer las configuraciones en la versión KCL 3.x y versiones posteriores. ConfigsBuilderproporciona una forma más flexible y fácil de mantener de configurar KCL la aplicación.

El siguiente es un ejemplo de uso ConfigsBuilder para establecer KCL configuraciones.

ConfigsBuilder configsBuilder = new ConfigsBuilder(
    streamName,
    applicationName,
    kinesisClient,
    dynamoClient,
    cloudWatchClient,
    UUID.randomUUID().toString(),
    new SampleRecordProcessorFactory()
);

Scheduler scheduler = new Scheduler(
    configsBuilder.checkpointConfig(),
    configsBuilder.coordinatorConfig(),
    configsBuilder.leaseManagementConfig()
    .failoverTimeMillis(60000), // this is an example
    configsBuilder.lifecycleConfig(),
    configsBuilder.metricsConfig(),
    configsBuilder.processorConfig(),
    configsBuilder.retrievalConfig()
);

Algunos registros de Kinesis Data Streams se omiten al usar Kinesis Client Library

La causa más frecuente de la omisión de registros es que haya una excepción de processRecords no administrada. La biblioteca de clientes de Kinesis (KCL) se basa en su processRecords código para gestionar cualquier excepción que surja al procesar los registros de datos. Cualquier excepción lanzada desde processRecords es absorbida por. KCL Para evitar reintentos infinitos en caso de un error recurrente, KCL no reenvía el lote de registros procesado en el momento de la excepción. KCLA continuación, processRecords solicita el siguiente lote de registros de datos sin reiniciar el procesador de registros. Esto da como resultado que en las aplicaciones consumidoras se observen registros omitidos. Para evitar que se omitan registros, administre todas las excepciones de processRecords convenientemente.

Registros que pertenecen a la misma partición se procesan en distintos procesadores de registros a la vez

Para cualquier aplicación de Kinesis Client Library (KCL) que se ejecute, un fragmento solo tiene un propietario. Sin embargo, varios procesadores de registros podrían procesar el mismo fragmento temporalmente. En el caso de una instancia de trabajo que pierde la conectividad de red, se KCL supone que la instancia de trabajo a la que no se puede acceder ya no está procesando registros una vez transcurrido el tiempo de conmutación por error, e indica a otras instancias de trabajo que se hagan cargo de ella. Durante un breve periodo, los nuevos procesadores de registros y los procesadores de registros del proceso de trabajo inaccesible pueden procesar datos procedentes del mismo fragmento.

Debe definir un tiempo de conmutación por error que sea adecuado para su aplicación. En el caso de las aplicaciones de baja latencia, el valor predeterminado de 10 segundos puede representar el tiempo máximo que desee esperar. Sin embargo, en aquellos casos en los que prevea que se producirán problemas de conectividad, como al hacer llamadas en zonas geográficas en las que la conectividad se podría perder con más frecuencia, puede que este número sea demasiado bajo.

Su aplicación debe anticiparse a esta situación y administrarla, especialmente debido a que la conectividad de red normalmente se restaura al proceso de trabajo previamente inaccesible. Si los fragmentos de un procesador de registros son ocupados por otro procesador de registros, debe afrontar los dos casos siguientes para cerrarse sin ocasionar problemas:

  1. Una vez completada la llamada actual aprocessRecords, KCL invoca el método de apagado del procesador de registros con el motivo de apagado ''. ZOMBIE Cabe esperar que sus procesadores de registros eliminen los recursos según corresponda y, a continuación, se cierren.

  2. Cuando intentas detener a un trabajador «zombi», se lanza. KCL ShutdownException Tras recibir esta excepción, lo normal es que el código salga del método actual sin ocasionar problemas.

Para obtener más información, consulte Administrar registros duplicados.

La aplicación consumidora lee a una velocidad menor que lo esperado

Los motivos más comunes para que el rendimiento de lectura sea menor que lo esperado son los siguientes:

  1. Varias aplicaciones consumidoras tienen lecturas totales que superan los límites por fragmento. Para obtener más información, consulte Cuotas y límites. En este caso, puede aumentar el número de particiones en el flujo de datos de Kinesis.

  2. El límite que especifica el número máximo de comandos GetRecords por llamada puede haberse configurado con un valor bajo. Si utiliza elKCL, es posible que haya configurado al trabajador con un valor bajo para la maxRecords propiedad. En general, recomendamos que utilice los valores predeterminados del sistema para esta propiedad.

  3. La lógica de su processRecords llamada puede tardar más de lo esperado por varias razones posibles: la lógica puede ser CPU intensiva, bloquear las E/S o entorpecer la sincronización. Para probar si alguno de estos supuestos es cierto, realice ejecuciones de prueba de procesadores de registros vacíos y compare el rendimiento de lectura. Para obtener información sobre cómo mantener la entrada de datos, consulte Utilizar la nueva partición, el escalado y el procesamiento paralelo para cambiar el número de particiones.

Si tiene una única aplicación consumidora, siempre puede leer al menos dos veces más rápido que la velocidad de inclusión. Esto se debe a que puede escribir hasta 1000 registros por segundo para escrituras, hasta un máximo de escritura de datos de 1 MB por segundo (incluidas las claves de partición). Cada partición abierta admite hasta 5 transacciones por segundo en el caso de las lecturas, con una velocidad máxima total de lectura de datos de 2 MB por segundo. Tenga en cuenta que con cada lectura (llamada a GetRecords) se obtiene un lote de registros. El tamaño de los datos devueltos por GetRecords varía en función del uso del fragmento. El volumen máximo de datos que GetRecords puede devolver es de 10 MB. Si una llamada devuelve ese límite, las llamadas posteriores realizadas en los siguientes 5 segundos provocan una ProvisionedThroughputExceededException.

GetRecords devuelve una matriz de registros vacía incluso cuando hay datos en la transmisión

El consumo o la obtención de registros se basa en un modelo de extracción. Se espera que los desarrolladores GetRecordsrealicen llamadas en un bucle continuo sin interrupciones. Cada llamada a GetRecords devuelve también un valor ShardIterator que debe utilizarse en la siguiente iteración del bucle.

La operación GetRecords no se bloquea. En su lugar, se devuelve de inmediato, con registros de datos relevantes o con un elemento Records vacío. Un elemento Records vacío se devuelve con dos condiciones:

  1. No hay más datos actualmente en el fragmento.

  2. No hay datos cerca de la parte del fragmento a la que apunta el ShardIterator.

La última condición es sutil, pero supone un equilibrio de diseño necesario para evitar el tiempo de búsqueda ilimitado (latencia) al recuperar registros. Por lo tanto, la aplicación que consume la secuencia debe proceder en bucle y llamar a GetRecords, ocupándose también de los registros vacíos.

En un escenario de producción, la única vez que se debería salir del bucle continuo es cuando el valor NextShardIterator es NULL. Cuando NextShardIterator es NULL, significa que el fragmento actual se ha cerrado y el valor ShardIterator, de lo contrario, apuntaría más allá del último registro. Si la aplicación consumidora nunca llama a SplitShard o a MergeShards, el fragmento permanece abierto y las llamadas a GetRecords nunca devuelven para NextShardIterator el valor NULL.

Si utiliza la biblioteca de clientes de Kinesis (KCL), se abstrae el patrón de consumo anterior. Esto incluye la administración automática de un conjunto de fragmentos que cambian de forma dinámica. Con elKCL, el desarrollador solo proporciona la lógica para procesar los registros entrantes. Esto es posible porque la biblioteca realiza automáticamente llamadas continuas a GetRecords.

El iterador de particiones caduca de forma inesperada

Con cada nueva solicitud GetRecords se devuelve un nuevo iterador de fragmentos (como NextShardIterator) que debe usar entonces en la siguiente solicitud GetRecords (como ShardIterator). Normalmente, este iterador de fragmentos no caduca antes de utilizarlo. Sin embargo, los iteradores de fragmentos pueden caducar por no haber llamado a GetRecords durante más de 5 minutos, o porque haber reiniciado la aplicación consumidora.

Si el iterador de particiones caduca inmediatamente, antes de poder utilizarlo, esto podría indicar que la tabla de DynamoDB que utiliza Kinesis no tiene capacidad suficiente para almacenar los datos arrendados. Es más probable que se dé esta situación si tiene un gran número de fragmentos. Para solucionar este problema, aumente la capacidad de escritura asignada a la tabla de fragmentos. Para obtener más información, consulte Utilice una tabla de arrendamientos para realizar un seguimiento de los fragmentos procesados por la aplicación de consumo KCL.

El procesamiento de registros del consumidor se queda atrás

En la mayoría de casos de uso, las aplicaciones consumidoras leen los datos más recientes de la secuencia. En determinadas circunstancias, puede que las lecturas del consumidor se queden atrás, lo que no es deseable. Tras identificar el retraso con el que están realizando las lecturas sus consumidores, consulte los motivos más comunes por los que estos se retrasan.

Comience por la métrica GetRecords.IteratorAgeMilliseconds, que controla la posición de lectura de todos los fragmentos y los consumidores de la secuencia. Tenga en cuenta que si la antigüedad de un iterador supera el 50 % del periodo de retención (con un valor predeterminado de 24 horas pero configurable hasta 365 días), existe el riesgo de pérdida de datos debido a la caducidad del registro. Una parche rápido es aumentar el periodo de retención. Así se detiene la pérdida de datos importantes mientras se realizan los pasos para solucionar el problema. Para obtener más información, consulte Supervise el servicio Amazon Kinesis Data Streams con Amazon CloudWatch. A continuación, identifique el retraso con el que su aplicación de consumo lee cada fragmento mediante una CloudWatch métrica personalizada emitida por la biblioteca de clientes de Kinesis KCL (),. MillisBehindLatest Para obtener más información, consulte Supervise la biblioteca de clientes de Kinesis con Amazon CloudWatch.

Estos son los motivos más comunes por los que los consumidores se pueden retrasar:

  • Los aumentos repentinos y grandes que MillisBehindLatest se producen GetRecords.IteratorAgeMilliseconds o suelen indicar un problema transitorio, como un fallo en el API funcionamiento de una aplicación posterior. Debe investigar estos aumentos repentinos si alguna de las métricas muestra constantemente este comportamiento.

  • Un incremento gradual de estas métricas indica que un consumidor no mantiene el ritmo de la secuencia porque no procesa los registros lo suficientemente rápido. Las causas más comunes para este comportamiento son la insuficiencia de recursos físicos o una lógica de procesamiento de registros que no está ajustada a un aumento en el rendimiento de la secuencia. Para comprobar este comportamiento, consulte las demás CloudWatch métricas personalizadas que emiten asociadas a la KCL processTask operación, incluidasRecordProcessor.processRecords.Time, Success y. RecordsProcessed

    • Si percibe un aumento en la métrica processRecords.Time que se correlaciona con una mejora en el rendimiento, debe analizar su lógica de procesamiento de registros para identificar por qué no se ajusta al aumento de rendimiento.

    • Si percibe un incremento de los valores processRecords.Time que no está correlacionado con el aumento de rendimiento, compruebe si está realizando llamadas de bloqueo en la ruta crítica, ya que suelen ser la causa de la reducción de velocidad en el procesamiento de registros. Otro enfoque consiste en aumentar el paralelismo incrementando el número de fragmentos. Por último, confirme que dispone de una cantidad adecuada de recursos físicos (memoria, CPU utilización, etc.) en los nodos de procesamiento subyacentes durante los picos de demanda.

Error de permiso de clave KMS maestra no autorizado

Este error se produce cuando una aplicación de consumo lee una transmisión cifrada sin permisos en la clave KMS maestra. Para asignar permisos a una aplicación para acceder a una KMS clave, consulte Uso de políticas clave en AWS KMS y Uso de IAM políticas con AWS KMS.

Solucionar otros problemas comunes para los consumidores