Solución del problema de errores 502 esporádicos en servidores en línea después de períodos pico

La función lanzada esta vez es la función de mensajería grupal. Ahora que la epidemia ha terminado, generalmente hay muchas personas que quieren enviar mensajes grupales para informar a los clientes que las operaciones normales se han reanudado. Actualmente se usa mucho, y esta notificación de mensajes La escala es relativamente grande y los mensajes generalmente se envían a decenas de miles o cientos de miles de personas cada vez. Bajo las condiciones de recursos existentes, generalmente causa ciertas fluctuaciones de recursos en el servidor. , la primera sospecha es que los recursos del servidor no son suficientes y el sistema genera informes de error, como tiempos de espera a gran escala, lo que hace que la capa de puerta de enlace juzgue falsamente que el servidor no está disponible, lo que hace que la puerta de enlace rechace directamente llamadas de terceros.

Eché un vistazo y es cierto que cada vez que ocurre 502, básicamente ocurre cuando hay mucha programación de tareas masivas. Sin embargo, no encontré ningún otro informe de error a gran escala en nuestro registro. Además, los recursos del servidor son limitados. Hay fluctuaciones, pero no son tan grandes, porque generalmente es más fácil para nosotros solicitar recursos del servidor y hemos obtenido una cierta cantidad de excedente.

Aquí preguntamos al lado de operación y mantenimiento si ha habido algún cambio o solución reciente. El lado de operación y mantenimiento pensó que era un problema de recursos del servidor, por lo que directamente duplicaron la cantidad de máquinas para nosotros.

Sin embargo, después de la observación, descubrí que había menos 502, pero el problema aún no se resolvió

El día en que se lanzó la nueva función, cambiamos nuestros servicios a K8 y el lado de operación y mantenimiento realizó cambios relativamente grandes en la arquitectura del servicio allí. Ajuste: para el proxy, antes usábamos nginx, pero ahora usamos traefik. Sabemos que cuando se usa un proxy, el cliente y el servidor no interactúan directamente. para establecer una conexión, pero la solicitud del cliente se entrega al proxy, el agente luego la reenvía y ambas partes establecen conexiones con la capa del agente.

Primero explica ¿qué es keepalive?

Esta es la configuración predeterminada del protocolo http 1.1. En http 1.0, si hay 10 imágenes en su página web, se deben establecer 10 conexiones entre el navegador y el servidor al mismo tiempo. 10 Envíe una imagen y luego cierre estas 10 conexiones. Obviamente, para el servidor, establecer 10 conexiones y luego cerrar 10 conexiones es relativamente costoso. Por lo tanto, se ha agregado la función keepalive al protocolo http 1.1. Al enviar 10 imágenes, solo es necesario establecer una conexión. Mientras quede contenido por transmitir, este canal siempre permanecerá abierto y no se perderá inmediatamente. Una vez completada la transmisión, esto es lo que significa keepalive.

Pero keepalive no puede mantener esta conexión para siempre. Si no hay contenido, continuar manteniéndola es sin duda un desperdicio, por lo que aquí nace el concepto de tiempo de espera keepalive_timeout, que significa que si no hay contenido en esta conexión. Si se transmite y excede este tiempo, la conexión se desconectará. keepalive_requests significa la cantidad máxima de contenido que nuestra conexión puede transmitir. Si el contenido excede esto, también se desconectará.

Entonces, ¿cuál es la relación entre este keepalive_timout y nuestro error 502?

Como dije antes: porque la arquitectura de todos los sitios web no es que el navegador se conecte directamente al servidor de aplicaciones back-end, sino que debe haber servidores nginx y traefik en el medio como proxy inverso. navegador y servidor nginx Se establece una conexión keepalive entre nginx y el servidor de aplicaciones back-end, por lo que son dos conexiones keepalive diferentes.

A la conexión keepalive entre el navegador y nginx la llamamos ka1, y a la conexión keepalive entre nginx y el servidor de aplicaciones ka2.

Si el tiempo de espera de ka1 se establece en 100 segundos, es decir, si no hay contenido nuevo para transmitir dentro de 100 segundos, la conexión entre nginx y el navegador se desconectará.

Al mismo tiempo, configuramos ka2 en 50 segundos, lo que significa que si no hay contenido nuevo para transmitir entre nginx y el servidor de aplicaciones, entonces la conexión entre el servidor de aplicaciones y nginx se desconectará. Entonces ocurrirá un fenómeno en este momento: no se transmite ningún contenido en los primeros 50 segundos. En el segundo 51, el navegador envía una solicitud a nginx. En este momento, ka1 no se ha desconectado porque no ha llegado a los 100 segundos. esto No hay problema, pero algo sale mal cuando nginx intenta enviar una solicitud al servidor de aplicaciones. ¡Ka2 está roto! Debido a que la configuración de tiempo de espera de ka2 es de 50 segundos, ha excedido el límite de tiempo, por lo que está desconectado. En este momento, nginx ya no puede obtener una respuesta correcta del servidor de aplicaciones y tiene que devolver un error 502 al navegador.

Pero nunca hemos establecido estos parámetros en absoluto. ¿Cómo podría haber tal problema?

No importa. Dado que no se ha configurado, el sistema debe estar usando los parámetros predeterminados. Echemos un vistazo a la configuración predeterminada de ka1, que es la brecha entre nginx (ingreso) y el navegador. Valor provincial de keepalive_timeout:

La configuración predeterminada de ka1 es 60 segundos.

Echemos un vistazo a la configuración predeterminada de ka2 en segundos. La documentación oficial de Tomcat dice:

El valor predeterminado es igual al valor de ConnectionTimeout. Entonces, ¿cuál es el valor de ConnectionTimeout? ?

El valor predeterminado de ConnectionTimeout es 60 segundos, ¡pero el server.xml estándar que proporcionan establece este valor en 20 segundos!

Ahora el problema es muy claro. Nuestro ka1 es de 60 segundos y ka2 es de 20 segundos. Si llega una solicitud en cualquier momento entre 21 y 60 segundos, se producirá un error 502.

Ahora que hemos encontrado la causa raíz del problema, es fácil de resolver. Solo necesitamos asegurarnos de que la configuración del tiempo de espera de ka1 sea menor que la configuración de ka2. Puede modificar ka1 o ka2.

Lo mismo ocurre con traefik. Después de cambiar a traefik, el conjunto de keepalive del cliente a traefik es de 180, y el conjunto de keepalive de traefik a nuestro servidor es de 60. cliente a traefik es 60s. Después de desconectar la conexión, si traefik solicita servicio dentro del intervalo de tiempo antes de que se desconecte la conexión al servidor, es muy probable que ocurra 502

El lado de operación y mantenimiento ha ajustado el El tiempo de keepalive desde el cliente hasta traefik debe ser menor o igual que nosotros. Aquí se puede utilizar el keepalive desde el servidor hasta traefik.

Después de observar durante unos días, descubrí que después del ajuste, el servidor estaba completamente normal y 502 nunca volvió a aparecer.

De hecho, el problema esta vez fue bastante obvio;

El punto ciego esta vez

El punto ciego principal es que no está claro que el agente lateral de operación y mantenimiento haya reemplazado nginx con traefik; de lo contrario, el problema será más obvio y el posicionamiento será más rápido;