502 Bad Gateway - Cuelga el enchufe

Estás viendo la documentación de Apigee Edge.
Ve a 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 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
Tiempo de espera de keep-alive configurado de forma incorrecta Los tiempos de espera de mantenimiento de disponibilidad están configurados de forma incorrecta entre Edge Microgateway y el servidor de destino. Usuarios perimetrales de nubes públicas y privadas
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 perimetrales de nubes públicas y privadas

Pasos comunes de diagnóstico

  1. Revisa los registros de Edge Microgateway: 
    /var/tmp/edgemicro-`hostname`-*.log
  2. Realiza una búsqueda para ver si hay algún error 502 con el código ECONNRESET durante un período específico (si el problema ocurrió en el pasado) o si hay solicitudes Sigue fallando 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 mensaje [warn] que incluya el nombre de host y el puerto del servidor de destino en la . En este ejemplo, es X.X.X.X:8080, y esto se puede usar más tarde 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. Esto 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. Siga los pasos de la sección Pasos comunes del diagnóstico y verifique si recibió el Error [socket hang up][ECONNRESET].

  2. Si es así, investiga más 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 muestra de tcpdump: ( ver imagen más grande)

    En el tcpdump de ejemplo 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 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 al que el cliente inicie el cierre de la conexión. Tengan en cuenta que son cinco segundos después del paquete anterior (250561).
    7. En el paquete 262441, el cliente envía otro POST. para cada solicitud. Sin embargo, esto falla porque el servidor ya inició el cierre del conexión. Responde con un RST en el paquete 262441

    La misma conexión se reutilizó al menos una vez en este ejemplo, pero en la solicitud final, el servidor inicia un cierre de la conexión después de cinco segundos de inactividad, que sucede al mismo tiempo que el cliente envía una nueva solicitud. Esta sugiere que el tiempo de espera de keep-alive del servidor de backend probablemente sea más corto o igual a el valor establecido en el cliente. Para validarlo, 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 específica de tiempo de espera de keep-alive. Sí determinadas por el sistema operativo donde se ejecuta. Algunos ejemplos comunes son Windows, contenedores de Linux y Docker.
  2. Es posible que esté personalizado en el sistema operativo. Verifica con tu administrador del sistema. De forma predeterminada, los sistemas operativos Linux tienen un sistema keep-alive predeterminado tiempo de espera de dos horas.
  3. A continuación, verifica la propiedad de tiempo de espera keep-alive configurada en tu servidor de backend. Veamos digamos que tu servidor de backend está configurado con un valor de 10 segundos.
  4. Si determinas que el valor del tiempo de espera 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 ejemplo anterior, esa es la causa de los errores 502.

Solución

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

  1. Determina el valor establecido para el tiempo de espera keep-alive en el servidor de backend.
  2. Configura un valor adecuado para la propiedad de tiempo de espera keep-alive en las operaciones de modo que la propiedad de tiempo de espera keep-alive sea menor que el valor establecido en el backend servidor web siguiendo los pasos correspondientes a tu sistema operativo.

Práctica recomendada

Se recomienda que los componentes downstream siempre tengan un tiempo de espera de keep-alive menor que los configurados en los servidores ascendentes para evitar este tipo de condiciones de carrera y 502 de errores. Cada salto descendente debe ser menor que cada salto upstream. 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 para tu archivo ~/.edgemicro/org-env-config.yaml.

    edgemicro:
  keep_alive_timeout: 65000
  2. El tiempo de espera de mantenimiento del sistema operativo de Edge Microgateway debe ser inferior al objetivo tiempo de espera de keep-alive del servidor.
  3. Si tienes otros saltos delante o detrás de Edge Microgateway, se debe aplicar la misma regla si se aplican. Siempre debes dejarlo como responsabilidad del cliente final del cierre. la conexión con el upstream.

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

Diagnóstico

  1. Siga las instrucciones que se explican en la sección Pasos comunes del diagnóstico y verifique si se cumple alguna de las siguientes condiciones: recibió 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] En el ejemplo anterior, indica que este error se produjo mientras Edge Microgateway estaba enviando la solicitud al servidor backend (de destino). Es decir, Edge Microgateway envió el archivo al servidor de backend y estaba esperando respuesta. Sin embargo, el backend el servidor finalizó la conexión de forma abrupta antes de que Edge Microgateway recibiera una respuesta.

  3. Revisa los registros del servidor de backend y fíjate si hay algún error o información que pueda que hicieron que el servidor backend finalizara la conexión de forma abrupta. Si encuentras errores o Luego, ve a Solución y corrige el problema según corresponda. en tu servidor de backend.
  4. Si no encuentras ningún error ni información en tu servidor de backend, recopila la Resultado de tcpdump 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 muestra de tcpdump: ( ver imagen más grande)

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

    1. En el paquete 4, Edge Microgateway envió una solicitud GET al destino servidor.
    2. En el paquete 5, el servidor de destino respondió con ACK para confirmar el para cada solicitud.
    3. Sin embargo, en el paquete 6, en lugar de responder con una carga útil de respuesta, el destino el servidor 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 mutuamente. Dado que la conexión fue cerrado antes de enviar la respuesta, Edge Microgateway devolverá el HTTP 502 error 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 Edge Microgateway. los registros del sistema operativo. Las marcas de tiempo en los archivos de registro y en tcpdump suelen para correlacionar los errores con los paquetes reales.

    Solución

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

    Si el problema persiste y necesitas asistencia para solucionarlo 502 Bad Gateway Error o sospechas que se trata de un problema en Edge Microgateway, ve a 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, reúne 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). Sí 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 se encuentra en Archivo YAML en la carpeta predeterminada de Edge Microgateway, $HOME/.edgemicro. Hay una archivo de configuración predeterminado llamado default.yaml y, luego, uno para cada entorno ORG-ENV-config.yaml Sube este archivo para la organización afectada y el entorno