Estás viendo la documentación de Apigee Edge.
Ve a 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 para las llamadas a la API
El error 504 Gateway Timeout
del código de estado HTTP indica que el cliente
no recibieron 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 perimetral será Client -> Router -> Procesador de mensajes -> Backend Server, como se muestra en la siguiente figura:
La aplicación cliente, los routers y los procesadores de mensajes de la plataforma perimetral se configuran con
valores de tiempo de espera adecuados. La plataforma perimetral espera que se envíe una respuesta en un período determinado
de tiempo para cada solicitud a la API
según los valores de tiempo de espera. Si no recibes la respuesta en un plazo
durante el 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:
Tiempo de espera de caso | Detalles |
---|---|
Se produce el tiempo de espera en Message Processor |
|
Se agota el tiempo de espera en el router |
|
Se produce el tiempo de espera en la aplicación cliente |
|
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 una carga 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 mala rendimiento. |
Lenta servidor de backend
Si el servidor de backend es muy lento o tarda mucho tiempo en procesar la solicitud a la API, entonces
recibirás un error 504 Gateway Timeout
. Como se explicó en la sección anterior, el tiempo de espera puede
se producen en una de las siguientes situaciones:
- Message Processor agota el tiempo de espera antes de que el servidor de backend responda.
- Se agota el tiempo de espera del router antes de que el servidor de backend o procesador de mensajes responda.
- Se agota el tiempo de espera de la aplicación cliente antes de que el router, procesador de mensajes o servidor de backend responda.
En las siguientes secciones, se describe cómo diagnosticar y resolver el problema en cada uno de estos reales.
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 se produjo el error 504 Gateway Timeout
debido al servidor de backend lento.
Procedimiento 1: Usa Trace
Si el problema persiste (504
todavía se producen errores), sigue los pasos que se indican a continuación.
pasos:
- Hacer un seguimiento de la API afectada en la IU de Edge. Espera a que se produzca el error o si
Luego, realiza algunas llamadas a la API y reproduce el error
504 Gateway Timeout
. - Una vez que se produjo el error, examina la solicitud específica que muestra el código de respuesta como
504
- Comprueba el tiempo transcurrido en cada fase y toma nota de la fase en la que se reduce la mayor cantidad del tiempo. de los recursos que gastas.
- Si observas el error con el tiempo transcurrido más largo inmediatamente después de uno de
siguientes fases, indica que el servidor de backend es lento o tarda 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 en el que se indica que el servidor de backend ni siquiera respondió
después de 55 segundos, lo que genera un error 504 Gateway Timeout
:
En el seguimiento anterior, Message Processor agota el tiempo de espera después de 55,002 ms como lo hace el servidor de backend no responden.
Procedimiento 2: Usa los registros de Message Processor
- Cómo consultar el registro de Message Processor
(
/opt/apigee/var/log/edge-message-processor/logs/system.log
) -
Si encuentras errores
Gateway Timeout
yonTimeoutRead
para la solicitud específica del proxy de API. en un momento determinado, significa que se agotó el tiempo de espera del Message Processor.Ejemplo de registro del procesador de mensajes en el que se 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 backend denotado con la IP dirección XX.XX.XX.XX no respondió, incluso después de 55 segundos (lastIO=55,000ms). Como resultado, se agotó el tiempo de espera de Message Processor y se envió un error
504 Gateway Timeout
.Verifica lo siguiente: ¿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 ser
se establece 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 es se aplicará a todos los proxies de API que pertenezcan a una organización que cumpla con esta Message Processor.- Si el servidor de backend no responde en 55 segundos, el mensaje
Se agota el tiempo de espera del procesador y se envía
504 Gateway Timeout
error al cliente.
- Si el servidor de backend no responde en 55 segundos, el mensaje
Se agota el tiempo de espera del procesador y se envía
- El valor de tiempo de espera especificado en Message Processor puede ser
anulado por la propiedad
io.timeout.millis
especificadas dentro del proxy de API. Este valor de tiempo de espera se aplica a una API específica Proxy en el que se especifica la propiedad antes mencionada. Por ejemplo, si elio.timeout.millis
se configura en 10 segundos en el proxy de API; luego, 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 10 segundos a la respuesta
proxy de API, se agota el tiempo de espera de Message Processor y envía
504 Gateway Timeout
error al cliente.
- Si el servidor de backend no responde en 10 segundos a la respuesta
proxy de API, se agota el tiempo de espera de Message Processor y envía
- Cómo se controla el tiempo de espera en Message Processor Los procesadores de mensajes suelen ser
se establece con un valor de tiempo de espera predeterminado de 55 segundos) a través de la propiedad.
Solución
- Comprueba por qué el servidor de backend tarda más de 55 segundos y observa si se puede se corrigen/optimizan para responder más rápido.
- Si no es posible corregir u optimizar el servidor de backend o si se sabe que el servidor el servidor tarda más que el tiempo de espera configurado y, luego, Aumenta el valor de tiempo de espera del router y del procesador de mensajes a un valor adecuado.
Situación No 2: Se agota el tiempo de espera del router antes de que el procesador de mensajes o el servidor de backend responda.
Es posible que recibas errores 504 Gateway Timeout
si se agota el tiempo de espera del router antes de que aparezca el mensaje
el procesador/servidor de backend responde. Esto puede suceder en una de las siguientes circunstancias:
- El valor de tiempo de espera establecido en el router es menor que el valor de tiempo de espera establecido en el mensaje.
Procesador. Por ejemplo, supongamos que el tiempo de espera del router es de 50 segundos, mientras que el mensaje
El procesador dura 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 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 Tiempo de espera en Message Processor Tiempo de espera en el proxy de API 57 segundos 55 segundos 120 segundos Sin embargo,
io.timeout.millis
está configurado 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, Message Processor no agota el tiempo de espera después de 55 segundos aunque haya transcurrido (55 segundos) es 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 Message Processor se anula con el valor de 120 segundos que se configura en el proxy de API. Entonces, el valor de tiempo de espera del Message Processor para este proxy de API específico serán 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
- Verifica el registro de acceso de NGINX
(
/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log
) -
Si se agota el tiempo de espera del router 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 elmessage id
de Message Processor se configurará 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 una entrada de registro de NGINX que muestra 504 debido a que se agotó el tiempo de espera del router
- En el ejemplo anterior, observa el estado de
504
en NGINX, el ID del mensaje de la El procesador 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 obtuvimos ninguna respuesta del Message Processor. - En este caso, verás
Broken Pipe
excepciones en la sección Mensaje Registros del procesador (/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>
Se muestra este error porque, una vez que se agota el tiempo de espera del router, se cierra la conexión con el
Message Processor. Cuando el procesador de mensajes completa su procesamiento, intenta escribir el
respuesta al router. Como la conexión al router ya está cerrada, obtendrás el
Broken Pipe exception
en Message Processor
Se espera que esta excepción se vea en las circunstancias explicadas anteriormente. Entonces,
La causa del error 504 Gateway Timeout
sigue siendo el servidor de backend que tarda más tiempo en responder.
y necesitas resolver ese problema.
Solución
- Si es un servidor backend personalizado,
- Verifica por qué el servidor de backend tarda mucho tiempo en responder y observa si es posible se corrigen/optimizan para responder más rápido.
- Si no es posible corregir u optimizar el servidor de backend o es un hecho conocido que el
el servidor de backend tarda mucho tiempo. Luego, aumenta el valor del tiempo de espera en
Router y procesador de mensajes.
Idea: Configure el valor de tiempo de espera en los diferentes componentes de las siguientes secciones: pedido:
Tiempo de espera en el cliente > Tiempo de espera en el router > Tiempo de espera en el mensaje Procesador > Tiempo de espera en el proxy de API
- Si es un servidor de backend de Node.js, haz lo siguiente:
- Comprueba si el código NodeJS hace llamadas a algún otro servidor de backend y si tarda mucho tiempo para devolver una respuesta. Comprueba por qué los servidores backend tardan más tiempo solucionar el problema según corresponda.
- Verifica si los procesadores de mensajes tienen un uso elevado de CPU o memoria:
- Si algún Message Processor tiene un uso elevado de CPU, genera tres
conversación
dumps cada 30 segundos con el siguiente comando:
JAVA_HOME/bin/jstack -l PID > FILENAME
- Si algún Message Processor tiene un uso elevado de memoria, genera un
montón
dump con el siguiente comando:
sudo -u apigee JAVA_HOME/bin/jmap -dump:live,format=b,file=FILENAME PID
- Usa el siguiente comando para reiniciar el Message Processor. Debería reducir la CPU
y la memoria:
/opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
- Supervisa las llamadas a la API para confirmar si el problema persiste.
- Comunícate con el equipo de asistencia de Apigee Edge y proporciona la
volcados de subprocesos, volcado de montón y registros de Message Processor
(
/opt/apigee/var/log/edge-message-processor/logs/system.log)
para ayudar investigar la causa del alto uso de CPU/memoria.
- Si algún Message Processor tiene un uso elevado de CPU, genera tres
conversación
dumps cada 30 segundos con el siguiente comando:
Verifica lo siguiente: Cómo se controla el tiempo de espera de los servidores de backend de NodeJS en Message Procesador
|
Situación 3: Se agota el tiempo de espera de la aplicación cliente antes del router, el procesador de mensajes o el servidor de backend responde
Es posible que recibas errores 504 Gateway Timeout
si se agota el tiempo de espera de la aplicación cliente antes de la
el servidor de backend. Esta situación puede ocurrir en los siguientes casos:
- El valor de tiempo de espera establecido en la aplicación cliente es menor que el valor de tiempo de espera establecido en la
Router y 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 menor o igual que 50 segundos. Esto incluye el tiempo necesario para realizar una solicitud a la API; la solicitud se que procesa Edge (enrutador, procesador de mensajes) y que la solicitud se envía al servidor de backend (si corresponde), el backend procesa la solicitud y envía la respuesta, el procesamiento perimetral respuesta y, por último, la envía de vuelta al cliente.
Si el router no responde al cliente en 50 segundos, el cliente el tiempo de espera y cierra 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ó el conexión.
Diagnóstico
- Si se agota el tiempo de espera de la aplicación cliente antes de recibir una respuesta del router,
cerrar la conexión con el router. En este caso, 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 una entrada de registro NGINX que muestra el código de estado 499
- En el ejemplo anterior, observa que el estado de
499
en NGINX y el tiempo total transcurrido es 50.001 segundos. Esto indica que se agotó el tiempo de espera del cliente después de 50.001 segundos. - En este caso, verás
Broken Pipe
excepciones en el mensaje Registros del procesador (/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>
- Una vez que se agota el tiempo de espera del router, se cierra la conexión con el Message Processor. Cuando
El procesador de mensajes completa su procesamiento y, luego, intenta escribir la respuesta en el router.
Como la conexión al router ya está cerrada, obtienes el
Broken Pipe exception
en el Message Processor. - Se espera esta excepción en las circunstancias que se explicaron anteriormente. Entonces, la causa real
el error
504 Gateway Timeout
sigue siendo que el servidor de backend tarda mucho tiempo en responder y que necesitas para abordar ese problema.
Solución
- Si es tu servidor de backend personalizado, haz lo siguiente:
- Verifica el servidor de backend para determinar por qué tarda más de 57 segundos y observa si Se puede optimizar o corregir para que responda más rápido.
- Si no es posible corregir u optimizar el servidor backend o si sabe que el
el servidor de backend demorará mucho tiempo, luego aumenta el valor del tiempo de espera en
y el procesador de mensajes.
Idea: Configure el valor de tiempo de espera en los diferentes componentes de las siguientes secciones: pedido:
Tiempo de espera en el cliente > Tiempo de espera en el router > Tiempo de espera en el mensaje Procesador > Tiempo de espera en el proxy de API
- Si es un backend de Node.js, haz lo siguiente:
- Verifica si el código NodeJS hace llamadas a algún otro servidor de backend y si eso es correcto. tardando mucho tiempo en regresar. Verifica por qué esos servidores de backend tardan más tiempo.
- Verifica si los procesadores de mensajes tienen un uso elevado de CPU o memoria:
- Si un Message Processor tiene un uso elevado de CPU, genera tres
conversación
dumps cada 30 segundos con el siguiente comando:
JAVA_HOME/bin/jstack -l PID > FILENAME
- 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
- Usa el siguiente comando para reiniciar el Message Processor. Esto debería reducir
CPU y memoria:
/opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
- Supervisa las llamadas a la API para confirmar si el problema persiste.
- Comunícate con el equipo de asistencia de Apigee Edge y proporciona la
volcados de subprocesos, volcado de montón y registros de Message Processor
(
/opt/apigee/var/log/edge-message-processor/logs/system.log)
para ayudarlos investigar la causa del alto uso de CPU/memoria.
- Si un Message Processor tiene un uso elevado de CPU, genera tres
conversación
dumps cada 30 segundos con el siguiente comando:
Aumentar el valor del tiempo de espera en Router y procesador de mensajes
Elige cuidadosamente los valores de tiempo de espera que se configurarán en el router y el procesador de mensajes según según tus requisitos. No configures valores de tiempo de espera arbitrariamente grandes. Si necesitas ayuda, comunícate con Asistencia de Apigee Edge.
Router
chown apigee:apigee /opt/apigee/customer/application/router.properties
- Crea el archivo
/opt/apigee/customer/application/router.properties
en la máquina virtual, si aún no existe. - 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 de 120 segundos, configúralo como sigue:
conf_load_balancing_load.balancing.driver.proxy.read.timeout=120
- Asegúrate de que este archivo sea propiedad de Apigee:
- Reinicia el router de la siguiente forma:
/opt/apigee/apigee-service/bin/apigee-service edge-router restart
- Si tienes más de un router, repite los pasos anteriores en todos ellos.
Message Processor
- Crear archivo
/opt/apigee/customer/application/message-processor.properties
en en la máquina del procesador de mensajes, si aún no existe. - 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 de 120 segundos, configúralo como sigue:
conf_http_HTTPTransport.io.timeout.millis=120000
- Asegúrate de que este archivo sea propiedad de Apigee:
chown apigee:apigee /opt/apigee/customer/application/message-processor.properties
- Reinicia el procesador de mensajes:
/opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
- Si tienes más de un Message Processor, repite los pasos anteriores en todos los mensajes Procesadores.
Idea: Configure 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 Message Processor > Tiempo de espera en el proxy de API |
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, obtendrás un mensaje
504 Gateway Timeout
error.
Diagnóstico
- Hacer un seguimiento de la API afectada en la IU de Edge.
- Espera a que se produzca el error o, si recibes la llamada a la API, y realiza algunas llamadas a la API.
y reproduce el error
504 Gateway Timeout
. - Ten en cuenta que, en este caso, es posible que veas una respuesta exitosa en Trace.
- 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 cliente (el que tenga el período de tiempo de espera más bajo). Sin embargo, Message Processor continúa procesando la solicitud y puede completar con éxito.
- Además, el valor
HTTPTransport.io.timeout.millis
establecido en el Message Processor se activa solo si este se comunica con un servidor HTTP/HTTPS servidor de backend. En otras palabras, este tiempo de espera no se activará cuando alguna política que la política ServicePrompt) en el proxy de API está tardando mucho tiempo.
- Una vez ocurrido el error, examina la solicitud específica que tenga la tiempo transcurrido
- Comprueba el tiempo transcurrido en cada fase y toma nota de la fase en la que se alcanza la mayor cantidad de tiempo. de los recursos que gastas.
- Si observas el tiempo transcurrido más largo en cualquiera de las políticas que no sean la del Servicio La política de texto destacado indica que Edge está tardando mucho tiempo en procesar para cada solicitud.
- Este es un ejemplo de seguimiento de la IU en el que se muestra un tiempo transcurrido muy alto en la política de JavaScript:
- En el ejemplo anterior, observas que la política de JavaScript tarda una cantidad anormalmente larga de 245 segundos aproximadamente.
Solución
- Verifica si la política que tardó mucho tiempo en responder y si hay algún código personalizado que pueden tardar mucho tiempo en procesarse. Si existe ese código, ve si puedes corregir y optimizar el código identificado.
- Si no hay ningún código personalizado que pueda causar un tiempo de procesamiento alto, comprueba si el mensaje
Los procesadores están experimentando un uso elevado de CPU o memoria:
- Si algún Message Processor tiene un uso elevado de CPU, genera tres
conversación
dumps cada 30 segundos con el siguiente comando:
JAVA_HOME/bin/jstack -l PID > FILENAME
- 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
- Usa el siguiente comando para reiniciar el Message Processor. Esto debería reducir la capacidad
y Memory.
/opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
- Supervisa las llamadas a la API y confirma si el problema persiste.
- Comunícate con el equipo de asistencia de Apigee Edge y proporciona la conversación.
Registros de volcados, volcado de montón y Message Processor
(
/opt/apigee/var/log/edge-message-processor/logs/system.log)
para ayudarlos investigar la causa del alto uso de CPU/memoria.
- Si algún Message Processor tiene un uso elevado de CPU, genera tres
conversación
dumps cada 30 segundos con el siguiente comando:
Diagnostica problemas con la supervisión de API
La supervisión de API te permite aislar rápidamente las áreas problemáticas para diagnosticar errores, rendimiento y latencia, así como su origen. como apps para desarrolladores, proxies de API, destinos de backend o la plataforma de API.
Lee una situación de ejemplo que demuestra cómo solucionar problemas 5xx con tus APIs con la supervisión de API. 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 en particular.