El agente no está en línea y el cliente realiza una conmutación por error - Amazon Managed Streaming para Apache Kafka

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.

El agente no está en línea y el cliente realiza una conmutación por error

Kafka permite utilizar un agente que no está en línea; un único agente que no está en línea en un clúster sano y equilibrado que siga las prácticas recomendadas no se verá afectado ni provocará fallos en la producción o el consumo. Esto se debe a que otro agente asumirá el liderazgo de la partición y a que la cartera de clientes de Kafka cambiará automáticamente por error y empezará a enviar solicitudes a los nuevos agentes líderes.

Contrato cliente-servidor

Esto se traduce en un contrato compartido entre la cartera de clientes y el comportamiento del servidor; el servidor debe asignar correctamente uno o más nuevos líderes y el cliente debe cambiar de agente para enviar las solicitudes a los nuevos líderes en el momento oportuno.

Kafka utiliza excepciones para controlar este flujo:

Un procedimiento de ejemplo
  1. El agente A entra en estado de desconexión.

  2. El cliente de Kafka recibe una excepción (normalmente desconectado de la red o not_leader_for_partition).

  3. Estas excepciones hacen que el cliente de Kafka actualice sus metadatos para conocer a los líderes más recientes.

  4. El cliente de Kafka vuelve a enviar solicitudes a los nuevos líderes de partición a través de otros agentes.

Este proceso suele tardar menos de 2 segundos con el cliente Java vendido y las configuraciones predeterminadas. Los errores del cliente son detallados y repetitivos, pero no son motivo de preocupación, como se indica en el nivel “WARN”.

Ejemplo: excepción 1

10:05:25.306 [kafka-producer-network-thread | producer-1] WARN o.a.k.c.producer.internals.Sender - [Producer clientId=producer-1] Got error produce response with correlation id 864845 on topic-partition msk-test-topic-1-0, retrying (2147483646 attempts left). Error: NETWORK_EXCEPTION. Error Message: Disconnected from node 2

Ejemplo: excepción 2

10:05:25.306 [kafka-producer-network-thread | producer-1] WARN o.a.k.c.producer.internals.Sender - [Producer clientId=producer-1] Received invalid metadata error in produce request on partition msk-test-topic-1-41 due to org.apache.kafka.common.errors.NotLeaderOrFollowerException: For requests intended only for the leader, this error indicates that the broker is not the current leader. For requests intended for any replica, this error indicates that the broker is not a replica of the topic partition.. Going to request metadata update now"

Los clientes de Kafka resolverán automáticamente estos errores, normalmente en 1 segundo y como máximo en 3 segundos. Esto se presenta como una latencia de producción/consumo de p99 en las métricas del cliente (normalmente, alta en milisegundos a los 100). Un valor superior a este valor suele indicar un problema con la configuración del cliente o con la carga del controlador del servidor. Consulte la sección de solución de problemas.

Una conmutación por error exitosa puede verificarse comprobando el aumento de las métricas de BytesInPerSec y LeaderCount de otros agentes, lo que demuestra que el tráfico y el liderazgo se han movido como se esperaba. También observará un aumento en la métrica UnderReplicatedPartitions, lo que se espera cuando las réplicas no están en línea con el agente de cierre.

Solución de problemas

El flujo anterior puede interrumpirse si se rompe el contrato cliente-servidor. Los motivos más comunes del problema son:

  • Configuración incorrecta o uso incorrecto de las carteras de clientes de Kafka.

  • Comportamientos predeterminados inesperados y errores en las carteras de clientes de terceros.

  • Sobrecarga del controlador que hace que la asignación del líder de partición sea más lenta.

  • Elección de un nuevo controlador que hace que la asignación del líder de partición sea más lenta.

Con el fin de garantizar un comportamiento correcto a la hora de gestionar los fallos de liderazgo, recomendamos:

  • Se deben seguir las prácticas recomendadas del servidor para garantizar que el agente de controladores tenga la escala adecuada para evitar una lenta asignación de liderazgo.

  • Las carteras de clientes deben tener habilitados los reintentos para garantizar que el cliente gestione la conmutación por error.

  • Las carteras de clientes deben tener configurado retry.backoff.ms (valor predeterminado: 100) para evitar atascos de conexiones/solicitudes.

  • Las carteras de clientes deben configurar request.timeout.ms y delivery.timeout.ms en valores acordes con el SLA de las aplicaciones. Los valores más altos harán que la conmutación por error sea más lenta para algunos tipos de errores.

  • Las carteras de clientes deben asegurarse de que bootstrap.servers contenga al menos 3 agentes aleatorios para evitar que la disponibilidad se vea afectada en el momento de la detección inicial.

  • Algunas carteras de clientes son de nivel inferior a otras y esperan que el desarrollador de la aplicación implemente por sí mismo la lógica de reintentos y la gestión de excepciones. Consulte la documentación específica de la cartera de clientes para ver, por ejemplo, el uso y asegúrese de que se sigue la lógica correcta de reconexión/reintento.

  • Recomendamos supervisar la latencia del cliente para comprobar la producción, el recuento de solicitudes satisfactorias y el recuento de errores en caso de errores que no se puedan volver a intentar.

  • Hemos observado que las antiguas carteras de golang y ruby de terceros permanecen detalladas durante todo el periodo de inactividad del agente, a pesar de que las solicitudes de producción y consumo no se ven afectadas. Le recomendamos que siempre supervise las métricas a nivel empresarial, además de solicitar métricas de éxito y errores, para determinar si hay un impacto real o un ruido en sus registros.

  • Los clientes no deberían alarmarse ante las excepciones transitorias en el caso de network/not_leader, ya que son normales, no impactan y se espera que formen parte del protocolo Kafka.

  • Los clientes no deberían activar la alarma, UnderReplicatedPartitions ya que son normales, no impactan y se esperan de un solo agente fuera de línea.