Resolución

Los consumidores de Apache Kafka suelen formar parte de un grupo de consumidores. Cada consumidor del grupo de consumidores recibe mensajes de un subconjunto diferente de particiones del tema cuando ocurre lo siguiente:

• Varios consumidores se suscriben a un tema.
• Estos consumidores pertenecen al mismo grupo de consumidores.

Cuando un consumidor no puede acceder al clúster, el coordinador del grupo elimina al consumidor del grupo de consumidores. Este proceso inicia un evento de reequilibrio que incluye las siguientes acciones:

• Los consumidores restantes quedan libres de sus particiones.
• El coordinador del grupo redistribuye las particiones del tema al resto de los consumidores.

Su grupo de consumidores podría reequilibrarse en las siguientes condiciones:

• Ha transferido la propiedad de la partición de un consumidor a otro en un grupo de consumidores.
• Ha añadido un nuevo consumidor al grupo de consumidores.
• Un consumidor se cierra, se bloquea o abandona el grupo de consumidores.
• Ha modificado los temas y se produce una realineación de la partición.
• Hay un problema de configuración del cliente en las suscripciones del grupo de consumidores. Esto se debe a una discrepancia entre los temas a los que se ha suscrito el grupo y el tema asignado a cada consumidor individual del grupo.

Los consumidores del mismo grupo de consumidores no pueden seguir consumiendo datos hasta que se complete el proceso de reequilibrio. Este es el comportamiento predeterminado de la asignación de particiones. Para evitarlo, puede cambiar la estrategia de asignación de particiones a CooperativeStickyAssignor.

Para evitar que su grupo de consumidores se reequilibre continuamente, pruebe lo siguiente:

• Reduzca el valor de max.partition.fetch.bytes o aumente el valor del tiempo de espera de la sesión (session.timeout.ms) en la configuración del consumidor. El consumidor debe llamar a poll() con frecuencia para evitar que se agote el tiempo de espera de la sesión y el consiguiente reequilibrio. Si la cantidad de datos que devuelve un solo método poll() es grande, es posible que el consumidor tarde mucho tiempo en procesar los datos. Esto significa que el consumidor no llega a la siguiente iteración del bucle de sondeo a tiempo para evitar que se agote el tiempo de espera de la sesión.
  Nota: Si se establece un valor más alto para session.timeout.ms, se reduce la posibilidad de un reequilibrio accidental. Sin embargo, es posible que se tarde más en detectar un error real. Este parámetro está relacionado con heartbeat.interval.ms. El parámetro heartbeat.interval.ms controla la frecuencia con la que el método KafkaConsumer poll() envía un latido al coordinador del grupo. Sin embargo, el parámetro session.timeout.ms controla cuánto tiempo puede estar un consumidor sin enviar un latido.
  Por ejemplo, supongamos que ejecuta Apache Kafka 0.10.1 o una versión posterior y gestiona registros que tardan más en procesarse. En este caso, ajuste max.poll.interval.ms para gestionar retrasos más prolongados entre el sondeo de nuevos registros.
• Asegúrese de que el valor de session.timeout.ms en la configuración del consumidor sea inferior al de group.max.session.timeout.ms en la configuración del agente.
• max.poll.interval.ms establece un límite superior en la cantidad de tiempo que el consumidor puede permanecer inactivo antes de obtener más registros. De forma predeterminada, este valor se establece en 5 minutos. Si este valor se establece en menos de 5 minutos, auméntelo para reducir la posibilidad de reequilibrio. También puede considerar la posibilidad de reducir el valor de max.poll.records junto con max.poll.interval.ms.
• heartbeat.interval.ms es el tiempo esperado entre los latidos enviados al coordinador de consumidores cuando se utilizan las instalaciones de administración de grupos de Kafka. Los latidos se utilizan para garantizar que la sesión del consumidor permanezca activa. Facilitan el reequilibrio cuando nuevos consumidores se unen al grupo o lo abandonen. Este valor se debe establecer en un valor inferior al de session.timeout.ms. Normalmente, este valor se debe establecer en un valor que no supere un tercio del valor de session.timeout.ms. Puede optar por reducir el valor de heartbeat.interval.ms a uno mucho más bajo para controlar el tiempo esperado para que se produzcan reequilibrios normales.
• Si recientemente ha realizado una reasignación de particiones que implique cambios en las particiones de uno de los temas suscritos del grupo de consumidores, es posible que el grupo de consumidores se reequilibre. Esto se debe a que las particiones involucradas se mueven o se alteran. En este caso, absténgase de volver a iniciar el coordinador del grupo u otros agentes de Kafka. Debe esperar a que finalice la reasignación de particiones antes de intentar impedir que el grupo de consumidores se reequilibre. Se recomienda realizar reasignaciones de particiones durante momentos de poco tráfico.

En algunos casos, es posible que vea la siguiente información en los registros de los agentes de Amazon MSK:

[2023-03-01 01:23:45,678] INFO [GroupCoordinator 1]: Preparing to rebalance group amazon.msk.canary.group.broker-1 in state PreparingRebalance with old generation 382660 (__consumer_offsets-21) (reason: Adding new member consumer-amazon.msk.canary.group.broker-1-xxxx-xxxx-xxxx-xxxx-xxxx-xxxx with group instance id None) (kafka.coordinator.group .GroupCoordinator)

Este mensaje indica que amazon.msk.canary.group.broker-N se encuentra en estado PreparingRebalance.

Los grupos amazon.msk.canary.group.broker-N son grupos de consumidores internos que se añaden o eliminan periódicamente para comprobar el estado y las métricas de diagnóstico del clúster. Estos grupos tienen un tamaño insignificante y no se pueden eliminar. Puede ignorar este mensaje.

Información relacionada

Grupo de consumidores bloqueado en estado PreparingRebalance