504 Gateway Timeout

Estás viendo la documentación de Apigee Edge.
Ir a la documentación de Apigee X. info

Síntoma

La aplicación cliente recibe un código de estado HTTP 504 con el mensaje Gateway Timeout como respuesta a las llamadas a la API.

El código de estado HTTP (error 504 Gateway Timeout) indica que el cliente no recibió una respuesta oportuna de la puerta de enlace perimetral o del servidor de backend durante la ejecución de una API.

Mensajes de error

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

HTTP/1.1 504 Gateway Timeout

En algunos casos, también se puede observar el siguiente mensaje de error:

{
   "fault": {
      "faultstring": "Gateway Timeout",
      "detail": {
           "errorcode": "messaging.adaptors.http.flow.GatewayTimeout"
       }
    }
}

¿Qué causa los tiempos de espera de la puerta de enlace?

La ruta típica para una solicitud a la API a través de la plataforma de Edge será Cliente -> Router -> Message Processor -> Servidor de backend, como se muestra en la siguiente figura:

La aplicación cliente, los routers y los Message Processors dentro de la plataforma de Edge se configuran con valores de tiempo de espera adecuados. La plataforma de Edge espera que se envíe una respuesta dentro de un período determinado para cada solicitud a la API según los valores de tiempo de espera. Si no recibes la respuesta dentro del período especificado, se devolverá 504 Gateway Timeout Error.

En la siguiente tabla, se proporcionan más detalles sobre cuándo pueden ocurrir los tiempos de espera en Edge:

Causas posibles

En Edge, las causas típicas del error 504 Gateway Timeout son las siguientes:

Servidor de backend lento

Si el servidor de backend es muy lento o tarda mucho en procesar la solicitud a la API, recibirás un error 504 Gateway Timeout. Como se explicó en la sección anterior, el tiempo de espera puede ocurrir en una de las siguientes situaciones:

1. El Message Processor agota el tiempo de espera antes de que responda el servidor de backend.
2. El router agota el tiempo de espera antes de que responda el Message Processor o el servidor de backend.
3. La aplicación cliente agota el tiempo de espera antes de que respondan el router, el Message Processor o el servidor de backend.

En las siguientes secciones, se describe cómo diagnosticar y resolver el problema en cada una de estas situaciones.

Situación 1: El procesador de mensajes agota el tiempo de espera antes de que responda el servidor de backend

Diagnóstico

Puedes usar los siguientes procedimientos para diagnosticar si el error 504 Gateway Timeout se produjo debido a la lentitud del servidor de backend.

Procedimiento 1: Usa Trace

Si el problema persiste (siguen apareciendo errores de 504), sigue estos pasos:

1. Realiza un seguimiento de la API afectada en la IU de Edge. Espera a que se produzca el error o, si tienes la llamada a la API, realiza algunas llamadas a la API y reproduce el error 504 Gateway Timeout.
2. Una vez que se produjo el error, examina la solicitud específica que muestra el código de respuesta como 504.
3. Verifica el tiempo transcurrido en cada fase y anota la fase en la que se dedica más tiempo.
4. Si observas el error con el tiempo transcurrido más largo inmediatamente después de una de las siguientes fases, significa que el servidor de backend es lento o tarda mucho en procesar la solicitud:
   • Se envió la solicitud al servidor de destino
   • Política ServiceCallout

A continuación, se proporciona un ejemplo de un registro de seguimiento que muestra que el servidor de backend no respondió incluso después de 55 segundos, lo que generó un error 504 Gateway Timeout:

En el seguimiento anterior, el Message Processor agota el tiempo de espera después de 55002 ms, ya que el servidor de backend no responde.

Procedimiento 2: Cómo usar los registros del Message Processor

1. Verifica el registro del procesador de mensajes (/opt/apigee/var/log/edge-message-processor/logs/system.log).

2. Si encuentras errores Gateway Timeout y onTimeoutRead para la solicitud de proxy de API específica en el momento específico, significa que se agotó el tiempo de espera del Message Processor.

   Ejemplo de registro de Message Processor que muestra el error Gateway Timeout

   2015-09-29 20:16:54,340 org:myorg env:staging api:profiles rev:13 NIOThread@1
   ERROR ADAPTORS.HTTP.FLOW - AbstractResponseListener.onException() :
   AbstractResponseListener.onError(HTTPResponse@4d898cf1, Gateway
   Timeout)
   2015-09-29 20:16:57,361 org:myorg env:staging api:profileNewsletters rev:8
   NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context$3.onTimeout() :
   SSLClientChannel[C:XX.XX.XX.XX:443 Remote
   host:192.168.38.54:38302]@120171 useCount=2 bytesRead=0
   bytesWritten=824 age=55458ms lastIO=55000ms .onTimeoutRead

   En el registro del Message Processor anterior, observas que el servidor de backend indicado con la dirección IP XX.XX.XX.XX no respondió incluso después de 55 segundos (lastIO=55000 ms). Como resultado, se agotó el tiempo de espera del Message Processor y se envió el error 504 Gateway Timeout.

   Consulta este artículo: ¿Cómo se controla el tiempo de espera en Message Processor? Cómo se controla el tiempo de espera en Message Processor Los procesadores de mensajes suelen configurarse con un valor de tiempo de espera predeterminado de 55 segundos a través de la propiedad HTTPTransport.io.timeout.millis. Este valor de tiempo de espera se aplica a todos los proxies de API que pertenecen a una organización a la que presta servicio este procesador de mensajes. Si el servidor de backend no responde en un plazo de 55 segundos, el procesador de mensajes agota el tiempo de espera y envía un error 504 Gateway Timeout al cliente. El valor de tiempo de espera especificado en el Message Processor se puede anular con la propiedad io.timeout.millis especificada en el proxy de API. Este valor de tiempo de espera se aplica a un proxy de API específico en el que se especifica la propiedad mencionada anteriormente. Por ejemplo, si el parámetro io.timeout.millis se establece en 10 segundos dentro del proxy de API, se usará el valor de tiempo de espera de 10 segundos para este proxy de API específico. Si el servidor de backend no responde en un plazo de 10 segundos para el proxy de API específico, el Message Processor agota el tiempo de espera y envía un error 504 Gateway Timeout al cliente.

Solución

1. Comprueba por qué el servidor de backend tarda más de 55 segundos y ve si se puede corregir o optimizar para que responda más rápido.
2. Si no es posible corregir o optimizar el servidor de backend, o bien se sabe que el servidor de backend tarda más tiempo que el tiempo de espera configurado, aumenta el valor del tiempo de espera en el router y el Message Processor a un valor adecuado.

Situación 2: El router agota el tiempo de espera antes de que respondan el Message Processor o el servidor de backend

Es posible que recibas errores 504 Gateway Timeout si el router agota el tiempo de espera antes de que responda el procesador de mensajes o el servidor de backend. Esto puede ocurrir en una de las siguientes circunstancias:

• El valor de tiempo de espera establecido en el Router es más corto que el valor de tiempo de espera establecido en el Message Processor. Por ejemplo, supongamos que el tiempo de espera del Router es de 50 segundos, mientras que el del Message Processor es de 55 segundos.

  Tiempo de espera en el router	Se agotó el tiempo de espera en el procesador de mensajes
  50 segundos	55 segundos

• El valor de tiempo de espera en el Message Processor se anula con un valor de tiempo de espera más alto usando la propiedad io.timeout.millis establecida en la configuración del extremo de destino del proxy de API:

  Por ejemplo, si se configuran los siguientes valores de tiempo de espera:

  Tiempo de espera en el router	Se agotó el tiempo de espera en el procesador de mensajes	Tiempo de espera dentro del proxy de API
  57 segundos	55 segundos	120 segundos

  Sin embargo, el valor de io.timeout.millis se establece en 120 segundos en el proxy de API:

  <HTTPTargetConnection>
       <Properties>
            <Property name="io.timeout.millis">120000</Property>
        </Properties>
        <URL>http://www.apigee.com</URL>
  </HTTPTargetConnection>

  Luego, el Message Processor no agotará el tiempo de espera después de 55 segundos, aunque su valor de tiempo de espera (55 segundos) sea menor que el valor de tiempo de espera del router (57 segundos). Esto se debe a que el valor de tiempo de espera de 55 segundos en el Message Processor se anula con el valor de 120 segundos que se establece dentro del proxy de API. Por lo tanto, el valor de tiempo de espera del Message Processor para este proxy de API específico será de 120 segundos.

  Dado que el router tiene un valor de tiempo de espera más bajo (57 segundos) en comparación con los 120 segundos establecidos en el proxy de API, el router agotará el tiempo de espera si el servidor de backend no responde después de 57 segundos.

Diagnóstico

1. Verifica el registro de acceso de NGINX (/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log)

2. Si el enrutador agota el tiempo de espera antes que el Message Processor, verás el estado 504 en los registros de acceso de NGINX para la solicitud a la API específica y el message id del Message Processor se establecerá como -. Esto se debe a que el Router no recibió ninguna respuesta del Message Processor dentro del período de tiempo de espera establecido en el router.

   Ejemplo de entrada de registro de NGINX que muestra el error 504 debido al tiempo de espera del enrutador

   

3. En el ejemplo anterior, observa el estado de 504 en NGINX, el ID del mensaje del Message Processor es - y el tiempo total transcurrido es de 57.001 segundos. Esto se debe a que el router agotó el tiempo de espera después de 57.001 segundos y no recibimos ninguna respuesta del Message Processor.
4. En este caso, verás excepciones de Broken Pipe en los registros del procesador de mensajes (/opt/apigee/var/log/edge-message-processor/logs/system.log).

   2017-06-09 00:00:25,886 org:myorg env:test api:myapi-v1 rev:23 messageid:rrt-mp01-18869-23151-1  NIOThread@1 INFO  HTTP.SERVICE - ExceptionHandler.handleException() : Exception java.io.IOException: Broken pipe occurred while writing to channel ClientOutputChannel(ClientChannel[A:XX.XX.XX.XX:8998 Remote host:YY.YY.YY.YY:51400]@23751 useCount=1 bytesRead=0 bytesWritten=486 age=330465ms  lastIO=0ms )
   2017-06-09 00:00:25,887  org:myorg env:test api:myapi-v1 rev:23 messageid:rrt-mp01-18869-23151-1  NIOThread@1 INFO  HTTP.SERVICE - ExceptionHandler.handleException() : Exception trace:
   java.io.IOException: Broken pipe
           at com.apigee.nio.channels.ClientOutputChannel.writePending(ClientOutputChannel.java:51) ~[nio-1.0.0.jar:na]
           at com.apigee.nio.channels.OutputChannel.onWrite(OutputChannel.java:116) ~[nio-1.0.0.jar:na]
           at com.apigee.nio.channels.OutputChannel.write(OutputChannel.java:81) ~[nio-1.0.0.jar:na]
            … <snipped>

Este error se muestra porque, una vez que se agota el tiempo de espera del router, se cierra la conexión con el Message Processor. Cuando el Message Processor completa su procesamiento, intenta escribir la respuesta en el router. Como la conexión al router ya está cerrada, obtienes el Broken Pipe exception en Message Processor.

Se espera que esta excepción se vea en las circunstancias explicadas anteriormente. Por lo tanto, la causa real del error 504 Gateway Timeout sigue siendo que el servidor de backend tarda más en responder, y debes abordar ese problema.

Solución

1. Si se trata de un servidor de backend personalizado, entonces
   1. Comprueba por qué el servidor de backend tarda tanto en responder y ve si se puede corregir o optimizar para que responda más rápido.
   2. Si no es posible corregir o optimizar el servidor de backend, o bien se sabe que el servidor de backend tarda mucho tiempo, aumenta el valor de tiempo de espera en el router y el Message Processor.

      Idea: Establece el valor de tiempo de espera en los diferentes componentes en el siguiente orden: Tiempo de espera en el cliente > Tiempo de espera en el router > Tiempo de espera en el procesador de mensajes > Tiempo de espera dentro del proxy de API

2. Si se trata de un servidor de backend de Node.js, haz lo siguiente:
   1. Verifica si el código de NodeJS realiza llamadas a otros servidores de backend y si tarda mucho en devolver una respuesta. Verifica por qué los servidores de backend tardan más y soluciona el problema según corresponda.
   2. Verifica si los procesadores de mensajes experimentan un uso elevado de CPU o memoria:
      1. Si algún Message Processor experimenta un uso elevado de la CPU, genera tres volcados de subprocesos cada 30 segundos con el siguiente comando:

         JAVA_HOME/bin/jstack -l PID > FILENAME

      2. Si algún procesador de mensajes experimenta un uso elevado de memoria, genera un volcado de montón con el siguiente comando:

         sudo -u apigee JAVA_HOME/bin/jmap -dump:live,format=b,file=FILENAME PID

      3. Reinicia el Message Processor con el siguiente comando. Debería reducir el uso de CPU y memoria:

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

      4. Supervisa las llamadas a la API para confirmar si el problema persiste.
      5. Comunícate con el equipo de asistencia de Apigee Edge y proporciona los volcados de subprocesos, el volcado de montón y los registros de Message Processor (/opt/apigee/var/log/edge-message-processor/logs/system.log)para ayudar a investigar la causa del uso elevado de CPU o memoria.

Situación 3: Se agota el tiempo de espera de la aplicación cliente antes de que respondan el enrutador, el Message Processor o el servidor de backend

Es posible que recibas errores 504 Gateway Timeout si la aplicación cliente agota el tiempo de espera antes de que responda el servidor de backend. Esta situación puede ocurrir en los siguientes casos:

1. El valor de tiempo de espera establecido en la aplicación cliente es inferior al valor de tiempo de espera establecido en el router y el Message Processor:

   Por ejemplo, si se configuran los siguientes valores de tiempo de espera:

   Tiempo de espera agotado en el cliente	Tiempo de espera en el router	Se agotó el tiempo de espera en el procesador de mensajes
   50 segundos	57 segundos	55 segundos

   En este caso, el tiempo total disponible para obtener una respuesta a una solicitud a la API a través de Edge es <= 50 segundos. Esto incluye el tiempo que se tarda en realizar una solicitud a la API, el tiempo que Edge tarda en procesar la solicitud (Router, Message Processor), el tiempo que se tarda en enviar la solicitud al servidor de backend (si corresponde), el tiempo que el backend tarda en procesar la solicitud y enviar la respuesta, el tiempo que Edge tarda en procesar la respuesta y, finalmente, el tiempo que se tarda en enviarla de vuelta al cliente.

   Si el router no responde al cliente en un plazo de 50 segundos, el cliente agotará el tiempo de espera y cerrará la conexión con el router. El cliente recibirá el código de respuesta 504.

   Esto hará que NGINX establezca un código de estado de 499, que indica que el cliente cerró la conexión.

Diagnóstico

1. Si la aplicación cliente agota el tiempo de espera antes de recibir una respuesta del router, cerrará la conexión con el router. En esta situación, verás un código de estado 499 en los registros de acceso de NGINX para la solicitud a la API específica.

   Entrada de registro de NGINX de ejemplo que muestra el código de estado 499
   
   

2. En el ejemplo anterior, ten en cuenta que el estado de 499 en NGINX y el tiempo total transcurrido es de 50.001 segundos. Esto indica que el cliente agotó el tiempo de espera después de 50.001 segundos.
3. En este caso, verás excepciones de Broken Pipe en los registros del procesador de mensajes (/opt/apigee/var/log/edge-message-processor/logs/system.log).
   

   2017-06-09 00:00:25,886 org:myorg env:test api:myapi-v1 rev:23 messageid:rrt-1-11193-11467656-1  NIOThread@1 INFO  HTTP.SERVICE - ExceptionHandler.handleException() : Exception java.io.IOException: Broken pipe occurred while writing to channel ClientOutputChannel(ClientChannel[A:XX.XX.XX.XX:8998 Remote host:YY.YY.YY.YY:51400]@23751 useCount=1 bytesRead=0 bytesWritten=486 age=330465ms  lastIO=0ms )
   2017-06-09 00:00:25,887  org:myorg env:test api:myapi-v1 rev:23 messageid:rrt-1-11193-11467656-1  NIOThread@1 INFO  HTTP.SERVICE - ExceptionHandler.handleException() : Exception trace:
   java.io.IOException: Broken pipe
           at com.apigee.nio.channels.ClientOutputChannel.writePending(ClientOutputChannel.java:51) ~[nio-1.0.0.jar:na]
           at com.apigee.nio.channels.OutputChannel.onWrite(OutputChannel.java:116) ~[nio-1.0.0.jar:na]
           at com.apigee.nio.channels.OutputChannel.write(OutputChannel.java:81) ~[nio-1.0.0.jar:na]
            … <snipped>

4. Una vez que se agota el tiempo de espera del router, este cierra la conexión con el Message Processor. Cuando el Message Processor completa su procesamiento, intenta escribir la respuesta en el router. Como la conexión al router ya está cerrada, recibes el mensaje Broken Pipe exception en el Message Processor.
5. Esta excepción es esperada en las circunstancias explicadas anteriormente. Por lo tanto, la causa real del error 504 Gateway Timeout sigue siendo que el servidor de backend tarda mucho en responder, y debes abordar ese problema.

Solución

1. Si se trata de tu servidor de backend personalizado, haz lo siguiente:
   1. Revisa el servidor de backend para determinar por qué tarda más de 57 segundos y comprueba si se puede corregir o optimizar para que responda más rápido.
   2. Si no es posible corregir o optimizar el servidor de backend, o si sabes que tardará mucho tiempo, aumenta el valor de tiempo de espera en el router y el Message Processor.
      
      

      Idea: Establece el valor de tiempo de espera en los diferentes componentes en el siguiente orden: Tiempo de espera en el cliente > Tiempo de espera en el router > Tiempo de espera en el procesador de mensajes > Tiempo de espera dentro del proxy de API

2. Si es un backend de NodeJS, haz lo siguiente:
   1. Comprueba si el código de NodeJS realiza llamadas a otros servidores de backend y si tardan mucho en regresar. Comprueba por qué esos servidores de backend tardan más.
   2. Verifica si los procesadores de mensajes tienen un uso elevado de CPU o memoria:
      1. Si un Message Processor experimenta un uso elevado de la CPU, genera tres volcados de subprocesos cada 30 segundos con el siguiente comando:

         JAVA_HOME/bin/jstack -l PID > FILENAME

      2. Si un procesador de mensajes experimenta un uso elevado de memoria, genera un volcado de montón con el siguiente comando:

         sudo -u apigee JAVA_HOME/bin/jmap -dump:live,format=b,file=FILENAME PID

      3. Reinicia el Message Processor con el siguiente comando. Esto debería reducir el uso de CPU y memoria:

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

      4. Supervisa las llamadas a la API para confirmar si el problema persiste.
      5. Comunícate con el equipo de asistencia de Apigee Edge y proporciona los volcados de subprocesos, el volcado de montón y los registros de Message Processor (/opt/apigee/var/log/edge-message-processor/logs/system.log)para ayudarlos a investigar la causa del uso elevado de CPU o memoria.

Aumenta el valor de tiempo de espera en el router y el procesador de mensajes

Elige con cuidado los valores de tiempo de espera que se establecerán en el Router y el Message Processor según tus requisitos. No establezcas valores de tiempo de espera arbitrariamente grandes. Si necesitas ayuda, comunícate con el equipo de asistencia de Apigee Edge.

Router

chown apigee:apigee /opt/apigee/customer/application/router.properties

1. Crea el archivo /opt/apigee/customer/application/router.properties en la máquina del router si aún no existe.
2. Agrega la siguiente línea a este archivo:

   conf_load_balancing_load.balancing.driver.proxy.read.timeout=TIME_IN_SECONDS

   Por ejemplo, si deseas establecer el valor de tiempo de espera en 120 segundos, configúralo de la siguiente manera:

   conf_load_balancing_load.balancing.driver.proxy.read.timeout=120

3. Asegúrate de que este archivo sea propiedad de apigee:
4. Sigue estos pasos para reiniciar el router:

   /opt/apigee/apigee-service/bin/apigee-service edge-router restart

5. Si tienes más de un router, repite los pasos anteriores en todos ellos.

Message Processor

1. Crea el archivo /opt/apigee/customer/application/message-processor.properties en la máquina del Message Processor si aún no existe.
2. Agrega la siguiente línea a este archivo:

   conf_http_HTTPTransport.io.timeout.millis=TIME_IN_MILLISECONDS

   Por ejemplo, si deseas establecer el valor de tiempo de espera en 120 segundos, configúralo de la siguiente manera:

   conf_http_HTTPTransport.io.timeout.millis=120000

3. Asegúrate de que este archivo sea propiedad de apigee:

   chown apigee:apigee /opt/apigee/customer/application/message-processor.properties

4. Reinicia el Message Processor:

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

5. Si tienes más de un Message Processor, repite los pasos anteriores en todos los Message Processors.

Procesamiento lento de solicitudes a la API por parte de Edge

Si Edge es muy lento o tarda mucho en procesar la solicitud a la API, recibirás un error 504 Gateway Timeout.

Diagnóstico

1. Realiza un seguimiento de la API afectada en la IU de Edge.
2. Espera a que se produzca el error o, si tienes la llamada a la API, realiza algunas llamadas a la API y reproduce el error 504 Gateway Timeout.
3. Ten en cuenta que, en este caso, es posible que veas una respuesta exitosa en el registro.
   1. El router o el cliente agotan el tiempo de espera porque el Message Processor no responde dentro del período de tiempo de espera especificado en el router o el cliente (el que tenga el período de tiempo de espera más bajo). Sin embargo, el Message Processor continúa procesando la solicitud y puede completarla correctamente.
   2. Además, el valor de HTTPTransport.io.timeout.millis establecido en el Message Processor solo se activa si el Message Processor se comunica con un servidor de backend HTTP/HTTPS. En otras palabras, este tiempo de espera no se activará cuando alguna política (que no sea la política ServiceCallout) dentro del proxy de API tarde mucho tiempo.
4. Después de que se produzca el error, examina la solicitud específica que tiene el tiempo transcurrido más largo.
5. Verifica el tiempo transcurrido en cada fase y anota la fase en la que se dedica más tiempo.
6. Si observas el tiempo transcurrido más largo en cualquiera de las políticas que no sean la política Service Callout, esto indica que Edge tarda mucho en procesar la solicitud.
7. A continuación, se muestra un ejemplo de registro de IU que muestra un tiempo transcurrido muy alto en la política de JavaScript:

   

8. En el ejemplo anterior, observas que la política de JavaScript tarda una cantidad anormalmente larga de tiempo, alrededor de 245 segundos.

Solución

1. Comprueba si la política tardó mucho en responder y si hay algún código personalizado que podría tardar mucho en procesarse. Si hay código de ese tipo, intenta corregir o optimizar el código identificado.
2. Si no hay código personalizado que pueda causar un tiempo de procesamiento alto, verifica si los procesadores de mensajes tienen un uso elevado de CPU o memoria:
   1. Si algún Message Processor experimenta un uso elevado de la CPU, genera tres volcados de subprocesos cada 30 segundos con el siguiente comando:

      JAVA_HOME/bin/jstack -l PID > FILENAME

   2. Si algún procesador de mensajes tiene un uso elevado de memoria, genera un volcado de montón con el siguiente comando:

      sudo -u apigee JAVA_HOME/bin/jmap -dump:live,format=b,file=FILENAME PID

   3. Reinicia el Message Processor con el siguiente comando. Esto debería reducir el uso de la CPU y la memoria.

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

   4. Supervisa las llamadas a la API y confirma si el problema persiste.
   5. Comunícate con el equipo de asistencia de Apigee Edge y proporciona los volcados de subprocesos, el volcado de montón y los registros de Message Processor (/opt/apigee/var/log/edge-message-processor/logs/system.log)) para ayudarlos a investigar la causa del uso elevado de CPU o memoria.

Diagnostica problemas con la supervisión de API

La supervisión de API te permite aislar rápidamente las áreas con problemas para diagnosticar errores, problemas de rendimiento y latencia, y su fuente, como apps para desarrolladores, proxies de API, destinos de backend o la plataforma de API.

Sigue un caso de ejemplo que muestra cómo solucionar problemas de 5xx con tus APIs usando API Monitoring. Por ejemplo, puedes configurar una alerta para recibir una notificación cuando la cantidad de códigos de estado 504 supere un umbral determinado.