O Google usa tecnologia de IA na tradução de conteúdos para seu idioma de preferência. As traduções com IA podem ter erros.

504 Gateway Timeout

Você está lendo a documentação do Apigee Edge.
Acesse a documentação da Apigee X. info

Sintoma

O aplicativo cliente recebe um código de status HTTP 504 com a mensagem Gateway Timeout como resposta para as chamadas de API.

O código de status HTTP 504 Gateway Timeout indica que o cliente não recebeu uma resposta do gateway do Edge ou do servidor de back-end durante a execução de uma API.

Mensagens de erro

O aplicativo cliente recebe o seguinte código de resposta:

HTTP/1.1 504 Gateway Timeout

Em alguns casos, a seguinte mensagem de erro também pode aparecer:

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

O que causa tempos limite de gateway?

O caminho típico de uma solicitação de API pela plataforma Edge é Cliente -> Router -> processador de mensagens -> Backend Server, conforme mostrado na figura abaixo:

O aplicativo cliente, os roteadores e os processadores de mensagens na plataforma Edge são configurados com valores de tempo limite adequados. A plataforma Edge espera que uma resposta seja enviada dentro de um determinado período de tempo para cada solicitação de API com base nos valores de tempo limite. Se você não receber a resposta dentro do período especificado, 504 Gateway Timeout Error será retornado.

A tabela a seguir oferece mais detalhes sobre quando os tempos limite podem ocorrer no Edge:

Ocorrência de tempo limite	Detalhes
O tempo limite ocorre no processador de mensagens	O servidor de back-end não responde ao processador de mensagens dentro de um período de tempo limite especificado no processador de mensagens. O processador de mensagens atinge o tempo limite e envia o status da resposta como `504 Gateway Timeout` para o roteador.
O tempo limite ocorre no roteador	O processador de mensagens não responde ao roteador dentro do período de tempo limite especificado no roteador. O roteador atinge o tempo limite e envia o status da resposta como `504 Gateway Timeout` para o aplicativo cliente.
O tempo limite ocorre no aplicativo cliente	O roteador não responde ao aplicativo cliente dentro do período de tempo limite especificado no roteador. O aplicativo cliente atinge o tempo limite e encerra o status da resposta como `504 Gateway Timeout` para o usuário final.

Causas possíveis

No Edge, as causas típicas do erro 504 Gateway Timeout são:

Causa	Detalhes	Etapas concedidas para
Servidor de back-end lento	O servidor de back-end que está processando a solicitação de API está muito lento devido a uma carga alta ou performance ruim.	Usuários da nuvem pública e privada
Processamento lento de solicitações de API pelo Edge	O Edge leva muito tempo para processar a solicitação de API devido à carga alta ou ao desempenho ruim.

Servidor de back-end lento

Se o servidor de back-end for muito lento ou demorar muito para processar a solicitação de API, você vai receber um erro 504 Gateway Timeout. Conforme explicado na seção acima, o tempo limite pode ocorrer em um dos seguintes cenários:

O processador de mensagens atinge o tempo limite antes que o servidor de back-end responda.
O roteador atinge o tempo limite antes que o processador de mensagens/servidor de back-end responda.
O tempo limite do aplicativo cliente expira antes que o roteador/processador de mensagens/servidor de back-end responda.

As seções a seguir descrevem como diagnosticar e resolver o problema em cada um desses cenários.

Cenário 1 O processador de mensagens atinge o tempo limite antes que o servidor de back-end responda

Diagnóstico

Use os procedimentos a seguir para diagnosticar se o erro 504 Gateway Timeout ocorreu devido à lentidão do servidor de back-end.

Procedimento nº 1: usar o Trace

Se o problema ainda estiver ativo (os erros 504 ainda estão acontecendo), siga as etapas abaixo:

Rastreie a API afetada na interface do Edge. Aguarde o erro ocorrer ou, se você tiver a chamada de API, faça algumas chamadas e reproduza o erro 504 Gateway Timeout.
Depois que o erro ocorrer, examine a solicitação específica que mostra o código de resposta como 504.
Verifique o tempo decorrido em cada fase e anote aquela em que mais tempo é gasto.
Se você observar o erro com o maior tempo decorrido imediatamente após uma das seguintes fases, isso indica que o servidor de back-end está lento ou demorando muito para processar a solicitação:
- Solicitação enviada ao servidor de destino
- Política ServiceCallout

Confira a seguir um exemplo de rastreamento mostrando que o servidor de back-end não respondeu mesmo após 55 segundos, resultando em um erro 504 Gateway Timeout:

No rastreamento acima, o processador de mensagens atinge o tempo limite após 55.002 ms porque o servidor de back-end não responde.

Procedimento 2: usar registros do processador de mensagens

Verifique o registro do processador de mensagens (/opt/apigee/var/log/edge-message-processor/logs/system.log)

Se você encontrar erros Gateway Timeout e onTimeoutRead para a solicitação específica de proxy de API no horário específico, isso indica que o processador de mensagens atingiu o tempo limite.

Exemplo de um registro do processador de mensagens mostrando o erro de tempo limite do gateway

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

No registro do processador de mensagens acima, você percebe que o servidor de back-end indicado com o endereço IP XX.XX.XX.XX não respondeu mesmo após 55 segundos (lastIO=55000ms). Como resultado, o processador de mensagens atingiu o tempo limite e enviou o erro 504 Gateway Timeout.

Confira: Como o tempo limite é controlado no processador de mensagens?

Como o tempo limite é controlado no processador de mensagens. Os processadores de mensagens geralmente são definidos com um valor de tempo limite padrão de 55 segundos usando a propriedade HTTPTransport.io.timeout.millis. Esse valor de tempo limite é aplicável a todos os proxies de API que pertencem a uma organização atendida por esse processador de mensagens.
- Se o servidor de back-end não responder em 55 segundos, o processador de mensagens vai atingir o tempo limite e enviar um erro 504 Gateway Timeout ao cliente.
O valor de tempo limite especificado no processador de mensagens pode ser substituído pela propriedade io.timeout.millis especificada no proxy de API. Esse valor de tempo limite é aplicável a um proxy de API específico em que a propriedade mencionada acima é especificada. Por exemplo, se o io.timeout.millis estiver definido como 10 segundos no proxy de API, o valor de tempo limite de 10 segundos será usado para esse proxy de API específico.
- Se o servidor de back-end não responder em 10 segundos para o proxy de API específico, o processador de mensagens vai atingir o tempo limite e enviar um erro 504 Gateway Timeout ao cliente.

Resolução

Verifique por que o servidor de back-end está demorando mais de 55 segundos e se ele pode ser corrigido/otimizado para responder mais rápido.
Se não for possível corrigir/otimizar o servidor de back-end ou se for conhecido que ele leva mais tempo do que o tempo limite configurado, aumente o valor do tempo limite no roteador e no processador de mensagens para um valor adequado.

Cenário 2: o roteador atinge o tempo limite antes que o processador de mensagens/servidor de back-end responda

Você pode receber erros 504 Gateway Timeout se o roteador atingir o tempo limite antes que o processador de mensagens/servidor de back-end responda. Isso pode acontecer em uma das seguintes circunstâncias:

O valor de tempo limite definido no roteador é menor do que o valor definido no processador de mensagens. Por exemplo, digamos que o tempo limite no roteador seja de 50 segundos, enquanto o processador de mensagens seja de 55 segundos.

Tempo limite no roteador	Tempo limite no processador de mensagens
50 segundos	55 segundos

O valor de tempo limite no processador de mensagens é substituído por um valor maior usando a propriedade io.timeout.millis definida na configuração do endpoint de destino do proxy de API:

Por exemplo, se os seguintes valores de tempo limite estiverem definidos:

Tempo limite no roteador	Tempo limite no processador de mensagens	Tempo limite no proxy de API
57 segundos	55 segundos	120 segundos

Mas o io.timeout.millis está definido como 120 segundos no proxy de API:

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

Assim, o processador de mensagens não vai atingir o tempo limite após 55 segundos, mesmo que o valor de tempo limite dele (55 segundos) seja menor que o valor de tempo limite no roteador (57 segundos). Isso ocorre porque o valor de tempo limite de 55 segundos no processador de mensagens é substituído pelo valor de 120 segundos definido no proxy de API. Assim, o valor de tempo limite do processador de mensagens para esse proxy de API específico será de 120 segundos.

Como o roteador tem um valor de tempo limite menor (57 segundos) em comparação com os 120 segundos definidos no proxy de API, o roteador vai atingir o tempo limite se o servidor de back-end não responder após 57 segundos.

Diagnóstico

Verifique o registro de acesso do NGINX (/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log)
Se o roteador atingir o tempo limite antes do processador de mensagens, o status 504 vai aparecer nos registros de acesso do NGINX para a solicitação de API específica, e o message id do processador de mensagens será definido como -. Isso acontece porque o roteador não recebeu nenhuma resposta do processador de mensagens dentro do tempo limite definido nele.

Exemplo de entrada de registro do NGINX mostrando 504 devido ao tempo limite do roteador
No exemplo acima, observe o status de 504 no NGINX.O ID da mensagem do Message Processor é -, e o tempo total decorrido é de 57,001 segundos. Isso acontece porque o roteador atingiu o tempo limite após 57,001 segundos e não recebemos nenhuma resposta do processador de mensagens.

Nesse caso, você vai encontrar exceções Broken Pipe nos registros do processador de mensagens (/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>

Esse erro é exibido porque, quando o tempo limite do roteador expira, ele fecha a conexão com o processador de mensagens. Quando o processador de mensagens conclui o processamento, ele tenta gravar a resposta no roteador. Como a conexão com o roteador já está fechada, você recebe o Broken Pipe exception no processador de mensagens.

Essa exceção deve ser observada nas circunstâncias explicadas acima. Portanto, a causa real do erro 504 Gateway Timeout ainda é o servidor de back-end demorando mais tempo para responder, e você precisa resolver esse problema.

Resolução

Se for um servidor de back-end personalizado, então

Verifique por que o servidor de back-end está demorando muito para responder e se ele pode ser corrigido/otimizado para responder mais rápido.

Se não for possível corrigir/otimizar o servidor de back-end ou se for um fato conhecido que o servidor de back-end leva muito tempo, aumente o valor de tempo limite no roteador e no processador de mensagens.

Ideia: defina o valor de tempo limite nos diferentes componentes na seguinte ordem:

Tempo limite no cliente > Tempo limite no roteador > Tempo limite no processador de mensagens > Tempo limite no proxy de API

Se for um servidor de back-end do NodeJS, faça o seguinte:
1. Verifique se o código NodeJS faz chamadas para outros servidores de back-end e se está demorando muito para retornar uma resposta. Verifique por que os servidores de back-end estão demorando mais e corrija o problema conforme necessário.
2. Verifique se os processadores de mensagens estão apresentando alto uso de CPU ou uso da memória:
  1. Se algum processador de mensagens estiver apresentando alto uso da CPU, gere três dumps de threads a cada 30 segundos usando o seguinte comando:
```
JAVA_HOME/bin/jstack -l PID > FILENAME
```
  2. Se algum processador de mensagens estiver com uso da memória alto, gere um despejo de heap usando o seguinte comando:
```
sudo -u apigee JAVA_HOME/bin/jmap -dump:live,format=b,file=FILENAME PID
```
  3. Reinicie o processador de mensagens usando o comando abaixo. Isso deve reduzir o uso da CPU e da memória:
```
/opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
```
  4. Monitore as chamadas de API para confirmar se o problema ainda existe.
  5. Entre em contato com o suporte do Apigee Edge e forneça os dumps de encadeamento, o heap dump e os registros do processador de mensagens (/opt/apigee/var/log/edge-message-processor/logs/system.log)para ajudar a investigar a causa do alto uso da memória/CPU.

Confira isto: como o tempo limite é controlado para servidores de back-end NodeJS no Message Processor

O servidor de back-end do NodeJS é executado no processo JVM do processador de mensagens. O valor de tempo limite para servidores de back-end do NodeJS é controlado pela propriedade http.request.timeout.seconds no arquivo nodejs.properties. Essa propriedade é definida como 0 por padrão. Ou seja, o tempo limite é desativado por padrão para todos os proxies de API que pertencem a uma organização atendida por esse processador de mensagens. Assim, mesmo que um servidor de back-end do NodeJS demore muito, o processador de mensagens não vai atingir o tempo limite.
No entanto, se o servidor de back-end do NodeJS demorar muito e o tempo gasto pela solicitação da API for > 57 segundos, o roteador vai atingir o tempo limite e enviar um erro 504 Gateway Timeout ao cliente.

Cenário 3: o aplicativo cliente atinge o tempo limite antes que o roteador/processador de mensagens/servidor de back-end responda

Você poderá receber erros 504 Gateway Timeout se o tempo limite do aplicativo cliente expirar antes da resposta do servidor de back-end. Essa situação pode acontecer se:

O valor de tempo limite definido no aplicativo cliente é menor do que o valor definido no roteador e no processador de mensagens:

Por exemplo, se os seguintes valores de tempo limite estiverem definidos:

Tempo limite no cliente	Tempo limite no roteador	Tempo limite no processador de mensagens
50 segundos	57 segundos	55 segundos

Nesse caso, o tempo total disponível para receber uma resposta de uma solicitação de API pelo Edge é <= 50 segundos. Isso inclui o tempo gasto para fazer uma solicitação de API, o processamento da solicitação pelo Edge (roteador, processador de mensagens), o envio da solicitação ao servidor de back-end (se aplicável), o processamento da solicitação e o envio da resposta pelo back-end, o processamento da resposta pelo Edge e, por fim, o envio dela de volta ao cliente.

Se o roteador não responder ao cliente em 50 segundos, o cliente vai atingir o tempo limite e fechar a conexão com o roteador. O cliente vai receber o código de resposta 504.

Isso fará com que o NGINX defina um código de status 499, indicando que o cliente fechou a conexão.

Diagnóstico

Se o aplicativo cliente atingir o tempo limite antes de receber uma resposta do roteador, ele vai fechar a conexão com o roteador. Nessa situação, você vai encontrar um código de status 499 nos registros de acesso do NGINX para a solicitação de API específica.
Exemplo de entrada de registro do NGINX mostrando o código de status 499
No exemplo acima, observe que o status de 499 no NGINX e o tempo total decorrido são de 50,001 segundos. Isso indica que o cliente atingiu o tempo limite após 50.001 segundos.

Nesse caso, você vai encontrar Broken Pipe Exceptions nos registros do 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>

Depois que o roteador atinge o tempo limite, ele fecha a conexão com o processador de mensagens. Quando o processador de mensagens conclui o processamento, ele tenta gravar a resposta no roteador. Como a conexão com o roteador já está fechada, você recebe o Broken Pipe exception no processador de mensagens.
Essa exceção é esperada nas circunstâncias explicadas acima. Portanto, a causa real do erro 504 Gateway Timeout ainda é que o servidor de back-end leva muito tempo para responder, e você precisa resolver esse problema.

Resolução

Se for seu servidor de back-end personalizado:

Verifique o servidor de back-end para determinar por que ele está demorando mais de 57 segundos e se pode ser corrigido/otimizado para responder mais rápido.

Se não for possível corrigir/otimizar o servidor de back-end ou se você souber que ele vai levar muito tempo, aumente o valor de tempo limite no roteador e no processador de mensagens.

Ideia: defina o valor de tempo limite nos diferentes componentes na seguinte ordem:

Tempo limite no cliente > Tempo limite no roteador > Tempo limite no processador de mensagens > Tempo limite no proxy de API

Se for um back-end NodeJS, faça o seguinte:
1. Verifique se o código NodeJS faz chamadas para outros servidores de back-end e se isso está demorando muito para retornar. Verifique por que esses servidores de back-end estão demorando mais.
2. Verifique se os processadores de mensagens estão apresentando alto uso de CPU ou memória:
  1. Se um processador de mensagens estiver com uso alto da CPU, gere três dumps de threads a cada 30 segundos usando o seguinte comando:
```
JAVA_HOME/bin/jstack -l PID > FILENAME
```
  2. Se um processador de mensagens estiver com uso alto de memória, gere um despejo de heap usando o seguinte comando:
```
sudo -u apigee JAVA_HOME/bin/jmap -dump:live,format=b,file=FILENAME PID
```
  3. Reinicie o processador de mensagens usando o comando abaixo. Isso deve reduzir o uso da CPU e da memória:
```
/opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
```
  4. Monitore as chamadas de API para confirmar se o problema ainda existe.
  5. Entre em contato com o suporte do Apigee Edge e forneça os dumps de encadeamento, o dump de heap e os registros do processador de mensagens (/opt/apigee/var/log/edge-message-processor/logs/system.log)para ajudar a investigar a causa do alto uso de CPU/memória.

Aumente o valor de tempo limite no roteador e no processador de mensagens.

Escolha com cuidado os valores de tempo limite a serem definidos no roteador e no processador de mensagens, dependendo dos seus requisitos. Não defina valores de tempo limite arbitrariamente grandes. Se precisar de ajuda, entre em contato com o suporte do Apigee Edge.

Roteador

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

Crie o arquivo /opt/apigee/customer/application/router.properties na máquina do roteador, se ele ainda não existir.

Adicione a seguinte linha ao arquivo:

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

Por exemplo, se você quiser definir o valor de tempo limite de 120 segundos, faça o seguinte:

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

Verifique se o arquivo pertence ao apigee:

Reinicie o roteador:

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

Se você tiver mais de um roteador, repita as etapas acima em todos eles.

processador de mensagens

Crie o arquivo /opt/apigee/customer/application/message-processor.properties na máquina do processador de mensagens, se ele ainda não existir.
Adicione a seguinte linha ao arquivo:
```
conf_http_HTTPTransport.io.timeout.millis=TIME_IN_MILLISECONDS
```
Por exemplo, se você quiser definir o valor de tempo limite de 120 segundos, faça o seguinte:
```
conf_http_HTTPTransport.io.timeout.millis=120000
```

Verifique se o arquivo pertence ao apigee:

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

Reinicie o processador de mensagens:

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

Se você tiver mais de um processador de mensagens, repita as etapas acima em todos eles.

Ideia: defina o valor de tempo limite nos diferentes componentes na seguinte ordem:

Tempo limite no cliente > Tempo limite no roteador > Tempo limite no processador de mensagens > Tempo limite no proxy de API

Processamento lento de solicitações de API pelo Edge

Se o Edge estiver muito lento e/ou demorando muito para processar a solicitação de API, você vai receber um erro 504 Gateway Timeout.

Diagnóstico

Rastreie a API afetada na interface do Edge.
Aguarde o erro ocorrer ou, se tiver a chamada de API, faça algumas chamadas e reproduza o erro 504 Gateway Timeout.
Observação: nesse caso, talvez você veja uma resposta bem-sucedida no trace.
1. O roteador/cliente atinge o tempo limite porque o processador de mensagens não responde dentro do período especificado no roteador/cliente (o que tiver o menor período de tempo limite). No entanto, o processador de mensagens continua processando a solicitação e pode concluir com sucesso.
2. Além disso, o valor HTTPTransport.io.timeout.millis definido no processador de mensagens só é acionado se ele se comunicar com um servidor de back-end HTTP/HTTPS. Em outras palavras, esse tempo limite não será acionado quando qualquer política (que não seja a política ServiceCallout) no proxy de API estiver demorando muito.
Depois que o erro ocorrer, examine a solicitação específica com o tempo decorrido mais longo.
Verifique o tempo decorrido em cada fase e anote aquela em que mais tempo é gasto.
Se você observar o maior tempo decorrido em qualquer uma das políticas que não seja a de chamada de serviço, isso indica que o Edge está demorando muito para processar a solicitação.
Confira um exemplo de rastreamento da interface que mostra um tempo decorrido muito alto na política do JavaScript:
No exemplo acima, você percebe que a política do JavaScript leva um tempo anormalmente longo de aproximadamente 245 segundos.

Resolução

Verifique se a política demorou muito para responder e se há algum código personalizado que pode levar muito tempo para ser processado. Se houver algum código assim, tente corrigir/otimizar o código identificado.
Se não houver código personalizado que possa causar um tempo de processamento alto, verifique se os processadores de mensagens estão apresentando alto uso de CPU ou memória:
1. Se algum processador de mensagens estiver com alto uso da CPU, gere três dumps de threads a cada 30 segundos usando o seguinte comando:
```
JAVA_HOME/bin/jstack -l PID > FILENAME
```
2. Se algum processador de mensagens estiver com uso alto de memória, gere um heap dump usando o seguinte comando:
```
sudo -u apigee JAVA_HOME/bin/jmap -dump:live,format=b,file=FILENAME PID
```
3. Reinicie o processador de mensagens usando o comando abaixo. Isso deve reduzir o uso da CPU e da memória.
```
/opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
```
4. Monitore as chamadas de API e confirme se o problema ainda existe.
5. Entre em contato com o suporte do Apigee Edge e forneça os despejos de threads, o heap dump e os registros do processador de mensagens (/opt/apigee/var/log/edge-message-processor/logs/system.log)para ajudar a investigar a causa do alto uso da memória/CPU.

Diagnosticar problemas usando a API Monitoring

Com a API Monitoring, é possível isolar as áreas problemáticas rapidamente para diagnosticar erros, problemas de desempenho e latência e a origem deles, como apps de desenvolvedor, proxies de API, destinos de back-end ou a plataforma de API.

Confira um cenário de exemplo que demonstra como resolver problemas 5xx com suas APIs usando o API Monitoring. Por exemplo, você pode configurar um alerta para receber uma notificação quando o número de códigos de status 504 exceder um determinado limite.