502 Bad Gateway

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 502 com a mensagem "Bad Gateway" como resposta para chamadas de API.

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

Mensagens de erro

O aplicativo cliente recebe este código de resposta:

HTTP/1.1 502 Bad Gateway

Além disso, talvez você veja 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 assim. A mensagem de erro do back-end depende completamente da implementação dele. 

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

Causas possíveis

Confira algumas causas que podem levar ao erro 502 Bad Gateway para APIs que passam pelo Apigee Edge:

Causa Descrição Instruções de solução de problemas aplicáveis a
Não há MPs disponíveis no pool Esse erro é observado se todos os MPs do grupo estiverem indisponíveis, ou seja, se estiverem inativos ou ocupados e, portanto, não estão respondendo. Usuários da nuvem privada do Edge
Configuração de SSL incorreta entre roteadores e MPs Esse erro é 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 da nuvem pública e privada do Edge

Causa: nenhum MP disponível no pool

Esse erro ocorrerá se o roteador descobrir que todos os processadores de mensagens de 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 (solicitações) de API de entrada em uma determinada região/data center seja sempre roteado dos roteadores para os processadores de mensagens (MPs) na mesma região/data center. Em alguns casos, os componentes do Apigee Edge podem ser configurados em apenas uma região/data center e, em alguns casos, 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/data centers em que as solicitações de API estão falhando com o erro 502 Bad Gateway, se houver mais de uma região/data center. Para encontrar esse código, 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 diferentes regiões.
  2. Você verá o seguinte erro nos registros de erro 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 inativos

  1. Verifique se os processadores de mensagens da região/data center específicos 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

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

  1. Verifique se os processadores de mensagens da região/data center específicos estão em execução.
  2. Se todos os processadores de mensagens estiverem ativos e ativos, verifique se eles estão com alto uso de 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 o processador de mensagens estiver com alto uso de memória, gere um heap dump com este comando:
    sudo -u apigee /bin/jmap -dump:live,format=b,file=
  4. 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
  5. Monitore as chamadas de API para confirmar se o problema ainda persiste.
  6. Entre em contato com o suporte da Apigee e envie os registros de Thread dumps, heap dump e 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 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, como 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). Você verá 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ê observar 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). Normalmente, o número da porta segura usada é 8443. Como uma porta não segura é usada para comunicação segura, ela causa a falha de handshake de SSL.
  5. Normalmente, isso pode acontecer se você tiver esquecido alguma etapa ou tiver definido valores incorretos ao configurar o SSL entre o roteador e o processador de mensagens. Consulte as etapas descritas aqui.
    Por exemplo, este erro poderá ocorrer se
    1. O número da porta é especificado 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 foram excluídos e o roteador não foi reiniciado durante a configuração SSL. Neste cenário, observe que o número da porta dos processadores de mensagens permanecerá como 8998 nos arquivos de configuração.

Resolução

  1. Certifique-se de que todas as etapas fornecidas em Como configurar o TLS entre um roteador e um processador de mensagens foram seguidas 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 rastro da interface das solicitações com falha. Selecione uma solicitação com falha e navegue pelas várias fases no rastro. Se você perceber que recebeu o erro "502 Bad Gateway" do próprio servidor de back-end, talvez o problema tenha acontecido porque alguma falha pode ter acontecido no servidor de back-end.
    Rastreamento mostrando 502 gateway inválido vindo do servidor de back-end
  2. Se o problema for intermitente e não for possível capturar o rastro,
    1. Se você é um usuário de nuvem pública, use o API Monitoring e verifique os detalhes dos erros 502.
      1. Se você observar que o código de falha é messaging.adaptors.http.flow.ErrorResponseCode e a origem da falha é target, o erro é causado pelo servidor de back-end.
    2. Se você for um usuário da nuvem privada, poderá analisar os registros de acesso do NGINX.
      /opt/apigee/var/log/edge-router/nginx/ORG-Env._access_log.
      Você verá a entrada da solicitação com falha da seguinte maneira:
      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 de 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 no back-end.

Coletar informações de diagnóstico

  1. Registros de acesso do NGINX
    (/opt/apigee/var/log/edge-router/nginx/ORG-Env._access_log)
    e 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).