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 tempo limite é atingido no roteador |
|
O tempo limite é atingido no aplicativo cliente |
|
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
eonTimeoutRead
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.
- Se o servidor de back-end não responder em 55 segundos, o processador de mensagens expira e envia o erro
- 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, seio.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.
- 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
- 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
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 omessage 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:
- 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.
- Verifique se os processadores de mensagens estão com alto uso de CPU ou memória:
- 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
- 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
- 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
- Monitore as chamadas de API para confirmar se o problema ainda persiste.
- 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.
- 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:
Verifique isto: como o tempo limite é controlado para servidores de back-end do NodeJS no processador de mensagens
|
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:
- 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.
- Verifique se os processadores de mensagens estão com alto uso de CPU ou memória:
- 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
- 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
- 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
- Monitore as chamadas de API para confirmar se o problema ainda persiste.
- 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.
- 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:
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.
- 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.
- 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:
- 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
- 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
- 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
- Monitore as chamadas de API e confirme se o problema ainda persiste.
- 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.
- 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:
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.