Esta página foi traduzida pela API Cloud Translation.

504 Gateway Timeout

Você está vendo a documentação do Apigee Edge.
Acesse a documentação da Apigee X. informações

Sintoma

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

O erro Código de status HTTP - 504 Gateway Timeout indica que o cliente não recebeu uma resposta em tempo hábil do gateway de borda ou do servidor de back-end durante a execução de uma API.

Mensagens de erro

O aplicativo cliente recebe este 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 os tempos limite do gateway?

O caminho típico para uma solicitação de API pela plataforma de borda será Cliente -> Roteador -> Processador de mensagens -> Servidor de back-end, conforme a 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 de borda espera que uma resposta seja enviada dentro de um determinado período 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 é atingido no processador de mensagens	O servidor de back-end não responde ao processador de mensagens dentro de um tempo limite especificado. 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. 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. O aplicativo cliente expira e encerra o status de resposta como `504 Gateway Timeout` para o usuário final.

Causas possíveis

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

Causa	Detalhes	Etapas dadas para
Servidor de back-end lento	O servidor de back-end que está processando a solicitação de API está muito lento devido à alta carga ou a um desempenho ruim.	Usuários de nuvens públicas e privadas
Processamento lento de solicitações de API por Edge	O Edge leva muito tempo para processar a solicitação de API devido à alta carga ou ao baixo desempenho.

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ê receberá um erro 504 Gateway Timeout. Conforme explicado na seção acima, esse tempo limite pode ocorrer em um dos seguintes cenários:

O processador de mensagens expira antes de o servidor de back-end responder.
O roteador expira antes que o processador de mensagens/servidor de back-end responda.
O aplicativo cliente expira antes de o roteador, o processador de mensagens ou o 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 n.o 1 O processador de mensagens expira antes da resposta do servidor de back-end

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: uso do Trace

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

Identifique a API afetada na interface do Edge. Aguarde a ocorrência do erro ou, se você tiver uma chamada de API, faça algumas chamadas de API e reproduza o erro 504 Gateway Timeout.
Quando 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 a maior parte do tempo é gasta.
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 está demorando muito para processar a solicitação:
- Solicitação enviada ao servidor de destino
- Política ServiceCallout

Confira 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 rastreamento acima, o processador de mensagens expira após 55.002 ms porque o servidor de back-end não responde.

Procedimento 2: como usar os 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 de proxy de API específica em um horário específico, 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 expirou e enviou o erro 504 Gateway Timeout.

Marque esta opção: 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) 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 55 segundos, o processador de mensagens expira e envia o erro 504 Gateway Timeout ao 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 estiver definido como 10 segundos no proxy da API, o valor de tempo limite de 10 segundos será usado para esse proxy 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 expira e envia o erro 504 Gateway Timeout ao cliente.

Resolução

Verifique por que o servidor de back-end está demorando mais de 55 segundos e veja 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 souber 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 expira antes de o processador de mensagens/servidor de back-end responder

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

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

Tempo limite do roteador	Tempo limite do 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 forem definidos:

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

Mas o io.timeout.millis está definido como 120 segundos no proxy da 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 atingirá o tempo limite após 55 segundos, mesmo que seu valor de tempo limite (55 segundos) seja menor que o valor de tempo limite do 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 da 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 tempo limite menor (57 segundos) em comparação com os 120 segundos definidos no proxy da 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 expirar antes do processador de mensagens, você verá o status de 504 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 ocorre porque o roteador não recebeu nenhuma resposta do processador de mensagens dentro do período de tempo limite definido nele.

Exemplo de entrada de registro do NGINX mostrando o erro 504 devido ao tempo limite do roteador
No exemplo acima, observe o status de 504 no NGINX, o ID da mensagem do processador de mensagens é - e o tempo total decorrido é de 57.001 segundos. Isso ocorreu porque o roteador expirou após 57.001 segundos e não recebemos nenhuma resposta do processador de mensagens.

Nesse caso, você verá 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 roteador expira, ele encerra 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á foi encerrada, você receberá o Broken Pipe exception no processador de mensagens.

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

Resolução

Se for um servidor de back-end personalizado:

Verifique por que o servidor de back-end está demorando muito para responder e veja 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 você souber que ele 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 da API

No caso de um servidor de back-end do NodeJS:
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 tempo e corrija o problema conforme apropriado.
2. Verifique se os processadores de mensagens estão com alto uso de CPU ou memória:
  1. Se algum processador de mensagens estiver apresentando alto uso de CPU, gere três dumps 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 apresentando alto uso 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 vai reduzir 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 persiste.
  5. Entre em contato com o suporte do Apigee Edge e forneça os registros de dumps de linhas de execução, heap dump e 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 processador de mensagens

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

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

É possível que você receba erros 504 Gateway Timeout se o 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 que o valor de tempo limite definido no roteador e no processador de mensagens:

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

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

Nesse caso, o tempo total disponível para receber uma resposta a uma solicitação de API pelo Edge é de 50 segundos ou menos. Isso inclui o tempo necessário para fazer uma solicitação de API, a solicitação processada pelo Edge (roteador, Processador de mensagens), a solicitação enviada ao servidor de back-end (se aplicável), o processamento e o envio da solicitação pelo back-end, o processamento da resposta no Edge e o envio dela de volta ao cliente.

Se o roteador não responder ao cliente em até 50 segundos, o cliente atingirá o tempo limite e encerrará a conexão com o roteador. O cliente vai 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 fechou a conexão.

Diagnóstico

Se o aplicativo cliente expirar antes de receber uma resposta do roteador, a conexão com o roteador será encerrada. Nessa situação, você verá 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 é de 50,001 segundos. Isso indica que o cliente expirou após 50,001 segundos.

Nesse caso, vão aparecer 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>

Depois que o roteador expira, ele encerra 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á foi encerrada, você vai receber 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, faça o seguinte:

Verifique o servidor de back-end para determinar por que está demorando mais de 57 segundos e veja 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 você souber que o servidor de back-end 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 da API

Se for um back-end do NodeJS, então:
1. Verifique se o código NodeJS faz chamadas para outros servidores de back-end e se 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 com alto uso de CPU ou memória:
  1. Se um processador de mensagens estiver apresentando alto uso de 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 apresentando alto uso de memória, gere um heap dump usando o comando a seguir:
```
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 vai reduzir 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 persiste.
  5. Entre em contato com o suporte do Apigee Edge e forneça os registros de despejos de linhas de execução, heap dump e 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.

Aumente 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 de suas necessidades. Não defina valores de tempo limite arbitrariamente altos. Se você 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 roteador, se ele ainda não existir.

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 um valor de tempo limite de 120 segundos, faça o seguinte:

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

Verifique se esse arquivo é de propriedade da 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 para 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 a este arquivo:
```
conf_http_HTTPTransport.io.timeout.millis=TIME_IN_MILLISECONDS
```
Por exemplo, se você quiser definir um valor de tempo limite de 120 segundos, faça o seguinte:
```
conf_http_HTTPTransport.io.timeout.millis=120000
```

Verifique se este arquivo é de propriedade da 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 para 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 da API

Processamento lento de solicitações de API por Edge

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

Diagnóstico

Identifique a API afetada na interface do Edge.
Aguarde a ocorrência do erro ou, se você tiver uma chamada de API, faça algumas chamadas de API e reproduza o erro 504 Gateway Timeout.
Observe que, nesse caso, você verá uma resposta bem-sucedida no Trace.
1. O roteador/cliente expira quando o processador de mensagens não responde dentro do tempo limite especificado no roteador/cliente (o que tiver o menor período de tempo limite). No entanto, o processador de mensagens continua a processar a solicitação e pode ser concluída.
2. Além disso, o valor HTTPTransport.io.timeout.millis definido no processador de mensagens será acionado somente se ele se comunicar com um servidor de back-end HTTP/HTTPS. Em outras palavras, esse tempo limite não vai ser acionado quando alguma política (exceto a Service callout) no proxy de API estiver demorando muito.
Depois que o erro ocorrer, examine a solicitação específica com o maior tempo decorrido.
Verifique o tempo decorrido em cada fase e anote aquela em que a maior parte do tempo é gasta.
Se você observar o maior tempo decorrido em qualquer uma das políticas diferentes da de chamada de serviço, isso indica que o Edge está demorando muito para processar a solicitação.
Confira um exemplo de trace de interface que mostra um tempo decorrido muito alto na política de JavaScript:
No exemplo acima, você percebe que a política JavaScript leva um tempo excepcionalmente longo, de aproximadamente 245 segundos.

Resolução

Verifique se a política que levou muito tempo para responder e se há algum código personalizado que possa levar muito tempo para ser processado. Se houver algum desses códigos, verifique se é possível corrigir/otimizar o código identificado.
Se não houver um código personalizado que possa causar alto tempo de processamento, verifique se os processadores de mensagens estão apresentando alto uso de CPU ou memória:
1. Se algum processador de mensagens estiver apresentando alto uso de CPU, gere três dumps 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 apresentando alto uso de memória, gere um heap dump usando o comando a seguir:
```
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 reduzirá 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 persiste.
5. Entre em contato com o suporte do Apigee Edge e forneça os registros de despejos de linha de execução, heap dump e 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.

Diagnosticar problemas usando o monitoramento de APIs

O Monitoramento de APIs permite isolar áreas problemáticas para diagnosticar erros, desempenho e latência rapidamente, além da origem, como apps de desenvolvedores, proxies de API, destinos de back-end ou a plataforma da API.

Consulte um exemplo de cenário que demonstra como resolver problemas de 5xx com suas APIs usando o monitoramento de APIs. 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.