504 Gateway Timeout

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

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 código de estado HTTP: El error 504 Gateway Timeout indica que el cliente no recibió una respuesta oportuna de la puerta de enlace de Edge 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 de acceso típica para una solicitud a la API a través de la plataforma de Edge será 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 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 en 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 muestra 504 Gateway Timeout Error.

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

Ocurrencia de tiempo de espera Detalles
Se produce el tiempo de espera en Message Processor
  • El servidor de backend no responde al procesador de mensajes dentro de un tiempo de espera especificado en el procesador de mensajes.
  • Se agota el tiempo de espera del procesador de mensajes y se envía el estado de la respuesta como 504 Gateway Timeout al router.
Se agota el tiempo de espera en el router
  • El procesador de mensajes no responde al router dentro del tiempo de espera especificado en el router.
  • Se agota el tiempo de espera del router y se envía el estado de la respuesta como 504 Gateway Timeout a la aplicación cliente.
Se produce un tiempo de espera en la aplicación cliente
  • El router no responde a la aplicación cliente dentro del tiempo de espera especificado en el router.
  • Se agota el tiempo de espera de la aplicación cliente y se finaliza el estado de la 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 que se proporcionan para
Servidor de backend lento El servidor de backend que procesa la solicitud a la API es demasiado lento debido a una carga alta o un rendimiento deficiente. Usuarios de nubes públicas y privadas
Procesamiento lento de solicitudes a la API por parte de Edge Edge tarda mucho tiempo en procesar la solicitud a la API debido a la carga alta o el rendimiento bajo.

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. Se agota el tiempo de espera del Message Processor antes de que el servidor de backend responda.
  2. Se agota el tiempo de espera del router antes de que el servidor de backend o procesador de mensajes responda.
  3. La aplicación cliente se agota antes de que responda el router, el procesador de mensajes 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 se agota 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 que el servidor de backend es lento.

Procedimiento 1: Usa Trace

Si el problema sigue activo (aún se producen errores 504), sigue los pasos que se indican a continuación:

  1. Haz 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 produzca 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 a la que se dedica la mayor parte del 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 seguimiento de muestra 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 registro anterior, el procesador de mensajes se agota después de 55,002 ms, ya que el servidor de backend no responde.

Procedimiento 2: Usa los registros de Message Processor

  1. Verifica el registro del Message Processor (/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 el tiempo de espera del procesador de mensajes se agotó.

    Registro de muestra del procesador de mensajes que muestra un 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 anterior del procesador de mensajes, 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=55000ms). Como resultado, el Message Processor agotó el tiempo de espera y envió el error 504 Gateway Timeout.

    Consulta este artículo: ¿Cómo se controla el tiempo de espera en el procesador de mensajes?

    • Cómo se controla el tiempo de espera en el procesador de mensajes Los procesadores de mensajes generalmente 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 Message Processor.
      • Si el servidor de backend no responde en 55 segundos, el procesador de mensajes se agota y envía un error 504 Gateway Timeout al cliente.
    • El valor de tiempo de espera especificado en el procesador de mensajes 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 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 procesador de mensajes se agota y envía un error 504 Gateway Timeout al cliente.

Solució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 o optimizar el servidor de backend, o si 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 procesador de mensajes a un valor adecuado.

Situación #2: El router se agota antes de que el procesador de mensajes o el servidor de backend respondan

Es posible que recibas errores 504 Gateway Timeout si el router se agota 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 procesador de mensajes. Por ejemplo, supongamos que el tiempo de espera del router es de 50 segundos, mientras que el del procesador de mensajes es de 55 segundos.
    Tiempo de espera en el router Se agotó el tiempo de espera en Message Processor
    50 segundos 55 segundos
  • El valor de tiempo de espera del procesador de mensajes se anula con un valor de tiempo de espera 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 establecen los siguientes valores de tiempo de espera:

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

    Sin embargo, el 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 procesador de mensajes no se agotará después de 55 segundos, aunque su valor de tiempo de espera (55 segundos) sea inferior al 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 procesador de mensajes se anula por el valor de 120 segundos que se establece 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 configurados en el proxy de API, se agotará el tiempo de espera del router 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 que el 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 del Message Processor se configurará como -. Esto se debe a que el router no recibió ninguna respuesta del procesador de mensajes dentro del tiempo de espera establecido en el router.

    Ejemplo de entrada de registro de NGINX que muestra un error 504 debido a que el router agotó el tiempo de espera

  3. En el ejemplo anterior, observa el estado de 504 en NGINX, el ID de mensaje del procesador de mensajes es - y el tiempo transcurrido total 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 procesador de mensajes.
  4. En este caso, verás excepciones Broken Pipe en los registros del 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, cierra la conexión con el procesador de mensajes. Cuando el procesador de mensajes 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 el procesador de mensajes.

Se espera que se vea esta excepción 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 tiempo en responder, y debes abordar ese problema.

Solución

  1. Si es un servidor de backend personalizado, ocurrirá lo siguiente:
    1. Verifica por qué el servidor de backend tarda mucho tiempo en responder y observa si se puede corregir, optimizar para responder más rápido.
    2. Si no es posible optimizar ni corregir el servidor de backend o es un hecho conocido que este tarda mucho tiempo, aumenta el valor de tiempo de espera del router y el procesador de mensajes.

      Idea: Configura 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 API
  2. Si es un servidor de backend de NodeJS, haz lo siguiente:
    1. Verifica si el código de NodeJS realiza llamadas a otros servidores de backend y si tarda mucho en mostrar una respuesta. Verifica por qué los servidores de backend tardan más tiempo y corrige el problema según corresponda.
    2. Verifica si los procesadores de mensajes tienen un uso alto de CPU o memoria:
      1. Si algún procesador de mensajes tiene 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 procesador de mensajes con el siguiente comando. Debe 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 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 alto uso de CPU o 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 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 procesador de mensajes. Por lo tanto, incluso si un servidor de backend de NodeJS tarda mucho tiempo, el procesador de mensajes no se agotará.
  • Sin embargo, si el servidor de backend NodeJS tarda mucho y si el tiempo que tarda 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 responda el router, el procesador de mensajes o el servidor de backend

Es posible que recibas errores 504 Gateway Timeout si la aplicación cliente se agota antes de que el servidor de backend responda. Esta situación puede ocurrir 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 establecen los siguientes valores de tiempo de espera:

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

    Si el router no responde al cliente en un plazo de 50 segundos, el cliente se agotará 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 indique que el cliente cerró la conexión.

Diagnóstico

  1. Si se agota el tiempo de espera de la aplicación cliente antes de recibir una respuesta del router, se cerrará la conexión con este. 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 NGINX y el tiempo total transcurrido es de 50.001 segundos. Esto indica que se agotó el tiempo de espera del cliente después de 50.001 segundos.
  3. En este caso, verás excepciones Broken Pipe en los registros del 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. Después de que se agote el tiempo de espera del router, se cerrará la conexión con el procesador de mensajes. Cuando el procesador de mensajes 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 el procesador de mensajes.
  5. Se espera esta excepción 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 es tu servidor de backend personalizado, haz lo siguiente:
    1. Verifica 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 este tardará mucho tiempo, aumenta el valor del tiempo de espera en el router y el procesador de mensajes.

      Idea: Configura 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 API
  2. Si es un backend de NodeJS, haz lo siguiente:
    1. Verifica si el código NodeJS realiza llamadas a algún otro servidor de backend y si eso tarda mucho tiempo en devolverse. Verifica por qué esos servidores de backend tardan más tiempo.
    2. Comprueba si los procesadores de mensajes tienen un alto uso de CPU o memoria:
      1. Si un procesador de mensajes usa una gran cantidad de 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 tiene un uso de memoria alto, 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 procesador de mensajes con el siguiente comando. 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 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 alto uso de CPU o memoria).

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

Elige los valores de tiempo de espera que se establecerán en el router y el procesador de mensajes con cuidado según tus requisitos. No configures valores de tiempo de espera arbitrariamente grandes. Si necesitas asistencia, 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 del 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 apigee sea el propietario de este archivo:
  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.

Message Processor

  1. Crea el archivo /opt/apigee/customer/application/message-processor.properties en la máquina del procesador de mensajes 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 del tiempo de espera en 120 segundos, configúralo de la siguiente manera:

    conf_http_HTTPTransport.io.timeout.millis=120000
  3. Asegúrate de que el propietario de este archivo sea apigee: 
    chown apigee:apigee /opt/apigee/customer/application/message-processor.properties
  4. Reinicia el procesador de mensajes: 
    /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.

Idea: Establece el valor del 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 API

Procesamiento lento de solicitudes a la API por 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. Haz 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 correcta en el seguimiento.
    1. Se agota el tiempo de espera del router o cliente, ya que el procesador de mensajes no responde dentro del 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 procesador de mensajes continúa procesando la solicitud y es posible que se complete correctamente.
    2. Además, el valor HTTPTransport.io.timeout.millis establecido en Message Processor se activa solo si este 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 Service conformidad) dentro del proxy de API tarde mucho tiempo.
  4. Después de que se produzca el error, examina la solicitud específica que tenga el tiempo transcurrido más largo.
  5. Verifica el tiempo transcurrido en cada fase y anota la fase en la que se pasa más tiempo.
  6. Si observas el tiempo transcurrido más largo en cualquiera de las políticas que no sean la política de texto destacado de servicio, eso indica que Edge está tardando mucho tiempo en procesar la solicitud.
  7. Este es un ejemplo de seguimiento de la IU en el que se muestra el tiempo transcurrido muy alto en la política de JavaScript:

  8. En el ejemplo anterior, observas que la política de JavaScript tarda un tiempo anormalmente largo de aproximadamente 245 segundos.

Solución

  1. Verifica si la política tardó mucho tiempo en responder y si hay algún código personalizado que pueda tardar mucho tiempo en procesarse. Si hay algún código de este tipo, comprueba si puedes corregirlo o optimizarlo.
  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 procesador de mensajes tiene 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. Usa el siguiente comando para reiniciar el 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 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 alto uso de CPU o memoria.

Diagnostica problemas con la supervisión de API

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

Revisa una situación de ejemplo en la que se muestra cómo solucionar problemas de 5xx con tus APIs mediante el monitoreo de APIs. Por ejemplo, es posible que desees configurar una alerta para recibir una notificación cuando la cantidad de códigos de estado 504 supere un umbral determinado.