502 Bad Gateway - Cuelga el enchufe

Estás viendo la documentación de Apigee Edge.
Ir a la documentación de Apigee X. info

Síntoma

La aplicación cliente recibe un código de estado HTTP de 502 Bad Gateway con el código ECONNRESET como respuesta para las llamadas a la API en Edge Microgateway.

Mensaje de error

El cliente verá el siguiente código de respuesta:

HTTP/1.1 502 Bad Gateway

La respuesta incluirá el siguiente mensaje de error:

{"message":"socket hang up","code":"ECONNRESET"}

Causas posibles

Pasos comunes de diagnóstico

1. Verifica los registros de Edge Microgateway:

   /var/tmp/edgemicro-`hostname`-*.log

2. Busca si hay errores 502 con el código ECONNRESET durante un período específico (si el problema ocurrió en el pasado) o si hay solicitudes que aún fallan con 502.

   2021-06-23T03:52:24.110Z [error][0:8000][3][myorg][test]
   [emg_badtarget/flakey/hangup][][][6b089a00-d3d6-11eb-95aa-911f1ee6c684]
   [microgateway-core][][GET][502][socket hang up][ECONNRESET][]

3. Si tienes el nivel de registro establecido en warn o info, también habrá un [warn] mensaje que incluirá el nombre de host y el puerto del servidor de destino en el segundo elemento. En este ejemplo, es X.X.X.X:8080, y se puede usar más adelante para capturar un tcpdump.

   2021-06-23T03:52:24.109Z
   [warn][X.X.X.X:8080][3][myorg][test][emg_badtarget/flakey/hangup]
   [][][6b089a00-d3d6-11eb-95aa-911f1ee6c684][plugins-middleware]
   [targetRequest error][GET][][socket hang up][ECONNRESET][395]

4. El código de error [socket hang up][ECONNRESET] indica que el servidor de destino cerró la conexión con Edge Microgateway. Se puede buscar en los registros para determinar con qué frecuencia ocurre.

Causa: Tiempo de espera de keep-alive configurado de forma incorrecta

Diagnóstico

1. Sigue los pasos que se indican en Pasos comunes de diagnóstico y verifica si recibiste el [socket hang up][ECONNRESET] error.

2. Si es así, investiga más a fondo con la ayuda de tcpdump como se explica a continuación:

Cómo usar tcpdump

1. Captura un tcpdump entre Edge Microgateway y el servidor de backend en el sistema operativo host de Edge Microgateway con el siguiente comando:

   tcpdump -i any -s 0 host TARGET_SERVER_HOSTNAME -w FILENAME.pcap
   

2. Analiza el tcpdump capturado:

   Resultado de tcpdump de muestra: ( ver imagen más grande)

   

   En el tcpdump de muestra anterior, puedes ver lo siguiente:

   1. En el paquete 250288, el cliente envía una solicitud POST.
   2. En el paquete 250371, el servidor responde con 200 OK.
   3. En el paquete 250559, el cliente envía un ACK.
   4. En el paquete 250560, el servidor envía el Continuation mensaje.
   5. En el paquete 250561, el cliente envía un ACK.
   6. En el paquete 262436, el servidor envía un FIN, ACK a el cliente que inicia el cierre de la conexión. Ten en cuenta que esto ocurre aproximadamente cinco segundos después del paquete anterior (250561).
   7. En el paquete 262441, el cliente envía otra POST solicitud. Sin embargo, falla porque el servidor ya inició el cierre de la conexión. Responde con un RST en el paquete 262441.

   En este ejemplo, la misma conexión se volvió a usar al menos una vez de forma correcta, pero en la solicitud final, el servidor inicia un cierre de la conexión después de cinco segundos de tiempo de inactividad, que ocurre al mismo tiempo que el cliente envió una solicitud nueva. Esto sugiere que el tiempo de espera de keep-alive del servidor de backend es muy probablemente más corto o igual a el valor establecido en el cliente. Para validar esto, consulta Compara los tiempos de espera de keep-alive en Edge Microgateway y el servidor de backend.

Compara los tiempos de espera de keep-alive

1. Edge Microgateway no tiene una propiedad específica de tiempo de espera de keep-alive. Está determinado por el sistema operativo en el que se ejecuta. Algunos ejemplos comunes son los contenedores de Windows, Linux y Docker.
2. Es posible que se personalice en el sistema operativo. Consulta con tu administrador del sistema. De forma predeterminada, los sistemas operativos Linux tienen un tiempo de espera de keep-alive predeterminado de dos horas.
3. A continuación, verifica la propiedad de tiempo de espera de keep-alive configurada en tu servidor de backend. Supongamos que tu servidor de backend está configurado con un valor de 10 segundos.
4. Si determinas que el valor del tiempo de espera de keep-alive en el sistema operativo es más alto que el valor de la propiedad de tiempo de espera de keep-alive en el servidor de backend, como en el ejemplo anterior, esa es la causa de los errores 502.

Solución

Asegúrate de que la propiedad de tiempo de espera de keep-alive siempre sea más baja en el sistema operativo en el que se ejecuta Edge Microgateway en comparación con la del servidor de backend.

1. Determina el valor establecido para el tiempo de espera de keep-alive en el servidor de backend.
2. Configura un valor adecuado para la propiedad de tiempo de espera de keep-alive en el sistema operativo, de modo que la propiedad de tiempo de espera de keep-alive sea más baja que el valor establecido en el servidor de backend, con los pasos que se aplican a tu sistema operativo.

Práctica recomendada

Se recomienda que los componentes descendentes siempre tengan un umbral de tiempo de espera de keep-alive menor que el configurado en los servidores ascendentes para evitar este tipo de condiciones de carrera y 502 errores. Cada salto descendente debe ser más bajo que cada salto ascendente. En Edge Microgateway, es una práctica recomendada usar los siguientes lineamientos:

1. El tiempo de espera de keep-alive en la aplicación cliente o el balanceador de cargas debe ser menor que el tiempo de espera de keep-alive de Edge Microgateway.

   Para configurar el tiempo de espera de keep-alive en Edge Microgateway, agrega el keep_alive_timeout valor a tu ~/.edgemicro/org-env-config.yaml archivo.

   edgemicro:
     keep_alive_timeout: 65000

2. El tiempo de espera de keep-alive del sistema operativo de Edge Microgateway debe ser menor que el tiempo de espera de keep-alive del servidor de destino.
3. Si tienes otros saltos delante o detrás de Edge Microgateway, se debe aplicar la misma regla. Siempre debes dejar que el cliente descendente sea responsable de cerrar la conexión con el ascendente.

Causa: El servidor de destino cierra la conexión antes de tiempo

Diagnóstico

1. Sigue los pasos que se indican en Pasos comunes de diagnóstico y verifica si recibiste el [socket hang up][ECONNRESET] error.
2. Si es así, investiga más a fondo con la ayuda de tcpdump como se explica a continuación.

   El mensaje de error [targetRequest error][GET][][socket hang up][ECONNRESET] en el ejemplo anterior indica que este error ocurrió mientras Edge Microgateway enviaba la solicitud al servidor de backend (destino). Es decir, Edge Microgateway envió la solicitud a la API al servidor de backend y esperaba la respuesta. Sin embargo, el servidor de backend finalizó la conexión de forma abrupta antes de que Edge Microgateway recibiera una respuesta.

3. Revisa los registros de tu servidor de backend y comprueba si hay errores o información que podrían haber provocado que el servidor de backend finalizara la conexión de forma abrupta. Si encuentras errores o información, ve a Solución y corrige el problema de forma adecuada en tu servidor de backend.
4. Si no encuentras errores ni información en tu servidor de backend, recopila el tcpdump resultado en el servidor de Edge Microgateway:

   tcpdump -i any -s 0 host TARGET_SERVER_HOSTNAME -w FILENAME.pcap
   

5. Analiza el tcpdump capturado:

   Resultado de tcpdump de muestra: ( ver imagen más grande)

   

   En el tcpdump de muestra anterior, puedes ver lo siguiente:

   1. En el paquete 4, Edge Microgateway envió una solicitud GET al servidor de destino.
   2. En el paquete 5, el servidor de destino respondió con ACK para confirmar la solicitud.
   3. Sin embargo, en el paquete 6, en lugar de responder con una carga útil de respuesta, el servidor de destino envía un FIN, ACK que inicia el cierre de la conexión.
   4. En los paquetes 7 en adelante, la conexión se cierra de forma mutua. Como la conexión se cerró antes de que se enviara la respuesta, Edge Microgateway mostrará el error HTTP 502 al cliente.
   5. Ten en cuenta que la marca de tiempo del paquete 8, 2021-06-23T03:52:24.110Z corresponde a la marca de tiempo en la que se registró el error en los registros de Edge Microgateway logs. Las marcas de tiempo en los archivos de registro y en el tcpdump a menudo se pueden usar para correlacionar los errores con los paquetes reales.

   Solución

   Corrige el problema en el servidor de backend de forma adecuada.

   Si el problema persiste y necesitas ayuda para solucionar el 502 Bad Gateway Error o sospechas que es un problema dentro de Edge Microgateway, consulta Se debe recopilar información de diagnóstico.

   Se debe recopilar información de diagnóstico

   Si el problema persiste incluso después de seguir las instrucciones anteriores, recopila la siguiente información de diagnóstico y, luego, comunícate con Asistencia de Apigee Edge:

   • Archivos de registro: La carpeta predeterminada es /var/tmp, pero se puede anular en el archivo config.yaml principal (logging > dir parameter). Se recomienda cambiar el log > level a info antes de proporcionar los archivos de registro a Asistencia de Apigee.
   • Archivo de configuración: La configuración principal de Edge Microgateway reside en el archivo YAML de la carpeta predeterminada de Edge Microgateway, $HOME/.edgemicro. Hay un archivo de configuración predeterminado llamado default.yaml y otro para cada entorno ORG-ENV-config.yaml. Sube este archivo completo para la organización y el entorno afectados.