504 Gateway Timeout

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 como respuesta a las llamadas a la API.

El error 504 Gateway Timeout del código de estado HTTP 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 las puertas de enlace?

La ruta de acceso típica para una solicitud a la API a través de la plataforma perimetral es Cliente -> Router -> Procesador de mensajes -> Servidor de backend, como se muestra en la siguiente figura:

La aplicación cliente, los routers y los procesadores de mensajes dentro de la plataforma Edge se configuran con valores de tiempo de espera adecuados. La plataforma perimetral espera que se envíe una respuesta dentro de un período determinado por cada solicitud a la API, según los valores de tiempo de espera. Si no obtienes la respuesta dentro del período especificado, se muestra 504 Gateway Timeout Error.

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

Tiempo de espera Detalles
El tiempo de espera ocurre en Message Processor
  • El servidor de backend no responde a Message Processor dentro de un tiempo de espera especificado.
  • Message Processor agota el tiempo de espera y envía el estado de respuesta como 504 Gateway Timeout al router.
El tiempo de espera ocurre en el router
  • Message Processor no responde al router dentro del tiempo de espera especificado.
  • El router agota el tiempo de espera y envía el estado de respuesta como 504 Gateway Timeout a la aplicación cliente.
El tiempo de espera se produce en la aplicación cliente
  • El router no responde a la aplicación cliente dentro del tiempo de espera especificado.
  • La aplicación cliente agota el tiempo de espera y finaliza el estado de respuesta como 504 Gateway Timeout para el usuario final.

Causas posibles

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

Causa Detalles Pasos dados para
Servidor de backend lento El servidor de backend que procesa la solicitud a la API es demasiado lento debido a la carga alta o al rendimiento deficiente. Usuarios de nubes públicas y privadas
Procesamiento lento de solicitud a la API por parte de Edge Edge tarda mucho tiempo en procesar la solicitud a la API debido a la carga alta o al rendimiento deficiente.

Servidor de backend lento

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

  1. El tiempo de espera del procesador de mensajes se agota antes de que el servidor de backend responda.
  2. Se agota el tiempo de espera del router antes de que el procesador de mensajes o el servidor de backend responda.
  3. Se agota el tiempo de espera de la aplicación cliente antes de que el router, el procesador de mensajes y el servidor de backend respondan.

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

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

Diagnóstico

Puedes usar los siguientes procedimientos para diagnosticar si el error 504 Gateway Timeout se produjo debido a que el servidor de backend es lento.

Procedimiento n.o 1 con Trace

Si el problema sigue activo (todavía se producen errores 504), sigue estos pasos:

  1. Hacer un seguimiento de la API afectada en la IU de Edge Espera a que ocurra 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 toma nota de la fase en la que se pasa la mayor 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 que está tardando mucho tiempo en procesar la solicitud:
    • Se envió la solicitud al servidor de destino
    • Política ServiceCallout

A continuación, se proporciona un seguimiento de muestra que indica 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 tiempo de espera de Message Processor se agota después de 55,002 ms, ya que el servidor de backend no responde.

Procedimiento 2: Usa registros de 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 un momento específico, esto indica que Message Processor se agotó el tiempo de espera.

    Ejemplo de registro del procesador de mensajes que muestra el error de tiempo de espera de la puerta de enlace

    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 de Message Processor anterior, observas que el servidor de backend indicado con la dirección IP XX.XX.XX.XX no respondió ni siquiera después de 55 segundos (lastIO=55000ms). Como resultado, se agotó el tiempo de espera de Message Processor y se envió el error 504 Gateway Timeout.

    Comprueba lo siguiente: ¿Cómo se controla el tiempo de espera en Message Processor?

    • Cómo se controla el tiempo de espera en Message Processor. Por lo general, los procesadores de mensajes se configuran 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 que entrega este procesador de mensajes.
      • Si el servidor de backend no responde en 55 segundos, se agota el tiempo de espera del procesador de mensajes y se envía el error 504 Gateway Timeout al cliente.
    • La propiedad io.timeout.millis especificada en el proxy de API puede anular el valor de tiempo de espera especificado en Message Processor. Este valor de tiempo de espera se aplica a un proxy de API específico en el que se especifica la propiedad antes mencionada. Por ejemplo, si io.timeout.millis se establece en 10 segundos dentro del proxy de API, se utilizará el valor de tiempo de espera de 10 segundos para este proxy de API específico.
      • Si el servidor de backend no responde en 10 segundos al proxy de API específico, se agota el tiempo de espera de Message Processor y se envía el error 504 Gateway Timeout al cliente.

Resolución

  1. Verifica por qué el servidor de backend tarda más de 55 segundos y comprueba si se puede corregir o optimizar para que responda más rápido.
  2. Si no es posible corregir ni optimizar el servidor de backend o si se sabe que este tarda más tiempo que el tiempo de espera configurado, aumenta el valor de tiempo de espera en el router y el procesador de mensajes a un valor adecuado.

Situación 2: Se agota el tiempo de espera del router antes de que el procesador de mensajes o el servidor de backend respondan

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

  • El valor de tiempo de espera configurado en el router es menor que el valor de tiempo de espera configurado en el procesador de mensajes. Por ejemplo, supongamos que el tiempo de espera en el router es de 50 segundos, mientras que el procesador de mensajes es de 55 segundos.
    Tiempo de espera en el router Tiempo de espera en Message Processor
    50 segundos 55 segundos
  • El valor de tiempo de espera en Message Processor se anula con un valor más alto mediante 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 Tiempo de espera en Message Processor Tiempo de espera dentro del proxy de API
    57 segundos 55 segundos 120 segundos

    Sin embargo, 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>
    

    De esta manera, Message Processor no agotará el tiempo de espera después de 55 segundos, aunque su valor sea inferior al del router (57 segundos). Esto se debe a que el valor de tiempo de espera de 55 segundos en Message Processor se anula por el valor de 120 segundos establecido en el proxy de API. Por lo tanto, el valor del 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 se agota el tiempo de espera del router antes de Message Processor, verás el estado de 504 en los registros de acceso de NGINX para la solicitud a la API específica, y el message id de Message Processor se establecerá como -. Esto se debe a que el router no recibió ninguna respuesta del Message Processor dentro del tiempo de espera establecido en el router.

    Ejemplo de entrada de registro de NGINX que muestra el código 504 debido al tiempo de espera del router

  3. En el ejemplo anterior, observa el estado de 504 en NGINX, el ID del mensaje del procesador de mensajes es - y el tiempo total transcurrido es 57,001 segundos. Esto se debe a que se agotó el tiempo de espera del router después de 57.001 segundos y no recibimos ninguna respuesta del Message Processor.
  4. En este caso, verás excepciones Broken Pipe en los registros de Message Processor (/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 Message Processor. Cuando Message Processor completa su procesamiento, intenta escribir la respuesta en el router. Como la conexión con el router ya está cerrada, obtendrás Broken Pipe exception en Message Processor.

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

Resolución

  1. Si se trata de un servidor de backend personalizado, entonces:
    1. Verifica por qué el servidor de backend tarda mucho en responder 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 es un hecho conocido de que el servidor de backend tarda mucho tiempo, aumenta el valor de tiempo de espera en el router y el procesador de mensajes.

      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 en el proxy de la API

  2. Si es un servidor de backend de Node.js, entonces:
    1. Verifica si el código NodeJS realiza llamadas a cualquier otro servidor de backend y si tarda mucho tiempo en mostrar una respuesta. Verifica por qué los servidores de backend tardan más tiempo y soluciona el problema según corresponda.
    2. 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 CPU, genera tres volcados de subprocesos cada 30 segundos con el siguiente comando:
        JAVA_HOME/bin/jstack -l PID > FILENAME
      2. Si algún Message Processor 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. 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
      4. Supervisa las llamadas a la API para confirmar si el problema aún existe.
      5. Comunícate con el equipo de asistencia de Apigee Edge y proporciona los registros de volcados de subprocesos, volcado de montón y 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.

Verifica lo siguiente: Cómo se controla el tiempo de espera de los servidores de backend de NodeJS en Message Processor

  • El servidor de backend NodeJS se ejecuta dentro del proceso de JVM de Message Processor. El valor de tiempo de espera para los servidores de backend de NodeJS se controla a través de la propiedad http.request.timeout.seconds en el archivo nodejs.properties. Esta propiedad se establece en 0 de forma predeterminada, es decir, el tiempo de espera está inhabilitado de forma predeterminada para todos los proxies de API que pertenecen a una organización que entrega este Message Processor. Por lo tanto, incluso si un servidor de backend NodeJS tarda mucho tiempo, Message Processor no agotará el tiempo de espera.
  • Sin embargo, si el servidor de backend NodeJS tarda mucho y si el tiempo que demora la solicitud a la API es superior a 57 segundos, el router agotará el tiempo de espera y enviará el error 504 Gateway Timeout al cliente.

Situación 3: Se agota el tiempo de espera de la aplicación cliente antes de que el router, el procesador de mensajes y el servidor de backend respondan

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

  1. El valor de tiempo de espera establecido en la aplicación cliente es menor que el valor de tiempo de espera establecido en el router y el procesador de mensajes:

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

    Tiempo de espera en el cliente Tiempo de espera en el router Tiempo de espera en Message Processor
    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 de 50 segundos o menos. Esto incluye el tiempo que tarda en realizar una solicitud a la API, el procesamiento de la solicitud por parte de Edge (router o procesador de mensajes), la solicitud que se envía al servidor de backend (si corresponde), el backend que procesa la solicitud y el envío de la respuesta, el procesamiento perimetral de la respuesta y, por último, la envía al cliente.

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

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

Diagnóstico

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

    Ejemplo de entrada de registro de NGINX que muestra el código de estado 499

  2. En el ejemplo anterior, ten en cuenta que el estado de 499 en el NGINX y el tiempo total transcurrido es de 50,001 segundos. Esto indica que el tiempo de espera del cliente se agotó después de 50.001 segundos.
  3. En este caso, verás excepciones Broken Pipe en los registros de Message Processor (/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. Cuando se agota el tiempo de espera del router, se cierra la conexión con Message Processor. Cuando el procesador de mensajes completa su procesamiento, intenta escribir la respuesta en el router. Como la conexión al router ya está cerrada, obtendrás el Broken Pipe exception en Message Processor.
  5. Se espera esta excepción en las circunstancias explicadas anteriormente. Por lo tanto, la causa real del error 504 Gateway Timeout es que el servidor de backend tarda mucho tiempo en responder y debes solucionar ese problema.

Resolución

  1. Si se trata de tu servidor de backend personalizado, haz lo siguiente:
    1. Verifica el servidor de backend a fin de determinar por qué tarda más de 57 segundos y verifica si se puede optimizar o corregir para que responda más rápido.
    2. Si no es posible corregir o optimizar el servidor de backend, o si sabes que este tardará mucho tiempo, aumenta el valor de tiempo de espera en el router y en 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 en el proxy de la API

  2. Si es un backend de Node.js, entonces:
    1. Verifica si el código NodeJS realiza llamadas a cualquier otro servidor de backend y si eso está tardando mucho tiempo en devolverse. Verifica por qué esos servidores de backend tardan más tiempo.
    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 CPU, genera tres volcados de subprocesos cada 30 segundos con el siguiente comando:
        JAVA_HOME/bin/jstack -l PID > FILENAME
      2. Si un Message Processor 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. Usa el siguiente comando para reiniciar Message Processor. Esto debería reducir la CPU y la memoria:
        /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
      4. Supervisa las llamadas a la API para confirmar si el problema aún existe.
      5. Comunícate con el equipo de asistencia de Apigee Edge 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 ayudarlos a investigar la causa del alto uso de CPU/memoria.

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

Elige con cuidado los valores de tiempo de espera que se configurarán en el router y el procesador de mensajes según tus requisitos. No establezcas valores de tiempo de espera grandes de manera arbitraria. 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 de 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. Reinicia 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.

Procesador de mensajes

  1. Crea el archivo /opt/apigee/customer/application/message-processor.properties en la máquina de 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 de 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 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 ellos.

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 en el proxy de la API

Procesamiento lento de solicitudes a la API por parte de Edge

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

Diagnóstico

  1. Hacer un seguimiento de la API afectada en la IU de Edge
  2. Espera a que ocurra 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 correcta en Trace.
    1. Se agota el tiempo de espera del router o del cliente, ya que Message Processor no responde dentro del tiempo de espera especificado en el router o cliente (el que tenga el período de espera más bajo). Sin embargo, Message Processor continúa con el procesamiento de la solicitud y puede completarse con éxito.
    2. Además, el valor HTTPTransport.io.timeout.millis configurado en Message Processor se activa solo si este último se comunica con un servidor de backend HTTP/HTTPS. En otras palabras, este tiempo de espera no se activará cuando una política (que no sea la de ServiceReferencia) del proxy de API demore mucho tiempo.
  4. Después de que se haya producido el error, examina la solicitud específica que tiene el tiempo transcurrido más largo.
  5. Verifica el tiempo transcurrido en cada fase y toma nota de la fase en la que se pasa más tiempo.
  6. Si observas el tiempo transcurrido más largo en alguna de las políticas que no sean la política Service Además de la política, esto indica que Edge está tardando mucho tiempo en procesar la solicitud.
  7. A continuación, se muestra un ejemplo de seguimiento de IU que muestra un tiempo transcurrido muy alto en la política de JavaScript:

  8. En el ejemplo anterior, notas que la política de JavaScript tarda unos 245 segundos aproximadamente.

Resolución

  1. Verifica si la política tardó mucho tiempo en responder y si existe algún código personalizado que pueda tardar mucho tiempo en procesarse. Si existe alguno de esos códigos, intenta corregir o optimizar el código identificado.
  2. Si no hay un 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 CPU, genera tres volcados de subprocesos cada 30 segundos con el siguiente comando:
      JAVA_HOME/bin/jstack -l PID > FILENAME
    2. Si algún Message Processor 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. Usa el siguiente comando para reiniciar Message Processor. Esto debería reducir 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 aún existe.
    5. Comunícate con el equipo de asistencia de Apigee Edge y proporciónale los volcados de subprocesos, el volcado de montón y los registros del procesador de mensajes (/opt/apigee/var/log/edge-message-processor/logs/system.log)para ayudarlos a investigar la causa del alto uso de CPU/memoria.

Diagnostica problemas con la supervisión de API

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 origen, como apps para desarrolladores, proxies de API, objetivos de backend o la plataforma de API.

Analiza una situación de ejemplo en la que se demuestra cómo solucionar problemas 5xx de tus APIs con la supervisión de APIs. Por ejemplo, es posible que desees configurar una alerta para que se te notifique cuando la cantidad de códigos de estado 504 supera un umbral en particular.