Esta página foi traduzida pela API Cloud Translation.

504 Gateway Timeout

Você está visualizando 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 de 504 com a mensagem Gateway Timeout como resposta às 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 os tempos limite de gateway?

O caminho típico de uma solicitação de API pela plataforma Edge é Cliente -> Roteador -> Processador de mensagens -> Servidor de back-end, 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 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 timeouts podem ocorrer no Edge:

Ocorrência de tempo limite	Detalhes
Ocorreu um tempo limite 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 expira e envia o status de 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 tempo limite especificado no roteador. O roteador expira e envia o status de resposta como `504 Gateway Timeout` ao 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 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 do erro 504 Gateway Timeout são:

Causa	Detalhes	Etapas para
Servidor de back-end lento	O servidor de back-end que está processando a solicitação de API é muito lento devido à carga alta ou ao 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 da API devido à alta carga ou à baixa performance.

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. Como 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 da resposta do processador de mensagens/servidor de back-end.
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 1 O processador de mensagens expira 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 ao servidor de back-end lento.

Procedimento 1: usar o Trace

Se o problema ainda estiver ativo (os erros 504 ainda estiverem 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 de API 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.
Confira o tempo decorrido em cada fase e anote a fase em que a maior parte do tempo é gasta.
Se você observar o erro com o tempo decorrido mais longo imediatamente após uma das fases a seguir, 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

Veja a seguir um exemplo de Trace 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 tem um tempo limite após 55002 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 na solicitação de proxy da API específica no momento específico, isso indica que o processador de mensagens expirou.

Exemplo de registro do processador de mensagens mostrando o erro de tempo limite da 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 um erro 504 Gateway Timeout.

Confira este artigo: 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 pela 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 irá expirar e enviar um erro 504 Gateway Timeout para o cliente.
O valor de tempo limite especificado no processador de mensagens pode ser substituído pela propriedade io.timeout.millis especificada no proxy da API. Esse valor de tempo limite é aplicável a um proxy de API específico em que a propriedade mencionada acima é definida. Por exemplo, se o io.timeout.millis for definido como 10 segundos no proxy da API, esse valor de tempo limite será usado para esse proxy 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 expirar 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 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 ele demorar mais 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 que o processador de mensagens/servidor de back-end responda

Você poderá 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 o processador de mensagens seja de 55 segundos.

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

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

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

Tempo limite no roteador	Timeout no 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>

O processador de mensagens não vai expirar após 55 segundos, mesmo que o 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 que é definido no proxy de API. Portanto, o valor do 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 esse período.

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, o status de 504 nos logs de acesso do NGINX para a solicitação de API específica e o message id do processador de mensagens serão definidos como -. Isso ocorre porque o roteador não recebeu nenhuma resposta do processador de mensagens dentro do período de tempo limite definido no roteador.

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

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 aparece porque, quando o 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á 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 é o servidor de back-end demorar 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 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 sabido que ele leva muito tempo, aumente o valor do tempo limite no Roteador e no processador de mensagens.

Ideia: defina o valor do 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 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 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 com uso alto de CPU, gere três dumps de thread a cada 30 segundos usando o seguinte comando:
```
JAVA_HOME/bin/jstack -l PID > FILENAME
```
  2. Se algum processador de mensagens estiver com uso de 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 vai desativar 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 do Apigee Edge e forneça os despejos de linha de execução, de heap e de logs do processador de mensagens (/opt/apigee/var/log/edge-message-processor/logs/system.log)) para ajudar a investigar a causa do uso intenso de CPU/memória.

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

O servidor de back-end do NodeJS é executado no processo JVM do processador de mensagens. O valor de tempo limite dos 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 NodeJS demore muito, o tempo limite do processador de mensagens não será excedido.
No entanto, se o servidor de back-end do NodeJS demorar muito e o tempo gasto pela solicitação de API for maior do 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 que o roteador/processador de mensagens/servidor de back-end responda

Você poderá receber erros 504 Gateway Timeout se o aplicativo cliente expirar antes da resposta do servidor de back-end. Isso 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	Timeout no roteador	Timeout no 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. Isso inclui o tempo que leva para fazer uma solicitação de API, a solicitação sendo processada pelo Edge (roteador, processador de mensagens), a solicitação sendo enviada ao servidor de back-end (se aplicável), o back-end processando a solicitação e enviando a resposta, o Edge processando a resposta e, por fim, enviando-a de volta ao cliente.

Se o roteador não responder ao cliente em 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 atingir o tempo limite antes de receber uma resposta do roteador, ele vai fechar a conexão com o roteador. 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 atingiu o tempo limite após 50,001 segundos.

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-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á 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, faça o seguinte:

Verifique o servidor de back-end para determinar por que ele 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 ele vai demorar muito, aumente o valor do tempo limite no roteador e no processador de mensagens.

Ideia: defina o valor do 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 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 com alta utilização de CPU ou memória:
  1. Se um processador de mensagens estiver com um uso alto de CPU, gere três dumps de thread a cada 30 segundos usando o seguinte comando:
```
JAVA_HOME/bin/jstack -l PID > FILENAME
```
  2. Se um processador de mensagens estiver com uso de 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 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 do Apigee Edge e forneça os despejos de linha de execução, de heap e de logs do processador de mensagens (/opt/apigee/var/log/edge-message-processor/logs/system.log)) para ajudar a investigar a causa do uso intenso de CPU/memória.

Aumente o valor do 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 a este arquivo:

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

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

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

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

Verifique se o 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 em todos os processadores.

Ideia: defina o valor do 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 pelo Edge

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

Diagnóstico

Rastrear a API afetada na interface do Edge.
Aguarde o erro ou, se você tiver a chamada de API, faça algumas chamadas de API e reproduza o erro 504 Gateway Timeout.
Nesse caso, talvez você receba uma resposta bem-sucedida no Trace.
1. O roteador/cliente tem um tempo limite porque o processador de mensagens não responde dentro do período de tempo limite especificado no roteador/cliente (qualquer um com o menor período de tempo limite). No entanto, o processador de mensagens continua processando a solicitação e pode ser concluído com sucesso.
2. Além disso, o valor HTTPTransport.io.timeout.millis definido no processador de mensagens é acionado somente se o processador de mensagens se comunicar com um servidor de back-end HTTP/HTTPS. Em outras palavras, esse tempo limite não será acionado quando alguma política (exceto a de Servicecall) no proxy de API estiver demorando muito.
Depois que o erro ocorrer, examine a solicitação específica que tem o tempo mais longo decorrido.
Confira o tempo decorrido em cada fase e anote a fase em que mais tempo é gasto.
Se você observar o tempo mais longo decorrido em qualquer uma das políticas que não sejam 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 de JavaScript:
No exemplo acima, a política de 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 possa exigir muito tempo de processamento. Se houver algum código desse tipo, 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 um alto uso da CPU ou da memória:
1. Se algum processador de mensagens estiver apresentando 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 muito a memória, gere um heap dump com 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 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 do Apigee Edge e forneça os despejos de linha de execução, de heap e de logs do processador de mensagens (/opt/apigee/var/log/edge-message-processor/logs/system.log)) para ajudar a investigar a causa do uso intenso de CPU/memória.

Diagnosticar problemas usando a API Monitoring

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

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