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
- Verifica los registros de Edge Microgateway:
/var/tmp/edgemicro-`hostname`-*.log
- Busca para ver si hay errores
502
con el códigoECONNRESET
durante un período específico (si el problema ocurrió en el pasado) o si hay alguna solicitud que aún falla con502
.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][]
- Si tienes el nivel de registro configurado en
warn
oinfo
, 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, esX.X.X.X:8080
, y se puede usar más adelante para capturar unatcpdump
.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]
- 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
- Sigue los pasos que se indican en Pasos comunes de diagnóstico y verifica si obtuviste el
error
[socket hang up][ECONNRESET]
. Si es así, investiga más con la ayuda de
tcpdump
como se explica a continuación:
Usa tcpdump
- 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
- Analiza los
tcpdump
capturados:Resultado de tcpdump de muestra: ( ver imagen más grande)
En el
tcpdump
de muestra anterior, puedes ver lo siguiente:- En el paquete 250288, el cliente envía una solicitud
POST
. - En el paquete 250371, el servidor responde con
200 OK
. - En el paquete 250559, el cliente envía un
ACK.
. - En el paquete 250560, el servidor envía el mensaje
Continuation
. - En el paquete 250561, el cliente envía un
ACK.
. - 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). - 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 unRST
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.
- En el paquete 250288, el cliente envía una solicitud
Compara los tiempos de espera de keep-alive
- 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.
- 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.
- 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.
- 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.
- Determina el valor establecido para el tiempo de espera de keep-alive en el servidor de backend.
- 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:
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
- El tiempo de espera de keep-alive del sistema operativo de Edge Microgateway debe ser menor que el del servidor de destino.
- 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
- Usa los pasos explicados en Pasos comunes de diagnóstico y verifica si
obtuviste el error
[socket hang up][ECONNRESET]
. - 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. - 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.
- 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
- Analiza los
tcpdump
capturados:Resultado de tcpdump de muestra: ( ver imagen más grande)
En el
tcpdump
de muestra anterior, puedes ver lo siguiente:- En el paquete 4, Edge Microgateway envió una solicitud
GET
al servidor de destino. - En el paquete 5, el servidor de destino respondió con
ACK
para confirmar la solicitud. - 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. - 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. - 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 entcpdump
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 archivoconfig.yaml
principal (logging > dir parameter
). Se recomienda cambiarlog > level
ainfo
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 llamadodefault.yaml
y, luego, uno para cada entornoORG-ENV-config.yaml
. Sube este archivo por completo para la organización y el entorno afectados.
- En el paquete 4, Edge Microgateway envió una solicitud