502 Bad Gateway

Esta é a documentação do Apigee Edge.
Acesse Documentação da Apigee X. informações

Sintoma

O aplicativo cliente recebe o código de status HTTP 502 com a mensagem "Gateway inválido" como uma resposta para chamadas de API.

O código de status HTTP 502 significa que o cliente não está recebendo uma resposta válida do servidores de back-end que vão atender à solicitação.

Mensagens de erro

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

HTTP/1.1 502 Bad Gateway

Além disso, você poderá encontrar as seguintes mensagens de erro:

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

Se o erro vier do servidor de back-end, talvez você veja algo parecido com isto. A mensagem de erro do back-end depende completamente da implementação. 

<html>
<head><title>502 Bad Gateway</title></head>
<body bgcolor="white">
<center><h1>502 Bad Gateway</h1></center>
</body>
</html>

Causas possíveis

Estas são algumas das possíveis causas do erro "502 Gateway inválido" para APIs que passam pelo Apigee Edge:

Causa Descrição Instruções para solução de problemas aplicáveis
Não há MPs disponíveis no grupo Esse erro será observado se todos os MPs no pool estiverem indisponíveis, ou seja, se estiverem inativos ou ocupados e, portanto, não respondem. Usuários da nuvem privada do Edge
Configuração de SSL incorreta entre roteadores e MPs Esse erro será observado se o certificado raiz assinado pela CA do cliente estiver ausente no truststore do roteador do Edge. Usuários da nuvem privada do Edge
Erro do servidor de back-end Esse erro será observado se o servidor de back-end falhar e enviar essa resposta. Usuários de nuvem pública e privada do Edge

Causa: nenhum MP está disponível no pool

Esse erro ocorrerá se o Roteador descobrir que todos os processadores de mensagens em uma determinada região/data center estão indisponíveis (por exemplo, se todos estiverem inativos).

O Apigee Edge é configurado de modo que o tráfego de API de entrada (solicitações) em uma determinada região/data center sempre seja roteado dos roteadores para os processadores de mensagens (MPs, na sigla em inglês) na mesma região/data center. Em alguns casos, os componentes do Apigee Edge podem ser configurados em apenas uma região/data center. Em alguns casos, eles podem ser configurados em mais de uma região/data center. Em cada região/data center, haverá dois ou mais roteadores e processadores de mensagens configurados.

Diagnóstico

  1. Determine as regiões/os data centers em que as solicitações da API estão falhando com o erro 502 Gateway inválido, se houver mais de uma região/data center. Para isso, identifique a região em que os usuários estão observando erros 502 ou verifique os registros de acesso do NGINX no diretório /opt/apigee/var/log/edge-router/nginx/ em cada um dos roteadores que pertencem a regiões diferentes.
  2. O seguinte erro vai aparecer nos registros de erros do NGINX (/opt/apigee/var/log/edge-router/nginx/ORG-Env._error_log)
    2019/06/24 15:26:00 [error] 4796#4796: *56357443 no live upstreams while connecting to upstream, client: <Router_IP_address>, server: <HostAlias>, request: "PUT <BasePath> HTTP/1.1", upstream: "http://<ListOfMP-IP_R-MP-Port>/<BasePath>", host: "<HostAlias>"

Cenário 1: todos os processadores de mensagens estão desativados

  1. Verifique se os processadores de mensagens na região/data center específico estão em execução.
  2. Se todos os processadores de mensagens estiverem inativos, reinicie-os.

Resolução

Reinicie todos os processadores de mensagens usando o seguinte comando:

/opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart

Cenário 2: todos os processadores de mensagens estão ocupados processando solicitações em andamento

Esse erro ocorrerá se os roteadores descobrirem que todos os processadores de mensagens em uma determinada região/data center estão indisponíveis, já que estão ocupados processando solicitações em andamento.

  1. Verifique se os processadores de mensagens na região/data center específico estão em execução.
  2. Se todos os processadores de mensagens estiverem ativos e ativos, verifique se eles estão apresentando um alto uso da CPU. Em seguida, gere três despejos de linha de execução a cada 30 segundos usando o seguinte comando:
    <JAVA_HOME>/bin/jstack -l <pid> > <filename>
  3. Se os processadores de mensagens estiverem apresentando um alto uso de memória, gere um heap dump com o seguinte comando:
    sudo -u apigee /bin/jmap -dump:live,format=b,file=
  4. 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
  5. Monitore as chamadas de API para confirmar se o problema ainda existe.
  6. Entre em contato com o suporte da Apigee e envie os despejos de linha de execução, o heap dump e os registros do processador de mensagens (/opt/apigee/var/log/edge-message-processor/logs/system.log) para investigar a causa do alto uso de CPU/memória.

Causa: configuração de SSL incorreta entre roteadores e MPs

Diagnóstico

  1. Verifique os registros de acesso do NGINX (/opt/apigee/var/log/edge-router/nginx/ORG-Env._access_log). Você verá a resposta 502, conforme mostrado abaixo:
        2019-07-23T12:13:42+03:00	sc-10-254-226-23	10.X.X.X:53634	10.X.X.X:8998	0.000	-	-	502	502	189	344	GET <path> curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.27.1 zlib/1.2.3 libidn/1.18 libssh2/1.4.2	<host alias>	mp-10-254-226-23-23706-8552529-1	10.129.107.101	-	-	-1	-	-	dc-2	gateway-2	green	-	gateway-2	dc-2	op	pilot	http	-
  2. Verifique os registros de erro do NGINX (/opt/apigee/var/log/edge-router/nginx/ORG-Env._error_log). Erros como estes:
    	2019/07/30 17:02:24 [error] 7691#7691: *11753633 peer closed connection in SSL handshake while SSL handshaking to upstream, client: X.X.X.X, server: <HostAlias>, request: "GET /no-target HTTP/1.1", upstream: "https://X.X.X.X:8998/no-target", host: "<HostAlias>"
  3. Isso mostra que o handshake de SSL falha entre o roteador e o processador de mensagens.
  4. Se você perceber cuidadosamente na mensagem de erro nas etapas 1 e 2, o número da porta usada para se comunicar com o processador de mensagens é 8998, que é uma porta não segura, mas o protocolo é SSL (https). Geralmente, o número da porta segura usada é 8443. Como uma porta não segura é usada para uma comunicação segura, ela causa a falha de handshake de SSL.
  5. Normalmente, isso pode acontecer se você perdeu alguma etapa ou definiu valores incorretos ao configurar o SSL entre o roteador e o processador de mensagens. Consulte as etapas descritas aqui.
    Por exemplo, esse erro poderá ocorrer se
    1. A porta no está especificada como 8998 em vez de 8443 em /opt/apigee/customer/application/message-processor.properties as shown below
              conf/message-processor-communication.properties+local.http.port=8998
    2. Os arquivos de configuração do roteador no diretório /opt/nginx/conf.d/* não serão excluídos, e o roteador não foi reiniciado durante a configuração do SSL. Nesse cenário, o número da porta dos processadores de mensagens permanece 8998 nos arquivos de configuração.

Resolução

  1. Siga todas as etapas descritas em Configurar TLS entre um roteador e um processador de mensagens (em inglês) corretamente.
  2. Se o problema persistir, acesse Coletar informações de diagnóstico.

Causa: erro do servidor de back-end

Diagnóstico

  1. Se o erro ocorrer todas as vezes, será possível capturar o rastreamento da interface das solicitações com falha. Selecione uma solicitação com falha e navegue pelas várias fases no trace. Se você receber a mensagem "502 Gateway inválido" do próprio servidor de back-end, é possível que uma falha tenha acontecido no servidor de back-end.
    Rastro mostrando 502 Gateway inválido proveniente do servidor de back-end
  2. Se o problema for intermitente e não for possível capturar o rastro,
    1. Se você usa a nuvem pública, use a API Monitoring e verifique os detalhes dos erros 502.
      1. Se você observar que o código da falha é messaging.adaptors.http.flow.ErrorResponseCode e a origem da falha é target, o erro é causado pelo servidor de back-end.
    2. Se você for usuário da nuvem privada, poderá analisar os registros de acesso do NGINX
      /opt/apigee/var/log/edge-router/nginx/ORG-Env._access_log.
      Será exibida a entrada da solicitação com falha da seguinte forma:
      2017-02-24T14:42:12+00:00	rt-01	192.8.155.2:18118	192.168.84.166:8998	10.225	-	-	502	502	440	0	GET /adv-eadlg-test/documents?type=doctype HTTP/1.1	rt-02efawae234-1234	Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36	myorg-dev.apigee.net	 rt-02efawae234-1234	6	-	false	target	messaging.adaptors.http.flow.ErrorResponseCode	null/null	-	/organizations/myorg/environments/dev/apiproxies/api123
      1. Se você observar que o código da falha é messaging.adaptors.http.flow.ErrorResponseCode e a origem da falha é target, o erro é causado pelo servidor de back-end.

Resolução

  1. Trabalhe com a equipe do servidor de back-end para corrigir esse problema.

Coletar informações de diagnóstico

  1. Registros de acesso do NGINX
    (/opt/apigee/var/log/edge-router/nginx/ORG-Env._access_log)
    e registros de erros
    (/opt/apigee/var/log/edge-router/nginx/ORG-Env._error_log).
  2. Registros do processador de mensagens
    /opt/apigee/var/log/edge-message-processor/logs/system.log).