O Google usa tecnologia de IA na tradução de conteúdos para seu idioma de preferência. As traduções com IA podem ter erros.

504 Tempo limite do gateway - Tempo limite do roteador

Você está lendo 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 504 com a mensagem Gateway Timeout em resposta às chamadas de API.

Essa resposta de erro indica que o cliente não recebeu uma resposta da Apigee Edge ou do servidor de back-end durante a execução de uma chamada de API.

Mensagem de erro

O aplicativo cliente recebe o seguinte código de resposta:

HTTP/1.1 504 Gateway Time-out

Ao chamar esse proxy usando cURL ou um navegador da Web, você pode receber o seguinte erro:

<!DOCTYPE html>
<html>
<head>
<title>Error</title>
<style>
    body {
        width: 35em;
        margin: 0 auto;
        font-family: Tahoma, Verdana, Arial, sans-serif;
    }
</style>
</head>
<body>
<h1>An error occurred.</h1>
<p>Sorry, the page you are looking for is currently unavailable.<br/>
Please try again later.</p>
</body>
</html>

O que causa os tempos limite?

O caminho típico para uma solicitação de API pela plataforma Edge é Cliente > Router > Message Processor > Backend Server, conforme mostrado na figura a seguir:

Todos os componentes no fluxo de ambiente de execução do Apigee Edge, incluindo clientes, roteadores, processadores de mensagens e servidores de back-end, são configurados com valores de tempo limite padrão adequados para garantir que as solicitações de API não demorem muito para serem concluídas. Se algum dos componentes no fluxo não receber a resposta do componente upstream dentro do período especificado na configuração de tempo limite, o componente específico vai atingir o tempo limite e geralmente vai retornar um erro 504 Gateway Timeout.

Este playbook descreve como solucionar e resolver um erro 504 causado quando o roteador atinge o tempo limite.

Tempo limite no roteador

O tempo limite padrão configurado nos roteadores do Apigee Edge é de 57 segundos. Esse é o tempo máximo que um proxy de API pode executar desde o momento em que a solicitação de API é recebida no Edge até que a resposta seja enviada de volta, incluindo a resposta do back-end e todas as políticas executadas. O tempo limite padrão pode ser substituído nos roteadores/hosts virtuais, conforme explicado em Configurar o tempo limite de E/S em roteadores.

Causas possíveis

No Edge, as causas típicas do erro 504 Gateway Timeout devido ao tempo limite do roteador são:

Causa	Descrição	Instruções de solução de problemas aplicáveis para
Configuração de tempo limite incorreta no roteador	Isso acontece se o roteador estiver configurado com um período de tempo limite de E/S incorreto.	Usuários da nuvem pública e privada do Edge

Etapas comuns do diagnóstico

Use uma das seguintes ferramentas/técnicas para diagnosticar esse erro:

Monitoramento de APIs
Registros de acesso do NGINX

Monitoramento de APIs

Para diagnosticar o erro usando o API Monitoring:

Acesse a página Analisar > Monitoramento de APIs > Investigar.
Filtre por erros de 5xx e selecione o período.
Crie um gráfico com Código de status e Tempo.
Clique na célula específica que mostra erros 504 para ver mais detalhes e registros sobre esses erros, conforme mostrado abaixo:

Exemplo mostrando erros 504
No painel à direita, clique em Ver registros.

Na janela Registros de tráfego, observe os seguintes detalhes de alguns erros 504:
- Solicitação:fornece o método de solicitação e o URI usados para fazer as chamadas.
- Tempo de resposta:mostra o tempo total decorrido para a solicitação.
No exemplo acima,
- A solicitação está apontando para GET /test-timeout.
- O tempo de resposta é de 57.001 segundos. Isso indica que o roteador atingiu o tempo limite antes que o processador de mensagens pudesse responder, já que o valor está muito próximo do tempo limite de E/S padrão definido no roteador, que é de 57 segundos.
Também é possível usar a API Monitoring GET logs para acessar todos os registros. Por exemplo, ao consultar os registros de org, env, timeRange e status, é possível baixar todos os registros de transações em que o cliente atingiu o tempo limite.

Como o API Monitoring define o proxy como - (not set) para esses erros 504, use a API (API Logs) para receber o proxy associado ao host virtual e ao caminho.

For example :
```
curl "https://apimonitoring.enterprise.apigee.com/logs/apiproxies?org=ORG&env=ENV&select=https
```
Observação:os campos a seguir vão mostrar o valor "-" para este erro 504:
- Origem da falha
- Código de falha
- Fluxo de falhas
- Política de falhas
- Proxy de falha
Esses campos são preenchidos pelo processador de mensagens e definidos com valores adequados somente se o roteador receber uma resposta do processador de mensagens. Nesse caso, o roteador atingiu o tempo limite antes do processador de mensagens porque não respondeu a tempo. Isso força o roteador a definir o código de status como 504 e, como resultado, todos os campos mencionados acima aparecem como -.
Analise o Tempo de resposta para outros erros de 504 e verifique se o Tempo de resposta é consistente (valor de tempo limite de E/S definido no roteador, que é de 57 segundos) em todos os erros de 504.

Registros de acesso do NGINX

Para diagnosticar o erro usando registros de acesso do NGINX:

Verifique os registros de acesso do NGINX:
/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log
Pesquise para ver se há erros de 504 durante um período específico (se o problema ocorreu no passado) ou se ainda há solicitações com falha em 504.
Confira as seguintes informações sobre alguns erros de 504:
- Tempo de resposta
- URI da solicitação
Neste exemplo, vemos as seguintes informações:
- Tempo da solicitação:57.001 segundos. Isso indica que o roteador atingiu o tempo limite após 57.001 segundos.
  
  Observação:isso representa o campo request_time nos registros do NGINX. Significa o tempo de processamento da solicitação em segundos, ou seja, o tempo decorrido entre a leitura dos primeiros bytes do cliente e a gravação do registro após o envio dos últimos bytes ao cliente.
- Solicitação:GET /test-timeout
- Alias do host: myorg-test.apigee.net
Observação:os campos a seguir vão mostrar o valor - para este erro de 504:
- Origem da falha
- Código de falha
- Fluxo de falhas
- Política de falhas
- Proxy de falha
Esses campos são preenchidos pelo processador de mensagens e só são definidos com valores adequados se o roteador receber uma resposta do processador de mensagens. Nesse caso, o roteador atingiu o tempo limite antes do processador de mensagens porque não respondeu a tempo. Isso força o roteador a definir o código de status como 504 e, como resultado, todos os campos mencionados acima aparecem como -.
Verifique se o Tempo da solicitação é igual ao tempo limite de E/S configurado no roteador/host virtual. Se sim, significa que o roteador atingiu o tempo limite antes que o processador de mensagens respondesse dentro desse período.

No exemplo de entrada de registro do NGINX mostrado acima, o tempo de solicitação de 57.001 segundos está muito próximo do tempo limite de E/S padrão definido no roteador. Isso indica claramente que o roteador atingiu o tempo limite antes que o processador de mensagens pudesse responder.
Determine o proxy de API para o qual a solicitação foi feita usando o caminho base no campo Solicitação .

Causa: configuração incorreta de tempo limite no roteador

Diagnóstico

Determine se os erros 504 são causados porque o roteador atingiu o tempo limite antes que o processador de mensagens pudesse responder. Para isso, verifique se o Tempo de resposta no API Monitoring/Tempo de solicitação no roteador (ambos os campos representam as mesmas informações, mas são chamados por nomes diferentes) é igual ao tempo limite de E/S configurado no roteador/host virtual e se os campos Origem da falha, Proxy de falha e Código de falha estão definidos como - usando o API Monitoring ou os registros de acesso do NGINX, conforme explicado em Etapas comuns de diagnóstico.
Verifique se o valor de tempo limite de E/S configurado no roteador ou host virtual específico é menor do que o configurado no processador de mensagens ou no proxy de API específico.

Para fazer isso, siga as etapas desta seção.

Como verificar o tempo limite de E/S em hosts virtuais

Interface do Edge

Para verificar o tempo limite do host virtual usando a interface do Edge, faça o seguinte:

Faça login na interface do Edge.
Acesse Administrador > Hosts virtuais.
Selecione um ambiente específico em que você está enfrentando o problema de tempo limite.
Selecione o host virtual específico para o qual você quer verificar o valor de tempo limite de E/S.
Em Propriedades, confira o valor de Tempo limite de leitura do proxy em segundos.

No exemplo acima, o tempo limite de leitura do proxy está configurado com o valor 120. Isso significa que o tempo limite de E/S configurado nesse host virtual é de 120 segundos.

Observação:se o tempo limite de leitura do proxy não tiver um valor, isso significa que ele vai usar o valor padrão de 57 segundos configurado no roteador, a menos que o tempo limite de E/S seja substituído nas instâncias do roteador.

APIs de gerenciamento

Também é possível verificar o tempo limite de leitura do proxy usando as seguintes APIs de gerenciamento:

Execute a API Get virtual host para receber a configuração virtualhost, conforme mostrado abaixo:

Usuário da nuvem pública

curl -v -X GET https://api.enterprise.apigee.com/v1/organizations/ORGANIZATION_NAME/environments/ENVIRONMENT_NAME/virtualhosts/VIRTUALHOST_NAME -u USERNAME

Usuário da nuvem privada

curl -v -X GET http://MANAGEMENT_SERVER_HOST:PORT#/v1/organizations/ORGANIZATION_NAME/environments/v/virtualhosts/VIRTUALHOST_NAME -u USERNAME

Em que:

ORGANIZATION_NAME é o nome da organização

ENVIRONMENT_NAME é o nome do ambiente;

VIRTUALHOST_NAME é o nome do host virtual.

Verifique o valor configurado para a propriedade proxy_read_timeout.

Exemplo de definição de host virtual

{
  "hostAliases": [
    "api.myCompany,com",
  ],
  "interfaces": [],
  "listenOptions": [],
  "name": "secure",
  "port": "443",
  "retryOptions": [],
  "properties": {
    "property": [
      {
        "name": "proxy_read_timeout",
        "value": "120"
      }
    ]
  },
  "sSLInfo": {
    "ciphers": [],
    "clientAuthEnabled": "false",
    "enabled": "true",
    "ignoreValidationErrors": false,
    "keyAlias": "myCompanyKeyAlias",
    "keyStore": "ref://myCompanyKeystoreref",
    "protocols": []
  },
  "useBuiltInFreeTrialCert": false
}

No exemplo acima, proxy_read_timeout é configurado com um valor de 120. Isso significa que o tempo limite de E/S configurado nesse host virtual é de 120 segundos.

Observação:se a propriedade proxy_read_timeout não existir na saída da API de gerenciamento, isso significa que ela vai usar o valor padrão de 57 segundos, a menos que o tempo limite de E/S seja substituído nas instâncias do roteador.

Como verificar o tempo limite de E/S no arquivo router.properties

Faça login em uma máquina de roteador.
Pesquise a propriedade proxy_read_timeout no diretório /opt/nginx/conf.d e verifique se ela foi definida com o novo valor da seguinte maneira:
```
grep -ri "proxy_read_timeout" /opt/nginx/conf.d
```
Verifique o valor definido para a propriedade proxy_read_timeout no arquivo de configuração do host virtual específico.

Exemplo de resultado do comando grep
```
/opt/nginx/conf.d/0-default.conf:proxy_read_timeout 57;
/opt/nginx/conf.d/0-edge-health.conf:proxy_read_timeout 1s;
```
No exemplo de saída acima, observe que a propriedade proxy_read_timeout foi definida com o novo valor 57 em 0-default.conf, que é o arquivo de configuração do host virtual padrão. Isso indica que o tempo limite de E/S está configurado para 57 segundos no roteador para o host virtual padrão. Se você tiver vários hosts virtuais, essas informações vão aparecer para cada um deles. Receba o valor de proxy_read_timeout para o host virtual específico usado para fazer as chamadas de API que falharam com erros 504.

Como verificar o tempo limite de E/S no proxy de API

É possível conferir o tempo limite de E/S nos seguintes locais:

Endpoint de destino do proxy de API
Política ServiceCallout do proxy de API

Ver o tempo limite de E/S no endpoint de destino do proxy de API

Na interface do Edge, selecione o proxy de API específico em que você quer ver o valor de tempo limite de E/S.
Selecione o endpoint de destino específico que você quer verificar.
Consulte a propriedade io.timeout.millis com um valor adequado no elemento <HTTPTargetConnection> na configuração TargetEndpoint.
Por exemplo, o tempo limite de E/S no código a seguir é definido como 120 segundos:
```
<Properties>
  <Property name="io.timeout.millis">120000</Property>
</Properties>
```

Ver o tempo limite de E/S na política ServiceCallout do proxy de API

Na interface do Edge, selecione o proxy de API específico em que você quer ver o novo valor de tempo limite de E/S para a política ServiceCallout.
Selecione a política ServiceCallout específica que você quer verificar.
Consulte o elemento <Timeout> com um valor adequado na configuração <ServiceCallout>.

Por exemplo, o tempo limite de E/S do código a seguir será de 120 segundos:
```
<Timeout>120000</Timeout>
```

Verificar o tempo limite de E/S nos processadores de mensagens

Faça login na máquina do processador de mensagens.

Procure a propriedade HTTPTransport.io.timeout.millis no diretório /opt/apigee/edge-message-processor/conf usando o seguinte comando:

grep -ri "HTTPTransport.io.timeout.millis" /opt/apigee/edge-message-processor/conf

Exemplo de saída

/opt/apigee/edge-message-processor/conf/http.properties:HTTPTransport.io.timeout.millis=55000

No exemplo de saída acima, observe que a propriedade HTTPTransport.io.timeout.millis foi definida com o valor 55000 em http.properties. Isso indica que o tempo limite de E/S foi configurado com sucesso para 55 segundos no processador de mensagens.

Depois de determinar o tempo limite configurado no roteador e no processador de mensagens, verifique se o roteador/host virtual foi configurado com um valor de tempo limite menor em comparação com o do processador de mensagens/proxy de API.

Anote os valores definidos em todas as camadas, conforme mostrado na tabela abaixo:

Tempo limite no roteador (segundos)	Tempo limite no host virtual (segundos)	Tempo limite no processador de mensagens (segundos)	Tempo limite no proxy de API (segundos)
57	-	55	120

Neste exemplo,

O valor padrão de 57 segundos é configurado no roteador.
O valor de tempo limite não está definido no host virtual específico. Isso significa que ele vai usar o valor padrão de 57 segundos configurado no próprio roteador.
No processador de mensagens, um valor padrão de 55 segundos é configurado.
No entanto, no proxy de API específico, um valor de 120 segundos está configurado.

O valor de tempo limite mais alto é configurado apenas no proxy de API, mas o roteador ainda é configurado com 57 segundos. Portanto, o roteador atinge o tempo limite em 57 segundos, enquanto o processador de mensagens/backend ainda está processando sua solicitação. Isso faz com que o roteador responda com o erro 504 Gateway Timeout ao aplicativo cliente.

Resolução

Siga estas etapas para configurar o tempo limite de E/S adequado no roteador e no processador de mensagens e resolver o problema.

Consulte Práticas recomendadas para configurar o tempo limite de E/S e entenda quais valores de tempo limite devem ser definidos em diferentes componentes envolvidos no fluxo de solicitação de API pelo Apigee Edge.
No exemplo acima, se você determinar que um valor de tempo limite maior precisa ser definido porque o servidor de back-end exige mais tempo e você aumentou o valor de tempo limite do processador de mensagens para 120 segundos, defina um valor de tempo limite maior. Por exemplo: 123 seconds no roteador. Para evitar o impacto em todos os proxies de API devido ao novo valor de tempo limite, defina o valor de 123 seconds apenas no host virtual específico usado no proxy de API específico.
Siga as instruções em Configurar o tempo limite de E/S em roteadores para definir o tempo limite no host virtual.