La documentación para las diversas métricas de recuento de restablecimiento de cliente/objetivo/elb ( TCP_Client_Reset_Count , TCP_Target_Reset_Count , TCP_ELB_Reset_Count ) simplemente dice que cuentan los paquetes RST. Traté de entender qué es un paquete RST y parece tener que ver con conexiones TCP rotas. Mi balanceador de carga tiene una conexión de cliente única, a largo plazo y aparentemente exitosa. ¿Por qué veo en el orden de 100 restablecimientos de clientes por hora? También veo alrededor de 10 restablecimientos del balanceador de carga por hora y 0 restablecimientos de objetivos.
EDITAR: acabo de observar que aumentar el tamaño de la instancia del servidor (estoy usando Farscape, aumenté 0,25 vCPU a 0,5) llevó a una reducción de 10 veces en los reinicios del cliente por hora. La cantidad de restablecimientos del balanceador de carga no cambió.
Mi corazonada es que esto está relacionado con un error en el Network Load Balancer que hace que envíe 100 veces más controles de estado de los que debería. Consulte: Las verificaciones de estado del grupo objetivo de NLB están fuera de control. Mi teoría es que un error hace que la conexión de verificación de estado se interrumpa de manera sucia si la instancia de destino no es lo suficientemente rápida. Estas conexiones de verificación de estado interrumpidas se informan como "restablecimientos del cliente", aunque deberían informarse como "restablecimientos de ELB" o no informarse en absoluto.
Hay muchas razones para enviar un TCP RST. Algunos no son normales, es decir, errores, y otros son limpiezas de conexión normales que realiza la aplicación o la pila TCP/IP.
Un ejemplo de un TCP RST normal sería una conexión de larga duración que supera algún límite de tiempo impuesto por un lado u otro. Una vez que se excede el límite de tiempo, la conexión puede cerrarse "a la fuerza", lo que generará el RST.
Un ejemplo de un TCP RST no normal sería una aplicación que se desconectó abruptamente debido a un error interno.
Una aplicación mal escrita también puede causar TCP RST cuando no realiza apagados correctos en el socket TCP antes de cerrar la conexión.
Supongo que el comportamiento que está viendo no es un problema. Sin embargo, para saberlo realmente, deberá realizar un seguimiento de cables y un análisis de protocolo en cada conexión para determinar exactamente qué está sucediendo.
Una de las razones por las que los recuentos de restablecimiento del balanceador de carga pueden ser más altos se debe a que el balanceador de carga de red tiene un valor de tiempo de espera ideal que es de 350 segundos. Entonces, si su conexión TCP no recibe ningún reconocimiento hasta que se agote el tiempo de espera, el balanceador de carga cerrará la conexión a la fuerza.