El agente está fuera de línea y el cliente pasa por error - Transmisión gestionada de Amazon 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 está fuera de línea y el cliente pasa por error

Kafka permite utilizar un bróker offline; un único bróker offline en un clúster sano y equilibrado que siga las mejores prácticas no se verá afectado ni provocará fallos en la producción o el consumo. Esto se debe a que otro bróker 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 corredores líderes.

Contrato cliente-servidor

Esto se traduce en un contrato compartido entre la biblioteca del cliente y el comportamiento del lado 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 ejemplo de procedimiento
  1. El corredor A entra en un estado fuera de línea.

  2. El cliente de Kafka recibe una excepción (normalmente se desconecta de la red o no se conecta a ninguna partición).

  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 intermediarios.

Este proceso suele tardar menos de 2 segundos con el cliente Java vendido y las configuraciones predeterminadas. Los errores del lado del cliente son detallados y repetitivos, pero no son motivo de preocupación, como indica 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 lado 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 lado del servidor. Consulte la sección de solución de problemas.

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

Resolución de problemas

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

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

  • Comportamientos predeterminados inesperados y errores en bibliotecas de clientes de terceros.

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

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

Para garantizar un comportamiento correcto a la hora de gestionar los fallos de liderazgo, recomendamos:

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

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

  • Las bibliotecas cliente deben tener configurado retry.backoff.ms (valor predeterminado: 100) para evitar atascos de conexiones o solicitudes.

  • Las bibliotecas cliente deben configurar request.timeout.ms y delivery.timeout.ms en valores alineados con los de las aplicaciones. SLA Los valores más altos provocarán una conmutación por error más lenta en algunos tipos de errores.

  • Las bibliotecas cliente deben garantizar 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 bibliotecas cliente 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 biblioteca de clientes para ver, por ejemplo, el uso y asegúrese de que se sigue la lógica correcta de reconexión y reintento.

  • Recomendamos monitorizar la latencia del lado 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 bibliotecas de golang y ruby de terceros permanecen detalladas durante todo el período de inactividad del broker, a pesar de que las solicitudes de producción y consumo no se ven afectadas. Le recomendamos que supervise siempre las métricas a nivel empresarial, además de solicitar métricas de éxito y errores, a fin de determinar si sus registros tienen un impacto real o no son ruidosos.

  • 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 deben activar la alarma, UnderReplicatedPartitions ya que es normal, no tienen impacto y se espera que se produzcan cuando se trata de un intermediario fuera de línea.