504 Gateway Timeout from Backend Server

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 504 con el mensaje "Gateway Timeout": la respuesta a las llamadas a la API.

Esta respuesta de error indica que el cliente no recibió una respuesta oportuna de Apigee Edge o del servidor de backend durante la ejecución de una llamada a la API.

Mensaje de error

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

HTTP/1.1 504 Gateway Timeout

Es posible que después de este código aparezca un mensaje de error similar al siguiente: 

<html>
<head><title>504 Gateway Timeout</title></head>
<body bgcolor="white">
<center><h1>504 Gateway Timeout</h1></center>
</body>
</html>

¿Qué causa los tiempos de espera de las puertas de enlace?

La ruta de acceso típica para una solicitud a la API realizada a través de Apigee Edge es Cliente -> Router -> Message Processor -> Backend Server, como se muestra en la siguiente figura:

Ruta de solicitud a la API

La aplicación cliente, los routers y los procesadores de mensajes están configurados con valores de tiempo de espera adecuados. Apigee Edge espera una respuesta para cada solicitud a la API en un período determinado según los valores de tiempo de espera. Si no se recibe la respuesta dentro del período especificado, se muestra una respuesta 504 Gateway Timeout.

Causas posibles

En Apigee Edge, la causa típica de una respuesta 504 Gateway Timeout del servidor de backend es la siguiente:

Causa Descripción Instrucciones de solución de problemas para
El servidor de backend responde con el tiempo de espera 504 Gateway Timeout Se agota el tiempo de espera del servidor de backend y se muestra una respuesta 504 Gateway Timeout al Message Processor. Usuarios de la nube pública y privada perimetral

El servidor de backend responde con un tiempo de espera de puerta de enlace 504.

El servidor de backend puede responder con un código de respuesta HTTP de 504 Gateway Timeout.

Diagnóstico

En esta sección, se explica cómo diagnosticar correctamente un tiempo de espera de puerta de enlace 504. Se enumeran los procedimientos para los usuarios de nubes privadas y públicas.

Procedimiento n.o 1: Usa Trace (usuarios de la nube privada y pública)

  1. Habilita Trace en la IU de Apigee para la API afectada.
  2. Envía una solicitud al servidor de backend.
  3. Si la solicitud a la API con errores muestra una respuesta 504 del servidor de backend en Trace, la causa del tiempo de espera 504 Gateway es el servidor de backend.
  4. Para determinar el tiempo de respuesta, haz clic en la fase Respuesta recibida del servidor de destino en Trace. En este ejemplo, el tiempo transcurrido es de 60,004 ms:

    detalles de la fase de la IU

    La sección Detalles de la fase proporciona información adicional:

    • Destaca la respuesta 504 Gateway Timeout que se recibió del servidor de backend.
    • En la sección Contenido de la respuesta, se muestra el cuerpo completo de la respuesta del servidor de backend. Como se señaló antes, el formato y el contenido de la carga útil de la respuesta pueden diferir según la implementación del servidor de backend.
    • La sección Encabezado de respuesta > Servidor puede indicar dónde se originó la respuesta.
  5. Para ver los datos de Analytics y confirmar el diagnóstico, haz clic en la fase Datos de Analytics registrados en Trace, como se muestra en la siguiente figura:

    detalles de Analytics de un seguimiento

    En la sección Encabezados de respuesta de los detalles de la fase, se muestran los valores de X-Apigee-fault-code y X-Apigee-fault-source, como se muestra en la siguiente figura:

    detalles de la fase de análisis desde la IU

    Si estos campos contienen los valores que se muestran en la siguiente tabla, la respuesta de error 504 se origina en el servidor de backend:

    Encabezados de respuesta Valor
    X-Apigee-fault-source objetivo
    X-Apigee-fault-code messaging.adaptors.http.flow.ErrorResponseCode
  6. Verifica el encadenamiento de proxies. Sigue estos pasos para determinar si el servidor de backend invoca otro proxy en Apigee:
    1. Regresa a la fase Solicitud enviada al servidor de destino y haz clic en el botón Show Curl para ver el alias del host del servidor de backend.
    2. Si el alias del host del servidor de backend apunta a un alias de host virtual, significa que se encadena el proxy. Repite los pasos anteriores para cada proxy encadenado a fin de diagnosticar la causa de la respuesta de error de tiempo de espera de la puerta de enlace 504. Los tiempos de espera de puerta de enlace 504 que ocurren en proxies en cadena en otras etapas del ciclo de solicitud/respuesta se pueden diagnosticar con esta guía.
    3. Si el alias del host del servidor de backend apunta al servidor de backend, continúa con la Resolución.

Procedimiento n.o 2: Invoca directamente la API del servidor de backend (usuarios de la nube pública y privada)

Llama al servidor de backend directamente para confirmar el mismo comportamiento de respuesta 504 Gateway Timeout que se encuentra cuando se realiza la solicitud a través de Apigee Edge.

  1. Asegúrate de tener todos los encabezados, parámetros de consulta y credenciales necesarios para pasar al servidor de backend como parte de la solicitud.
  2. Si el servicio de backend es de acceso público, puedes usar el comando curl, Postman o cualquier otro cliente de REST y, luego, invocar directamente la API del servidor de backend.
  3. Si solo se puede acceder al servidor de backend desde Message Processor, usa el comando curl, Postman o cualquier otro cliente de REST para invocar la API del servidor de backend directamente desde Message Processor.
  4. Si el servicio de backend muestra una respuesta de tiempo de espera de la puerta de enlace 504, continúa con la Resolución.

Procedimiento n° 3: Verifica los registros de acceso de NGINX (solo usuarios de la nube privada)

Los registros de acceso de NGINX pueden ayudar a determinar si el servidor de backend envió la respuesta de error 504. Esta información es muy útil si el problema ocurrió en el pasado, es intermitente o no se puede capturar en Trace. Sigue estos pasos para verificar los registros de acceso de NGINX:

  1. Para ver los registros de acceso de NGINX, usa este comando: 
    /opt/apigee/var/log/edge-router/nginx/ ORG ~ENV.PORT# _access_log
    .
  2. Busca respuestas de error 504 para el proxy de API afectado. Puedes verificar un período específico, si el problema ocurrió en el pasado o determinar si las solicitudes siguen fallando con una respuesta de error 504.
  3. Si hay respuestas de error 504, determina si la respuesta de error se origina en el servidor de backend.

    4. La siguiente figura es un ejemplo de una entrada de registro de NGINX que muestra una respuesta de error 504 causada por el servidor de destino:

    registros de NGINX de ejemplo

    Si los campos X-Apigee-fault-source y X-Apigee-fault-code contienen los valores que se muestran en la siguiente tabla, la respuesta 504 se origina en el servidor de backend:

    Encabezados de respuesta Valor
    X-Apigee-fault-source objetivo
    X-Apigee-fault-code messaging.adaptors.http.flow.ErrorResponseCode
  4. Revisa el proxy de la API afectado para verificar si hay encadenamiento de proxy, es decir, que el servidor de backend/extremo de destino está invocando otro proxy en Apigee. Si el proxy de la API usa encadenamiento de proxy , repite los pasos anteriores para cada proxy en cadena a fin de diagnosticar la causa de la respuesta de error de tiempo de espera de puerta de enlace 504. Los tiempos de espera de puerta de enlace 504 que se producen en proxies en cadena en otras etapas se pueden diagnosticar con esta guía.
  5. Si no hay un encadenamiento de proxy y la respuesta de error 504 se origina en el servidor de backend, continúa con la Resolución.

Procedimiento n.o 4: Usa la supervisión de APIs (solo usuarios de la nube pública)

La supervisión de las APIs te permite aislar las áreas problemáticas con rapidez para diagnosticar problemas de errores, rendimiento y latencia y su fuente, como las apps para desarrolladores, los proxies de API, los objetivos de backend o la plataforma de la API.

Analiza una situación de muestra en la que se demuestra cómo solucionar problemas 5xx de tus APIs con la supervisión de APIs. Por ejemplo, configura una alerta para notificar a los administradores cuando la cantidad de códigos de estado 504 supere un umbral específico.

Resolución

Con los procedimientos de diagnóstico descritos anteriormente, puedes trabajar con el equipo del servidor de backend para solucionar el problema en el servidor de backend. Esto puede incluir el ajuste de los tiempos de espera en los servidores de backend o en cualquier balanceador de cargas frente a los servidores de destino.

Recopilar información de diagnóstico

Si el problema persiste, comparte la siguiente información de diagnóstico con el equipo de asistencia de Apigee.

Si eres usuario de la nube pública, proporciona la siguiente información:

  • Nombre de la organización
  • Nombre del entorno
  • Nombre de proxy de API
  • Completa el comando curl que se usa para reproducir la respuesta de error 504
  • Archivo de seguimiento con solicitudes a la API que reciben una respuesta de error 504 Gateway Timeout

Si eres usuario de una nube privada, proporciona la siguiente información:

  • Mensaje de error completo observado para las solicitudes con errores
  • Nombre del entorno
  • Paquete de proxy de API
  • Archivo de seguimiento con solicitudes a la API que reciben una respuesta de error 504 Gateway Timeout
  • Registros de acceso de NGINX 
    /opt/apigee/var/log/edge-router/nginx/ ORG ~ENV.PORT# _access_log
  • Registros del procesador de mensajes 
    /opt/apigee/var/log/edge-message-processor/logs/system.log