Esta página foi traduzida pela API Cloud Translation.

504 Gateway Timeout

Esta é a documentação do Apigee Edge.
Acesse 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 uma resposta para as chamadas de API.

O código de status HTTP - erro 504 Gateway Timeout indica que o cliente não recebeu resposta em tempo hábil do gateway de borda ou do servidor de back-end durante a execução do 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 será Client -> Roteador -> Processador de mensagens -> Servidor de back-end, como mostra 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 em até o período especificado, 504 Gateway Timeout Error é retornado.

A tabela a seguir dá 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 no processador de mensagens. O processador de mensagens expira e envia o status de resposta como `504 Gateway Timeout` ao 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` ao aplicativo cliente.
O tempo limite ocorre no aplicativo cliente	O roteador não responde ao aplicativo cliente dentro do tempo limite especificado período 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 fornecidas para
Servidor de back-end lento	O servidor de back-end que está processando a solicitação de API é muito lento devido à alta carga ou desempenho ruim.	Usuários de nuvem pública e privada
Processamento lento de solicitações de API por Edge	O Edge leva muito tempo para processar a solicitação de API devido à carga alta ou ruim. desempenho.

Lenta servidor de back-end

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, o tempo limite pode ocorrer em um dos seguintes cenários:

O processador de mensagens expira 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 uma delas diferentes.

Cenário no 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 no 1: uso do Trace

Se o problema ainda estiver ativo (504 erros ainda estão acontecendo), faça o seguinte: etapas:

Rastrear a API afetada na interface do Edge. Aguarde até que o erro ocorra ou se você tem 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:
Verifique o tempo decorrido em cada fase e anote aquela em que passou mais tempo. gasto.
Se você observar o erro com o maior tempo decorrido logo 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

Veja a seguir um exemplo de Trace que mostra que o servidor de back-end não respondeu, nem 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, assim como o servidor de back-end. não responder.

Procedimento no 2: como usar registros do processador de mensagens

Verificar 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 do proxy de API no horário específico, isso indica que o tempo limite do processador de mensagens expirou.

Exemplo de registro do processador de mensagens mostrando 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 IP O endereço 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 geralmente definido 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 servidor de O processador expira e envia o 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 especificados no proxy da API. Esse valor de tempo limite é aplicável a uma API específica Proxy em que a propriedade mencionada acima é especificada. Por exemplo, se o io.timeout.millis é definido como 10 segundos no proxy de API, então o valor de tempo limite de 10 segundos será usado para este proxy de API específico.
- Se o servidor de back-end não responder em até 10 segundos para a proxy de API, o processador de mensagens expira e envia 504 Gateway Timeout. ao cliente.

Resolução

Verifique por que o servidor de back-end está demorando mais de 55 segundos e se isso pode ser corrigidos/otimizados para responder mais rapidamente.
Se não for possível corrigir/otimizar o servidor de back-end ou se você souber que o back-end servidor demorar mais que o tempo limite configurado, então Aumente o tempo limite no Roteador e processador de mensagens para um valor adequado.

Situação 2 - O roteador expira antes de o processador de mensagens/servidor de back-end responder

Você poderá receber erros 504 Gateway Timeout se o roteador expirar antes da mensagem O processador/servidor de back-end responde. 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 Por exemplo, digamos que o tempo limite no Roteador seja de 50 segundos, enquanto o "Processador" tem 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 de tempo limite mais alto 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 a io.timeout.millis está definida 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 atingirá o tempo limite após 55 segundos, mesmo que tenha atingido o tempo limite (55 segundos) é 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 será substituído pelo valor de 120 segundos definidos no proxy de API. O valor de tempo limite do processador de mensagens para este proxy de API específico será de 120 segundos.

Como o roteador tem um valor de tempo limite menor (57 segundos) em comparação aos 120 segundos definidos proxy de API, o roteador 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, o status 504 será exibido. nos registros de acesso do NGINX para a solicitação de API específica e o message id da o processador de mensagens será definido como -. Isso ocorre porque o roteador não recebeu resposta do processador de mensagens dentro do período de tempo limite definido no roteador.

Exemplo de entrada de registro 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 O processador é -, e o tempo total decorrido é de 57.001 segundos. Isso ocorre porque o tempo limite do roteador expirou após 57.001 segundos e ainda não recebemos nenhuma resposta do processador de mensagens.

Nesse caso, você verá Broken Pipe exceções na mensagem Registros do processador (/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, uma vez 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 o resposta ao roteador. Como a conexão com o roteador já foi encerrada, você vai receber Broken Pipe exception no processador de mensagens.

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

Resolução

No caso de um servidor de back-end personalizado,

Verifique por que o servidor de back-end está demorando muito para responder e se pode ser corrigidos/otimizados para responder mais rapidamente.

Se não for possível corrigir/otimizar o servidor de back-end ou for um fato conhecido que o servidor de back-end demorar muito, então Aumente o valor de tempo limite em entre o Cloud Router e o processador de mensagens.

Ideia: defina o valor de tempo limite nos diferentes componentes a seguir ordem:

Tempo limite no cliente > Tempo limite no roteador > Tempo limite na mensagem Processador > Tempo limite no proxy de API

Se for um servidor de back-end do NodeJS:
1. Verifique se o código NodeJS faz chamadas para qualquer outro servidor de back-end e se está demorando muito tempo para retornar uma resposta. Verifique por que os servidores de back-end estão demorando mais e 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 um alto uso da CPU, gere três conversa dumps a cada 30 segundos usando o seguinte comando:
```
JAVA_HOME/bin/jstack -l PID > FILENAME
```
  2. Se algum processador de mensagens estiver apresentando um alto uso de 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 vai desligar a CPU e 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 informe o despejos de linhas de execução, heap dump e registros do processador de mensagens (/opt/apigee/var/log/edge-message-processor/logs/system.log)para ajudar 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. A o valor de tempo limite para servidores de back-end do NodeJS é controlado pela propriedade http.request.timeout.seconds no arquivo nodejs.properties. Isso é definida como 0 por padrão, ou seja, o tempo limite está desabilitado 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 NodeJS demorar muito, o processador de mensagens não atingirá o tempo limite.
No entanto, se o servidor de back-end do NodeJS demorar muito e se o tempo gasto pela API solicitação é > 57 segundos, o roteador atingirá o tempo limite e enviará 504 Gateway Timeout ao cliente.

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

Você poderá receber erros 504 Gateway Timeout se o aplicativo cliente expirar antes da o servidor de back-end responde. 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 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 a uma solicitação de API pelo Edge é <= 50 segundos. Isso inclui o tempo necessário para fazer uma solicitação de API, a solicitação sendo processado pelo Edge (Roteador, Processador de mensagens), a solicitação enviada ao servidor de back-end (se aplicável), o back-end processa a solicitação e envia a resposta, o Edge processa a e, por fim, retorná-la ao cliente.

Se o roteador não responder ao cliente em 50 segundos, o cliente tempo limite e encerrar a conexão com o roteador. O cliente 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 uma conexão com a Internet.

Diagnóstico

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

Nesse caso, você verá Broken Pipe Exceções na mensagem Registros do processador (/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 O processador de mensagens conclui o processamento e 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. Então, a causa real o erro 504 Gateway Timeout ainda for 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 está demorando mais de 57 segundos e veja 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 o servidor de back-end demorará muito, então aumente o valor de tempo limite em roteador e processador de mensagens.

Ideia: defina o valor de tempo limite nos diferentes componentes a seguir ordem:

Tempo limite no cliente > Tempo limite no roteador > Tempo limite na mensagem Processador > Tempo limite no proxy de API

Se for um back-end NodeJS:
1. Verifique se o código NodeJS faz chamadas para qualquer outro servidor de back-end e se isso é levar muito tempo 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 da CPU ou da memória:
  1. Se um processador de mensagens estiver com alto uso da CPU, gere três conversa dumps a cada 30 segundos usando o seguinte comando:
```
JAVA_HOME/bin/jstack -l PID > FILENAME
```
  2. Se um processador de mensagens estiver apresentando um 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 deve interromper CPU e 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 informe o despejos de linhas de execução, heap dump e registros do processador de mensagens (/opt/apigee/var/log/edge-message-processor/logs/system.log)para ajudá-los investigar a causa do alto uso de CPU/memória.

Aumentar o valor do tempo limite em Roteador e processador de mensagens

Escolha com cuidado os valores de tempo limite a serem definidos no Roteador e no Processador de Mensagens, dependendo de acordo com seus requisitos. Não defina valores de tempo limite arbitrariamente grandes. Se precisar de ajuda, entre em contato Suporte do Apigee Edge.

Roteador

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

Crie o arquivo /opt/apigee/customer/application/router.properties no máquina roteadorra, se ainda não houver uma.
Adicione a seguinte linha a esse 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, defina-o como da seguinte forma:
```
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 em todos eles.

processador de mensagens

Criar um arquivo /opt/apigee/customer/application/message-processor.properties em a máquina do processador de mensagens, se ela ainda não existir.
Adicione a seguinte linha a esse arquivo:
```
conf_http_HTTPTransport.io.timeout.millis=TIME_IN_MILLISECONDS
```
Por exemplo, se você quiser definir o valor de tempo limite de 120 segundos, defina-o como da seguinte forma:
```
conf_http_HTTPTransport.io.timeout.millis=120000
```

Verifique se esse 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 todas Processadores.

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 por Edge

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

Diagnóstico

Rastrear a API afetada na interface do Edge.
Aguarde a ocorrência do erro ou, caso tenha a chamada de API, faça algumas chamadas de API e reproduzir o erro 504 Gateway Timeout.
Nesse caso, talvez você receba uma resposta bem-sucedida no Trace.
1. O roteador/cliente expira, pois o processador de mensagens não responde dentro do período de tempo limite 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 ser concluído. com sucesso.
2. Além disso, o valor HTTPTransport.io.timeout.millis definido O processador de mensagens é acionado somente se o processador de mensagens se comunica com um endereço de e-mail servidor de back-end. Em outras palavras, esse tempo limite não será acionado quando alguma política (outros do que a política ServiceCall) no proxy de API está demorando muito.
Após a ocorrência do erro, examine a solicitação específica que tiver o maior tempo tempo decorrido.
Verifique o tempo decorrido em cada fase e anote aquela em que teve mais tempo. gasto.
Se você observar o maior tempo decorrido em qualquer uma das políticas que não sejam as do Serviço Política de chamada, que indica que o Edge está demorando muito para processar solicitação.
Confira um exemplo de rastro da interface mostrando um tempo decorrido muito alto na política do 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 pode exigir muito tempo de processamento. Se houver algum desses códigos, veja se é possível corrigir/otimizar o código identificado.
Se não houver um código personalizado que possa aumentar o tempo de processamento, verifique se a mensagem Os processadores estão com um alto uso da CPU ou da memória:
1. Se algum processador de mensagens estiver apresentando um alto uso da CPU, gere três conversa dumps 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 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 desligar a CPU e 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 ocorre.
5. Entre em contato com o suporte do Apigee Edge e informe a conversa. dumps, heap dump e registros do processador de mensagens (/opt/apigee/var/log/edge-message-processor/logs/system.log)para ajudá-los investigar a causa do alto uso de CPU/memória.

Diagnosticar problemas usando a API Monitoring

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

Confira um exemplo de cenário que demonstra como resolver problemas 5xx com suas APIs usando a API Monitoring. 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.