502 Bad Gateway

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

Síntoma

La aplicación cliente obtiene un código de estado HTTP de 502 con el mensaje "Bad Gateway" como respuesta a las llamadas a la API.

El código de estado HTTP 502 significa que el cliente no está recibiendo una respuesta válida de los servidores de backend que realmente deba completar la solicitud.

Mensajes de error

La aplicación cliente obtiene el siguiente código de respuesta:

HTTP/1.1 502 Bad Gateway

Además, es posible que observes los siguientes mensajes de error:

<html>
<head>
<title>Error</title>
<style>
body {
width: 35em;
margin: 0 auto;
font-family: Tahoma, Verdana, Arial, sans-serif;
}
</style>
</head>
<body>
<h1>An error occurred.</h1>
<p>Sorry, the page you are looking for is currently unavailable.<br/>
Please try again later.</p>
</body>
</html>

Si el error proviene del servidor de backend, es posible que veas algo así. El mensaje de error del backend depende completamente de su implementación. 

<html>
<head><title>502 Bad Gateway</title></head>
<body bgcolor="white">
<center><h1>502 Bad Gateway</h1></center>
</body>
</html>

Causas posibles

Estas son algunas causas posibles que pueden provocar el error 502 de Bad Gateway para las APIs que pasan por Apigee Edge:

Causa Descripción Instrucciones de solución de problemas aplicables a
No hay miembros del Parlamento disponibles en el grupo Este error se observa si todos los miembros del grupo no están disponibles, es decir, están ocupados o inactivos y, por lo tanto, no responden. Usuarios de la nube privada de Edge
Configuración de SSL incorrecta entre routers y MP Este error se observa si falta el certificado raíz firmado de la CA del cliente en el almacén de confianza del router de Edge. Usuarios de la nube privada de Edge
Error del servidor de backend Este error se observará si el servidor de backend falla y envía esta respuesta. Usuarios de la nube pública y privada de Edge

Causa: No hay miembros del Parlamento disponibles en el grupo.

Este error se producirá si el router detecta que todos los procesadores de mensajes de una región o un centro de datos determinados no están disponibles (por ejemplo, si todos están inactivos).

Apigee Edge está configurado de tal manera que el tráfico entrante de la API (solicitudes) en una región o centro de datos determinado siempre se enruta desde los routers a los procesadores de mensajes (MP) en la misma región o centro de datos. En algunos casos, los componentes de Apigee Edge se pueden configurar en una sola región o centro de datos y, en algunos casos, en más de una región o centro de datos. En cada región o centro de datos, habrá dos o más routers y procesadores de mensajes configurados.

Diagnóstico

  1. Determina la región o el centro de datos en los que fallan las solicitudes a la API con el error 502 Bad Gateway, si hay más de una región o centro de datos. Puedes encontrarlo identificando la región en la que los usuarios observan errores 502 o revisando los registros de NGINX Access en el directorio /opt/apigee/var/log/edge-router/nginx/ en cada uno de los routers que pertenecen a diferentes regiones.
  2. Verás el siguiente error en los registros de error de NGINX (/opt/apigee/var/log/edge-router/nginx/ORG-Env._error_log)
    2019/06/24 15:26:00 [error] 4796#4796: *56357443 no live upstreams while connecting to upstream, client: <Router_IP_address>, server: <HostAlias>, request: "PUT <BasePath> HTTP/1.1", upstream: "http://<ListOfMP-IP_R-MP-Port>/<BasePath>", host: "<HostAlias>"

Situación 1: Todos los procesadores de mensajes están inactivos

  1. Verifica si los procesadores de mensajes de la región o el centro de datos específicos están funcionando.
  2. Si todos los Message Processor están inactivos, reinícialos.

Resolución

Reinicia todos los Message Processor con el siguiente comando:

/opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart

Situación 2: Todos los procesadores de mensajes están ocupados procesando solicitudes en curso

Este error se producirá si los routers descubren que todos los procesadores de mensajes de una región o centro de datos determinados no están disponibles, ya que todos están ocupados procesando solicitudes en curso.

  1. Verifica si los procesadores de mensajes de la región o el centro de datos específicos están funcionando.
  2. Si todos los Message Processor están activos y activos, verifica si estos tienen un uso elevado de CPU. Luego, genera tres volcados de subprocesos cada 30 segundos con el siguiente comando:
    <JAVA_HOME>/bin/jstack -l <pid> > <filename>
  3. Si el procesador de mensajes usa una memoria elevada, genera un volcado de montón con el siguiente comando:
    sudo -u apigee /bin/jmap -dump:live,format=b,file=
  4. Usa el siguiente comando para reiniciar Message Processor. Debería reducir la CPU y la memoria:
    /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
  5. Supervisa las llamadas a la API para confirmar si el problema aún existe.
  6. Comunícate con el equipo de asistencia de Apigee y proporciona los registros de volcados de subprocesos, volcado de montón y del procesador de mensajes (/opt/apigee/var/log/edge-message-processor/logs/system.log) para ayudar a investigar la causa del alto uso de CPU/memoria.

Causa: configuración de SSL incorrecta entre routers y MP

Diagnóstico

  1. Verifica los registros de NGINX Access (/opt/apigee/var/log/edge-router/nginx/ORG-Env._access_log). Verás una respuesta 502 como se muestra a continuación:
        2019-07-23T12:13:42+03:00	sc-10-254-226-23	10.X.X.X:53634	10.X.X.X:8998	0.000	-	-	502	502	189	344	GET <path> curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.27.1 zlib/1.2.3 libidn/1.18 libssh2/1.4.2	<host alias>	mp-10-254-226-23-23706-8552529-1	10.129.107.101	-	-	-1	-	-	dc-2	gateway-2	green	-	gateway-2	dc-2	op	pilot	http	-
  2. Verifica los registros de error de NGINX (/opt/apigee/var/log/edge-router/nginx/ORG-Env._error_log). Verás errores como los siguientes:
    	2019/07/30 17:02:24 [error] 7691#7691: *11753633 peer closed connection in SSL handshake while SSL handshaking to upstream, client: X.X.X.X, server: <HostAlias>, request: "GET /no-target HTTP/1.1", upstream: "https://X.X.X.X:8998/no-target", host: "<HostAlias>"
  3. Esto muestra que el protocolo de enlace SSL falla entre el router y el procesador de mensajes.
  4. Si observas con atención en el mensaje de error de los pasos 1 y 2, el n.o de puerto que se usó para comunicarse con Message Processor es 8998, que es un puerto no seguro, pero el protocolo es SSL (https). Por lo general, el número de puerto seguro que se usa es 8443. Dado que se utiliza un puerto no seguro para la comunicación segura, se produce una falla del protocolo de enlace SSL.
  5. Por lo general, esto puede suceder si omitiste algún paso o estableciste valores incorrectos durante la configuración de SSL entre el router y el procesador de mensajes. Consulta los pasos que se describen aquí.
    Por ejemplo, este error puede ocurrir si
    1. El número de puerto se especifica como 8998 en lugar de 8443 en /opt/apigee/customer/application/message-processor.properties as shown below.
              conf/message-processor-communication.properties+local.http.port=8998
    2. Los archivos de configuración del router que se encuentran en el directorio /opt/nginx/conf.d/* no se borran y el router no se reinició mientras se realizaba la configuración de SSL. En esta situación, puedes observar que el puerto# de Message Processors seguirá siendo 8998 en los archivos de configuración.

Resolución

  1. Asegúrate de que se sigan todos los pasos proporcionados en Configura TLS entre un router y un procesador de mensajes.
  2. Si el problema persiste, ve a Recopilar información de diagnóstico.

Causa: Error del servidor de backend

Diagnóstico

  1. Si el error se produce todas las veces, puedes capturar el seguimiento de la IU para las solicitudes fallidas. Selecciona una solicitud con errores y navega por varias fases en el seguimiento. Si observas que obtienes la “502 Bad Gateway” del servidor de backend, el problema podría deberse a que se produjo un error en el servidor.
    Seguimiento que muestra 502 Bad Gateway procedente del servidor de backend
  2. Si el problema es intermitente y no puedes capturar el registro,
    1. Si eres usuario de una nube pública, podrías usar la supervisión de API y verificar los detalles de los errores 502.
      1. Si observas que el código de falla es messaging.adaptors.http.flow.ErrorResponseCode y la fuente de errores es target, entonces el servidor de backend causa el error.
    2. Si eres usuario de una nube privada, podrías analizar los registros de NGINX Access
      /opt/apigee/var/log/edge-router/nginx/ORG-Env._access_log.
      Verás la entrada de la solicitud fallida de la siguiente manera:
      2017-02-24T14:42:12+00:00	rt-01	192.8.155.2:18118	192.168.84.166:8998	10.225	-	-	502	502	440	0	GET /adv-eadlg-test/documents?type=doctype HTTP/1.1	rt-02efawae234-1234	Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36	myorg-dev.apigee.net	 rt-02efawae234-1234	6	-	false	target	messaging.adaptors.http.flow.ErrorResponseCode	null/null	-	/organizations/myorg/environments/dev/apiproxies/api123
      1. Si observas que el código de falla es messaging.adaptors.http.flow.ErrorResponseCode y la fuente de errores es target, entonces el servidor de backend causa el error.

Resolución

  1. Trabaja con tu equipo de servidores de backend para solucionar este problema en el backend.

Recopilar información de diagnóstico

  1. Registros de acceso de NGINX
    (/opt/apigee/var/log/edge-router/nginx/ORG-Env._access_log)
    y registros de errores
    (/opt/apigee/var/log/edge-router/nginx/ORG-Env._error_log).
  2. Registros del procesador de mensajes
    (/opt/apigee/var/log/edge-message-processor/logs/system.log).