504 Gateway Timeout

Você está vendo a documentação do Apigee Edge.
Veja a documentação da Apigee X.

Sintoma

O aplicativo cliente recebe um código de status HTTP de 504 com a mensagem Gateway Timeout como uma 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 de borda 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 ser observada:

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

O que causa o tempo limite do gateway?

O caminho típico para uma solicitação de API por meio da plataforma do Edge é Client -> Router -> Message Processor -> Backend Server, como mostrado na figura abaixo:

O aplicativo cliente, os roteadores e os processadores de mensagens na plataforma Edge são configurados com os valores de tempo limite adequados. A plataforma de borda 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 fornece mais detalhes sobre quando os tempos limite podem ocorrer no Edge:

Ocorrência de tempo limite Detalhes
O tempo limite do processador de mensagens é atingido
  • 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 expira e envia o status de resposta como 504 Gateway Timeout para o roteador.
O tempo limite é atingido no roteador
  • O processador de mensagens não responde ao roteador dentro do tempo limite especificado no roteador.
  • O roteador expira e envia o status de resposta como 504 Gateway Timeout para o aplicativo cliente.
O tempo limite é atingido no aplicativo cliente
  • O roteador não responde ao aplicativo cliente dentro do tempo limite especificado no roteador.
  • O aplicativo cliente expira e termina 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 indicadas para
Servidor de back-end lento O servidor de back-end que está processando a solicitação da API é muito lento devido à carga alta ou ao desempenho insatisfatório. Usuários de nuvem pública e privada
Processamento lento de solicitações de API pelo Edge O Edge leva muito tempo para processar a solicitação da API devido à alta carga ou ao baixo desempenho.

Servidor de back-end lento

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

  1. O processador de mensagens expira antes que o servidor de back-end responda.
  2. O roteador expira antes que o processador de mensagens/servidor de back-end responda.
  3. O aplicativo cliente expira antes de o roteador/processador de mensagens/servidor de back-end responder.

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

Cenário no 1 O processador de mensagens expira antes do servidor de back-end responder

Diagnóstico

Use os procedimentos a seguir para diagnosticar se o erro 504 Gateway Timeout ocorreu devido ao servidor de back-end lento.

Procedimento 1: como usar o Trace

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

  1. Rastreie a API afetada na IU do Edge. Aguarde a ocorrência do erro ou, se você tiver a chamada de API, faça algumas chamadas e reproduza o erro 504 Gateway Timeout.
  2. Depois que o erro ocorrer, examine a solicitação específica que mostra o código de resposta como 504.
  3. Verifique o tempo decorrido em cada fase e anote a fase em que a maior parte do tempo é passada.
  4. Se o erro com o maior tempo decorrido imediatamente após uma das fases a seguir indicar que o servidor de back-end está lento ou está demorando muito para processar a solicitação:
    • Solicitação enviada ao servidor de destino
    • Política ServiceCallout

Veja a seguir um trace de amostra que mostra que o servidor de back-end não respondeu mesmo após 55 segundos, resultando em um erro 504 Gateway Timeout:

No trace acima, o Processador de mensagens expira após 55.002 ms, porque o servidor de back-end não responde.

Procedimento 2 para usar os registros do processador de mensagens

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

  2. Se você encontrar erros Gateway Timeout e onTimeoutRead para a solicitação de proxy de API específica no momento, isso indicará que o processador de mensagens expirou.

    Exemplo de 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.

    Verifique isto: como o tempo limite é controlado no processador de mensagens?

    • Como o tempo limite é controlado no processador de mensagens. Os processadores de mensagens normalmente são definidos com um valor de tempo limite padrão de 55 segundos por meio da 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 este processador de mensagens.
      • Se o servidor de back-end não responder em até 55 segundos, o Processador de mensagens atingirá o tempo limite e enviará o erro 504 Gateway Timeout para o cliente.
    • O valor de tempo limite especificado no processador de mensagens pode ser modificado 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 io.timeout.millis for 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 até 10 segundos para o proxy de API específico, o processador de mensagens atingirá o tempo limite e enviará o erro 504 Gateway Timeout para o cliente.

Resolução

  1. Verifique por que o servidor de back-end está levando mais de 55 segundos e veja se ele pode ser corrigido/otimizado para responder mais rapidamente.
  2. 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 no 2: o roteador expira antes que o processador de mensagens/servidor de back-end responda

Você poderá receber erros 504 Gateway Timeout se o roteador expirar antes do processador de mensagens/servidor de back-end responder. Isso pode acontecer em uma das seguintes circunstâncias:

  • O valor de tempo limite definido no roteador é menor do que o definido no processador de mensagens. Por exemplo, digamos que o tempo limite do roteador seja de 50 segundos, enquanto o do processador de mensagens seja de 55 segundos.
    Tempo limite do 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 de tempo limite 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 do roteador Tempo limite no processador de mensagens Tempo limite dentro do 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>

    O processador de mensagens não vai atingir o tempo limite depois de 55 segundos, mesmo que o valor de tempo limite (55 segundos) seja menor que o 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. Portanto, 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 120 segundos definidos no proxy de API, o roteador atingirá o tempo limite se o servidor de back-end não responder após 57 segundos.

Diagnóstico

  1. Verifique o registro de acesso NGINX (/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log)

  2. Se o roteador expirar antes do processador de mensagens, você verá o status de 504 nos registros de acesso NGINX para a solicitação de API específica e o message id do processador de mensagens será definido como -. Isso ocorre porque o roteador não recebeu nenhuma resposta do processador de mensagens dentro do tempo limite definido no roteador.

    Exemplo de entrada de registro do NGINX mostrando o erro 504 devido ao tempo limite do roteador

  3. No exemplo acima, observe o status de 504 no NGINX, o código de mensagem do processador de mensagens é - e o tempo total decorrido é de 57.001 segundos. Isso ocorre porque o roteador expirou após 57.001 segundos e não recebemos nenhuma resposta do processador de mensagens.
  4. Nesse caso, você verá Broken Pipe exceções 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 roteador expirar, ele encerrará 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 deverá ser observada nas circunstâncias explicadas acima. Portanto, a causa real do erro 504 Gateway Timeout ainda é o servidor de back-end levando mais tempo para responder, e você precisa resolver esse problema.

Resolução

  1. Se for um servidor de back-end personalizado, então:
    1. Verifique por que o servidor de back-end está demorando muito para responder e veja se ele pode ser corrigido/otimizado para responder mais rapidamente.
    2. Se não for possível corrigir/otimizar o servidor de back-end ou se for conhecido que o servidor de back-end leva muito tempo, aumente o valor do 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
  2. Se for um servidor de back-end 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 apropriado.
    2. Verifique se os processadores de mensagens estão usando mais recursos de CPU ou memória:
      1. Se algum processador de mensagens estiver com alto uso da CPU, gere três despejos de linhas de execução a cada 30 segundos usando o seguinte comando: 
        JAVA_HOME/bin/jstack -l PID > FILENAME
      2. Se algum processador de mensagens estiver usando muita memória, gere um despejo de pilha 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. Ele reduz a CPU e a 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 da Apigee Edge e forneça os despejos de thread, despejo de heap e 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.

Verifique isto: como o tempo limite é controlado para servidores de back-end do NodeJS no Message Processador

  • O servidor de back-end do NodeJS é executado no processo JVM do processador de mensagens. O valor do tempo limite para servidores de back-end do NodeJS é controlado por meio da 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 este processador de mensagens. Portanto, mesmo que um servidor de back-end do NodeJS leve muito tempo, o processador de mensagens não vai atingir o tempo limite.
  • No entanto, se o servidor de back-end do NodeJS demorar e o tempo da solicitação de API for maior que 57 segundos, o roteador atingirá o tempo limite e enviará o erro 504 Gateway Timeout para o cliente.

Cenário 3: o aplicativo cliente expira antes do roteador/processador de mensagens/servidor de back-end responder

Você poderá receber erros 504 Gateway Timeout se o aplicativo cliente expirar antes do servidor de back-end responder. Isso pode acontecer se:

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

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

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

    Nesse caso, o tempo total disponível para receber uma resposta para uma solicitação de API por meio do Edge é de <= 50 segundos. Isso inclui o tempo necessário 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 pelo back-end e o envio da resposta, o processamento da resposta pelo Edge e o envio ao cliente.

    Se o roteador não responder ao cliente em 50 segundos, o tempo limite será encerrado e a conexão com o roteador será encerrada. O cliente receberá o código de resposta de 504.

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

Diagnóstico

  1. Se o aplicativo cliente expirar antes de receber uma resposta do roteador, ele encerrará a conexão com o roteador. Nessa situação, você verá um código de status de 499 nos registros de acesso NGINX para a solicitação de API específica.

    Exemplo de entrada de registro NGINX mostrando o código de status 499

  2. No exemplo acima, observe que o status de 499 no NGINX e o tempo total decorrido é de 50.001 segundos. Isso indica que o cliente expirou após 50.001 segundos.
  3. Nesse caso, você verá Broken Pipe exceções 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-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. Depois que o roteador atingir o tempo limite, ele encerrará 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ê vai conseguir o Broken Pipe exception no processador de mensagens.
  5. Essa exceção é esperada sob as 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

  1. Se for o servidor de back-end personalizado:
    1. Verifique o servidor de back-end para determinar por que ele está levando mais de 57 segundos e veja se ele pode ser corrigido/otimizado para responder mais rapidamente.
    2. Se não for possível corrigir/otimizar o servidor de back-end ou se você souber que ele levará muito tempo, aumente o valor do 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
  2. Se for um back-end NodeJS, faça o seguinte:
    1. Verifique se o código do NodeJS faz chamadas para qualquer outro servidor de back-end e se ele 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 usando muita CPU ou memória:
      1. Se um processador de mensagens estiver com alto uso da CPU, gere três despejos de linhas de execução a cada 30 segundos usando o seguinte comando: 
        JAVA_HOME/bin/jstack -l PID > FILENAME
      2. Se um processador de mensagens estiver com alto uso de memória, gere um despejo de pilha 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 reduz a CPU e a 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 da Apigee Edge e forneça os despejos de thread, despejo de heap e registros do processador de mensagens (/opt/apigee/var/log/edge-message-processor/logs/system.log) para ajudá-los a investigar a causa do alto uso de CPU/memória.

Aumentar o valor do tempo limite no roteador e no processador de mensagens

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

Roteador

chown apigee:apigee /opt/apigee/customer/application/router.properties
  1. Crie o arquivo /opt/apigee/customer/application/router.properties na máquina do roteador, se ainda não houver um.
  2. Adicione a seguinte linha a este 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
  3. Verifique se esse arquivo pertence à Apigee:
  4. Reinicie o roteador: 
    /opt/apigee/apigee-service/bin/apigee-service edge-router restart
  5. Se você tiver mais de um roteador, repita as etapas acima em todos eles.

processador de mensagens

  1. Crie o arquivo /opt/apigee/customer/application/message-processor.properties na máquina do Processador de mensagens, se ele ainda não existir.
  2. Adicione a seguinte linha a este 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
  3. Verifique se esse arquivo é de propriedade da Apigee: 
    chown apigee:apigee /opt/apigee/customer/application/message-processor.properties
  4. Reinicie o processador de mensagens: 
    /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
  5. Se você tiver mais de um processador de mensagens, repita as etapas acima em todos os processadores 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

Processamento lento de solicitações de API pelo Edge

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

Diagnóstico

  1. Rastreie a API afetada na IU do Edge.
  2. Aguarde a ocorrência do erro ou, se você tiver a chamada de API, faça algumas chamadas de API e reproduza o erro 504 Gateway Timeout.
  3. Nesse caso, você poderá ver uma resposta bem-sucedida no Trace.
    1. O roteador/cliente expira porque o processador de mensagens não responde dentro do tempo limite especificado no roteador/cliente (o que tiver o menor tempo limite). No entanto, o processador de mensagens continuará processando a solicitação e poderá ser concluído.
    2. Além disso, o valor de HTTPTransport.io.timeout.millis definido no Processador de mensagens só será 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 (diferente da política ServiceCallout) no proxy de API estiver demorando muito.
  4. Depois que o erro ocorrer, examine a solicitação específica que tem o tempo mais longo decorrido.
  5. Verifique o tempo decorrido em cada fase e anote a fase em que a maior parte do tempo é passada.
  6. Se você observar o tempo mais longo decorrido em qualquer uma das políticas além da política de frase de destaque de serviço, isso indicará que o Edge está demorando muito para processar a solicitação.
  7. Veja um exemplo de trace de IU que mostra o tempo decorrido muito alto na política de JavaScript:

  8. No exemplo acima, você nota que a política JavaScript leva um tempo anormalmente longo, de aproximadamente 245 segundos.

Resolução

  1. Verifique se a política levou muito tempo para responder e se há algum código personalizado que pode exigir muito tempo de processamento. Se houver, verifique se é possível corrigir/otimizar o código identificado.
  2. Se não houver um código personalizado que possa causar um alto tempo de processamento, verifique se os processadores de mensagens estão usando muita CPU ou memória:
    1. Se algum processador de mensagens estiver com alto uso da CPU, gere três despejos de linhas de execução a cada 30 segundos usando o seguinte comando: 
      JAVA_HOME/bin/jstack -l PID > FILENAME
    2. Se algum processador de mensagens estiver usando muita 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 reduz a CPU e a 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 da Apigee Edge e forneça os registros de despejo, heap dump e Message Processador (/opt/apigee/var/log/edge-message-processor/logs/system.log)) para ajudá-los a investigar a causa do alto uso de CPU/memória.

Diagnosticar problemas usando o monitoramento de APIs

O monitoramento de APIs permite isolar rapidamente as áreas problemáticas para diagnosticar problemas de erro, desempenho e latência, assim como a origem deles, como apps de desenvolvedor, proxies de API, destinos de back-end ou a plataforma de API.

Veja um exemplo de cenário que demonstra como resolver problemas de 5xx com suas APIs usando o monitoramento de APIs. Por exemplo, talvez você queira configurar um alerta para ser notificado quando o número de códigos de status 504 exceder um limite específico.