502 Bad Gateway - Cuelga el enchufe

Estás consultando la documentación de Apigee Edge.
Consulta la documentación de Apigee X. Información

Síntoma

La aplicación cliente recibe un código de estado HTTP de 502 Bad Gateway con el código ECONNRESET como respuesta a 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

Causa Descripción Instrucciones de solución de problemas aplicables para
Se configuró incorrectamente el tiempo de espera de keep-alive Los tiempos de espera de keep-alive están configurados de forma incorrecta entre Edge Microgateway y el servidor de destino. Usuarios de la nube pública y privada de Edge
El servidor de destino cierra la conexión de forma prematura El servidor de destino cierra la conexión de forma prematura mientras Edge Microgateway envía la carga útil de la solicitud. Usuarios de la nube pública y privada de Edge

Pasos comunes de diagnóstico

  1. Verifica los registros de Edge Microgateway: 
    /var/tmp/edgemicro-`hostname`-*.log
  2. Busca para ver 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 alguna solicitud que aún falla 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 configurado en warn o info, también habrá un mensaje [warn] 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 una 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 la frecuencia con la que ocurre.

Causa: Se configuró incorrectamente el tiempo de espera de keep-alive.

Diagnóstico

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

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

Usa tcpdump

  1. Captura una tcpdump entre Edge Microgateway y el servidor de backend en el sistema operativo del host de Edge Microgateway con el siguiente comando:
    tcpdump -i any -s 0 host TARGET_SERVER_HOSTNAME -w FILENAME.pcap
  2. Analiza los tcpdump capturados:

    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 mensaje Continuation.
    5. En el paquete 250561, el cliente envía un ACK..
    6. En el paquete 262436, el servidor envía un FIN, ACK al cliente que inicia el cierre de la conexión. Ten en cuenta que esto representa aproximadamente cinco segundos después del paquete anterior (250561).
    7. En el paquete 262441, el cliente envía otra solicitud POST. Sin embargo, esto falla porque el servidor ya inició el cierre de la conexión. Responde con un RST en el paquete 262441.

    En este ejemplo, se reutilizó la misma conexión 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 sucede cuando el cliente envió una solicitud nueva. Esto sugiere que el tiempo de espera de keep-alive del servidor de backend probablemente sea menor o igual que el valor establecido en el cliente. Para validar esto, consulta Compara el tiempo de espera de keep-alive en Edge Microgateway y en el servidor de backend.

Compara los tiempos de espera de keep-alive

  1. Edge Microgateway no tiene una propiedad de tiempo de espera de keep-alive específica. Lo determina el sistema operativo en el que se ejecuta. Algunos ejemplos comunes son los contenedores de Windows, Linux y Docker.
  2. Es posible que esto esté personalizado en el sistema operativo. Consulta con el 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 mayor que el valor de la propiedad de tiempo de espera keep-alive en el servidor de backend, como en el ejemplo anterior, esa es la causa de los errores 502.

Resolución

Asegúrate de que la propiedad de tiempo de espera de keep-alive siempre sea inferior en el sistema operativo en el que se ejecuta Edge Microgateway en comparación con el 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 keep-alive en el sistema operativo, de modo que esta propiedad sea menor que el valor establecido en el servidor de backend, mediante los pasos aplicables 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 que se configuró en los servidores upstream para evitar estos tipos de condiciones de carrera y errores 502. Cada salto descendente debe ser menor que cada salto ascendente. En Edge Microgateway, se recomienda 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 valor keep_alive_timeout al archivo ~/.edgemicro/org-env-config.yaml.

    edgemicro:
  keep_alive_timeout: 65000
  2. El tiempo de espera de keep-alive del sistema operativo de Edge Microgateway debe ser menor que el 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 upstream.

Causa: El servidor de destino cierra la conexión de forma prematura

Diagnóstico

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

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

  3. Verifica los registros del servidor de backend y comprueba si hay algún error o información que podría haber provocado que el servidor de backend finalice la conexión de forma abrupta. Si encuentras algún error o información, ve a Resolución y corrige el problema de forma adecuada en tu servidor de backend.
  4. Si no encuentras errores ni información en el servidor de backend, recopila el resultado de tcpdump en el servidor de Edge Microgateway:
    tcpdump -i any -s 0 host TARGET_SERVER_HOSTNAME -w FILENAME.pcap
  5. Analiza los tcpdump capturados:

    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. Desde los paquetes 7 en adelante, la conexión se cierra mutuamente. Dado que 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. Las marcas de tiempo en los archivos de registro y en tcpdump a menudo se pueden usar para correlacionar los errores con los paquetes reales.

    Resolución

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

    Si el problema persiste y necesitas ayuda para solucionar problemas 502 Bad Gateway Error o sospechas que es un problema de Edge Microgateway, ve a Debes 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 el equipo de 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 log > level a info antes de proporcionar los archivos de registro al equipo de asistencia de Apigee.
    • Archivo de configuración: La configuración principal de Edge Microgateway reside en el archivo YAML en la carpeta predeterminada de Edge Microgateway, $HOME/.edgemicro. Hay un archivo de configuración predeterminado llamado default.yaml y, luego, uno para cada entorno ORG-ENV-config.yaml. Sube este archivo por completo para la organización y el entorno afectados.