502 Gateway inválido EOF inesperado

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 502 com a mensagem Bad Gateway 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 a seguinte mensagem de erro:

{
   "fault": {
      "faultstring": "Unexpected EOF at target",
      "detail": {
           "errorcode": "messaging.adaptors.http.UnexpectedEOFAtTarget"
       }
    }
}

Causas possíveis

Uma das causas típicas da 502 Bad Gateway Error é Unexpected EOF que pode ser causado pelos seguintes motivos:

Etapas comuns do diagnóstico

Para diagnosticar o erro, é possível usar qualquer um dos seguintes métodos:

• Monitoramento de APIs
• Ferramenta de rastreamento
• Registros de acesso do NGINX

Causa: servidor de destino configurado incorretamente

O servidor de destino não está configurado corretamente para oferecer suporte a conexões TLS/SSL.

Diagnóstico

1. Use o Monitoramento de API, a Ferramenta de rastreamento ou Registros de acesso do NGINX para determinar o ID da mensagem, código e origem do erro 502.
2. Ative o rastreamento na interface da API afetada.
3. Se o trace da solicitação de API com falha mostrar o seguinte:
   1. O erro 502 Bad Gateway é exibido assim que a solicitação de fluxo de destino é iniciada.
   2. O error.class mostra messaging.adaptors.http.UnexpectedEOF..

      Então, é muito provável que esse problema seja causado por um servidor de destino incorreto configuração do Terraform.

4. Consiga a definição do servidor de destino usando a chamada da API Edge Management:
   1. Se você for um usuário da nuvem pública, use esta API:

      curl -v https://api.enterprise.apigee.com/v1/organizations/<orgname>/environments/<envname>/targetservers/<targetservername> -u <username>

   2. Se você for um usuário da nuvem privada, use esta API:

      curl -v http://<management-server-host>:<port #>/v1/organizations/<orgname>/environments/<envname>/targetservers/<targetservername> -u <username>

      Exemplo de definição de TargetServer com erros:

      <TargetServer  name="target1">
        <Host>mocktarget.apigee.net</Host>
        <Port>443</Port>
        <IsEnabled>true</IsEnabled>
      </TargetServer >

5. A definição ilustrada de TargetServer é um exemplo de uma das de configuração do Terraform, o que é explicado a seguir:

   Vamos supor que o servidor de destino mocktarget.apigee.net esteja configurado. para aceitar conexões seguras (HTTPS) na porta 443. No entanto, se você observar a definição do servidor de destino, não existem outros atributos/sinalizações que indicam que ele é destinadas a conexões seguras. Isso faz com que o Edge trate as solicitações de API que vão para o servidor de destino específico como solicitações HTTP (não seguras). Portanto, o Edge não vai inicie o processo de handshake de SSL com esse servidor de destino.

   Como o servidor de destino está configurado para aceitar somente solicitações HTTPS (SSL) em 443, ele rejeitar a solicitação do Edge ou encerrar a conexão; Como resultado, você recebe um UnexpectedEOFAtTarget erro no processador de mensagens. O processador de mensagens enviará 502 Bad Gateway como resposta ao cliente.

Resolução

Sempre verifique se o servidor de destino está configurado corretamente de acordo com seus requisitos.

No exemplo ilustrado acima, se você quiser fazer solicitações para um destino seguro (HTTPS/SSL) servidor, é necessário incluir os atributos SSLInfo com a flag enabled definida para true. Embora seja permitido adicionar os atributos SSLInfo para um servidor de destino na a definição do endpoint, recomendamos adicionar os atributos SSLInfo como parte do destino a definição do servidor para evitar confusão.

1. Se o serviço de back-end exigir comunicação SSL unidirecional:
   1. É necessário ativar o TLS/SSL na definição de TargetServer incluindo o SSLInfo. atributos em que a flag enabled está definida como verdadeira, conforme mostrado abaixo:

      <TargetServer name="mocktarget">
        <Host>mocktarget.apigee.net</Host>
        <Port>443</Port>
        <IsEnabled>true</IsEnabled>
        <SSLInfo>
            <Enabled>true</Enabled>
        </SSLInfo>
      </TargetServer>

   2. Se você quiser validar o certificado do servidor de destino no Edge, também será necessário inclua o truststore (contendo o certificado do servidor de destino) conforme mostrado abaixo:

      <TargetServer  name="mocktarget">
          <Host>mocktarget.apigee.net</Host>
          <Port>443</Port>
          <IsEnabled>true</IsEnabled>
          <SSLInfo>
              <Ciphers/>
              <ClientAuthEnabled>false</ClientAuthEnabled>
              <Enabled>true</Enabled>
              <IgnoreValidationErrors>false</IgnoreValidationErrors>
              <Protocols/>
              <TrustStore>mocktarget-truststore</TrustStore>
          </SSLInfo>
      </TargetServer>

2. Se o serviço de back-end exigir comunicação SSL bidirecional:
   1. É preciso ter atributos SSLInfo com ClientAuthEnabled. Keystore, KeyAlias e As flags Truststore são definidas corretamente, conforme mostrado abaixo:

      <TargetServer  name="mocktarget">
           <IsEnabled>true</IsEnabled>
           <Host>www.example.com</Host>
           <Port>443</Port>
           <SSLInfo>
               <Ciphers/>
               <ClientAuthEnabled>true</ClientAuthEnabled>
               <Enabled>true</Enabled>
               <IgnoreValidationErrors>false</IgnoreValidationErrors>
               <KeyAlias>keystore-alias</KeyAlias>
               <KeyStore>keystore-name</KeyStore>
               <Protocols/>
               <TrustStore>truststore-name</TrustStore>
           </SSLInfo>
        </TargetServer >

Referências

Balanceamento de carga em servidores de back-end

Causa: EOFException do servidor de back-end

O servidor de back-end pode enviar EOF (fim do arquivo) abruptamente.

Diagnóstico

1. Use o Monitoramento de API, a Ferramenta de rastreamento ou Registros de acesso do NGINX para determinar o ID da mensagem, código e origem do erro 502.
2. Verificar os registros do processador de mensagens (/opt/apigee/var/log/edge-message-processor/logs/system.log) e pesquise tem eof unexpected para a API específica ou se você tem o messageid exclusivo para a API; de pesquisa, você poderá pesquisá-lo.

   Exemplo de stack trace de exceção do registro do processador de mensagens

   "message": "org:myorg env:test api:api-v1 rev:10 messageid:rrt-1-14707-63403485-19 NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context$3.onException() : SSLClientChannel[C:193.35.250.192:8443 Remote host:0.0.0.0:50100]@459069 useCount=6 bytesRead=0 bytesWritten=755 age=40107ms lastIO=12832ms .onExceptionRead exception: {}
   java.io.EOFException: eof unexpected
   at com.apigee.nio.channels.PatternInputChannel.doRead(PatternInputChannel.java:45) ~[nio-1.0.0.jar:na]
   at com.apigee.nio.channels.InputChannel.read(InputChannel.java:103) ~[nio-1.0.0.jar:na]
   at com.apigee.protocol.http.io.MessageReader.onRead(MessageReader.java:79) ~[http-1.0.0.jar:na]
   at com.apigee.nio.channels.DefaultNIOSupport$DefaultIOChannelHandler.onIO(NIOSupport.java:51) [nio-1.0.0.jar:na]
   at com.apigee.nio.handlers.NIOThread.run(NIOThread.java:123) [nio-1.0.0.jar:na]"

   No exemplo acima, é possível ver que o erro java.io.EOFException: eof unexpected ocorreu enquanto o processador de mensagens tenta ler uma resposta do no servidor de back-end. Essa exceção indica que o fim do arquivo (EOF, na sigla em inglês) ou o fim do fluxo tenha sido atingido inesperadamente.

   Ou seja, o processador de mensagens enviou a solicitação de API para o servidor de back-end e estava aguardando ou ler a resposta. No entanto, o servidor de back-end encerrou a conexão abruptamente antes que o processador de mensagens recebesse a resposta ou pudesse ler a resposta completa.

3. Verifique os registros do servidor de back-end e veja se há erros ou informações que possam levaram o servidor de back-end a encerrar a conexão abruptamente. Se você encontrar erros/informações, e acesse Resolução. e corrija o problema no servidor de back-end.
4. Se você não encontrar erros ou informações no servidor de back-end, colete a saída tcpdump nos processadores de mensagens:
   1. Se o host do servidor de back-end tiver um único endereço IP, use o seguinte comando:

      tcpdump -i any -s 0 host IP_ADDRESS -w FILE_NAME

   2. Se o host do servidor de back-end tiver vários endereços IP, use o seguinte comando:

      tcpdump -i any -s 0 host HOSTNAME -w FILE_NAME

      Normalmente, esse erro é causado porque o servidor de back-end responde com [FIN,ACK] assim que o processador de mensagens enviar a solicitação ao servidor de back-end.

5. Considere o exemplo de tcpdump a seguir.

   Amostra de tcpdump tirada quando 502 Bad Gateway Error (UnexpectedEOFAtTarget) ocorreu

   

6. Na saída de TCPDump, você observa a seguinte sequência de eventos:
   1. No pacote 985, o processador de mensagens envia a solicitação de API ao servidor de back-end.
   2. No pacote 986, o servidor de back-end responde imediatamente com [FIN,ACK].
   3. No pacote 987, o processador de mensagens responde com [FIN,ACK] ao back-end. servidor.
   4. Eventualmente, as conexões serão fechadas com [ACK] e [RST] em ambos os lados.
   5. Como o servidor de back-end envia [FIN,ACK], você recebe a exceção Exceção java.io.EOFException: eof unexpected na mensagem Processador
7. Isso poderá acontecer se houver um problema de rede no servidor de back-end. Envolva sua rede de operações para investigar esse problema mais a fundo.

Resolução

Corrija o problema no servidor de back-end corretamente.

Se o problema persistir e você precisar de ajuda para solucionar o problema, 502 Bad Gateway Error ou você suspeita que seja um problema no Edge, entre em contato com o suporte do Apigee Edge.

Causa: tempo limite de sinal de atividade configurado incorretamente

Antes de diagnosticar se essa é a causa dos erros 502, leia os conceitos a seguir.

Conexões permanentes na Apigee

Por padrão, a Apigee (e a seguir com o padrão HTTP/1.1) usa conexões permanentes. ao se comunicar com o servidor de back-end de destino. Conexões persistentes podem aumentar o desempenho permitindo que uma conexão TCP e TLS/SSL já estabelecida (se aplicável) seja reutilizada, o que e reduzir as sobrecargas de latência. A duração da persistência de uma conexão é controlada usando um tempo limite de sinal de atividade (keepalive.timeout.millis) de uma propriedade.

O servidor de back-end e o processador de mensagens da Apigee usam tempos limite de sinal de atividade para manter conexões se abrem umas com as outras. Quando nenhum dado for recebido dentro do tempo limite do sinal de atividade duração, o servidor de back-end ou o processador de mensagens pode encerrar a conexão com o outro.

Por padrão, os proxies de API implantados em um processador de mensagens na Apigee têm um tempo limite de sinal de atividade definido como 60s, a menos que seja substituído. Quando nenhum dado for recebido para 60s, a Apigee encerre a conexão com o servidor de back-end. O servidor de back-end também mantém um tempo limite de sinal de atividade, e, assim que expirar, o servidor de back-end encerra a conexão com o processador de mensagens.

Implicação da configuração incorreta de tempo limite de sinal de atividade

Se a Apigee ou o servidor de back-end estiverem configurados com tempos limite de sinal de atividade incorretos, resulta em uma disputa que faz com que o servidor de back-end envie um End Of File (FIN) inesperado em resposta a uma solicitação de recurso.

Por exemplo, se o tempo limite de sinal de atividade for configurado no proxy de API ou no Processador com um valor maior ou igual ao tempo limite do servidor de back-end upstream, depois a seguinte disputa pode ocorrer. Ou seja, se o processador de mensagens não receber até que muito próximo do limite do tempo limite de atividade de back-end do servidor de back-end, então uma solicitação é recebido e enviada ao servidor de back-end usando a conexão atual. Isso pode levar a 502 Bad Gateway devido a um erro EOF inesperado, conforme explicado abaixo:

1. Digamos que o tempo limite de sinal de atividade foi definido no processador de mensagens e no servidor de back-end é de 60 segundos e não é nova solicitação veio até 59 segundos depois que a solicitação anterior foi atendida pelo Processador de mensagens
2. O processador de mensagens processa a solicitação que chegou aos 59 segundos usando a conexão existente (já que o tempo limite de sinal de atividade ainda não expirou) e envia o ao servidor de back-end.
3. No entanto, antes que a solicitação chegue ao servidor de back-end, o tempo limite de sinal de atividade o limite foi excedido no servidor de back-end.
4. A solicitação do processador de mensagens para um recurso está em andamento, mas o servidor de back-end tenta encerrar a conexão enviando um pacote FIN para o servidor da Processador
5. Enquanto o processador de mensagens aguarda o recebimento dos dados, em vez disso, ele recebe o FIN inesperado e a conexão é encerrada.
6. Isso resulta em uma Unexpected EOF e, em seguida, uma 502 é retornados ao cliente pelo processador de mensagens.

Nesse caso, observamos que o erro 502 ocorreu porque o mesmo tempo limite de sinal de atividade foi atingido. de 60 segundos foi configurado no processador de mensagens e no servidor de back-end. Da mesma forma, Esse problema também poderá acontecer se um valor mais alto for configurado para o tempo limite de sinal de atividade que está no servidor de back-end.

Diagnóstico

1. Se você for usuário da nuvem pública:
   1. Use a ferramenta Trace ou API Monitoring (conforme explicado em etapas comuns de diagnóstico) e confirme se você atende a uma das opções abaixo configurações:
      • Código de falha:messaging.adaptors.http.flow.UnexpectedEOFAtTarget
      • Origem da falha:target
   2. Acesse Como usar o tcpdump para mais detalhes.
2. Se você é usuário da nuvem privada:
   1. Use a ferramenta Trace ou Registros de acesso do NGINX para determinar o ID da mensagem, código e origem do erro 502.
   2. Pesquisar o ID da mensagem no registro do processador de mensagens
      (/opt/apigee/var/log/edge-message-processor/logs/system.log).
   3. Você verá o java.io.EOFEXception: eof unexpected conforme mostrado abaixo:

      2020-11-22 14:42:39,917 org:myorg env:prod api:myproxy rev:1 messageid:myorg-opdk-dc1-node2-17812-56001-1  NIOThread@1 ERROR HTTP.CLIENT - HTTPClient$Context$3.onException() :  ClientChannel[Connected: Remote:51.254.225.9:80 Local:10.154.0.61:35326]@12972 useCount=7 bytesRead=0 bytesWritten=159 age=7872ms  lastIO=479ms  isOpen=true.onExceptionRead exception: {}
              java.io.EOFException: eof unexpected
              at com.apigee.nio.channels.PatternInputChannel.doRead(PatternInputChannel.java:45)
              at com.apigee.nio.channels.InputChannel.read(InputChannel.java:103)
              at com.apigee.protocol.http.io.MessageReader.onRead(MessageReader.java:80)
              at com.apigee.nio.channels.DefaultNIOSupport$DefaultIOChannelHandler.onIO(NIOSupport.java:51)
              at com.apigee.nio.handlers.NIOThread.run(NIOThread.java:220)

   4. O erro java.io.EOFException: eof unexpected indica que o O processador de mensagens recebeu um EOF enquanto ainda estava esperando a leitura de uma do servidor de back-end.
   5. O atributo useCount=7 na mensagem de erro acima indica que o O processador de mensagens reutilizou essa conexão cerca de sete vezes, e o atributo bytesWritten=159 indica que o processador de mensagens enviou a solicitação. payload de 159 bytes para o servidor de back-end. Mas não recebeu nenhum byte quando a EOF inesperada ocorreu.

   6. Isso mostra que o processador de mensagens reutilizou a mesma conexão várias vezes, Nesse caso, ele enviou dados, mas logo depois recebeu uma mensagem EOF antes que os dados fossem recebidos. Isso significa que há uma alta probabilidade de que o back-end o tempo limite de sinal de atividade do servidor for menor ou igual ao definido no proxy de API.

      Você pode investigar mais detalhadamente com a ajuda de tcpdump, conforme explicado abaixo.

Como usar o tcpdump

1. Capture um tcpdump no servidor de back-end com o seguinte comando:

   tcpdump -i any -s 0 host MP_IP_Address -w File_Name

2. Analise a tcpdump capturada:

   Confira um exemplo de resposta do tcpdump:

   

   No tcpdump de exemplo acima, é possível ver o seguinte:

   1. No pacote 5992,, o servidor de back-end recebeu uma solicitação GET.
   2. No pacote 6064, ele responde com 200 OK..
   3. No pacote 6084, o servidor de back-end recebeu outra solicitação GET.
   4. No pacote 6154, ele responde com 200 OK.
   5. No pacote 6228, o servidor de back-end recebeu uma terceira solicitação GET.
   6. Desta vez, o servidor de back-end retorna um FIN, ACK para o processador de mensagens. (pacote 6285) iniciando o fechamento da conexão.

   A mesma conexão foi reutilizada duas vezes neste exemplo, mas na terceira solicitação, o servidor de back-end inicia o encerramento da conexão, enquanto o processador de mensagens aguardando os dados do servidor de back-end. Isso sugere que o servidor de back-end o tempo limite de atividade provavelmente será menor ou igual ao valor definido no proxy de API. Para validar Para isso, consulte Comparar o tempo limite de sinal de atividade na Apigee e no servidor de back-end.

Comparar o tempo limite de sinal de atividade na Apigee e no servidor de back-end

1. Por padrão, a Apigee usa um valor de 60 segundos para a propriedade de tempo limite de sinal de atividade.

2. No entanto, é possível que você tenha substituído o valor padrão no proxy de API. Para confirmar isso, confira a definição específica de TargetEndpoint no arquivo um proxy de API com falha que está fornecendo erros 502.

   Exemplo de configuração do TargetEndpoint:

   <TargetEndpoint name="default">
     <HTTPTargetConnection>
       <URL>https://mocktarget.apigee.net/json</URL>
       <Properties>
         <Property name="keepalive.timeout.millis">30000</Property>
       </Properties>
     </HTTPTargetConnection>
   </TargetEndpoint>

   No exemplo acima, a propriedade de tempo limite de sinal de atividade foi substituída por um valor de 30 segundos (30000 milissegundos).

3. Em seguida, verifique a propriedade de tempo limite de sinal de atividade configurada no servidor de back-end. Digamos que seu servidor de back-end está configurado com um valor de 25 seconds;
4. Se você determinar que o valor da propriedade de tempo limite de sinal de atividade na Apigee é maior que o valor da propriedade de tempo limite de sinal de atividade no servidor de back-end, como acima exemplo, essa é a causa dos erros 502.

Resolução

Certifique-se de que a propriedade de tempo limite de sinal de atividade seja sempre menor na Apigee (no proxy de API e Processador de mensagens) em comparação com o servidor de back-end.

1. Determine o valor definido para o tempo limite de sinal de atividade no servidor de back-end.
2. Configure um valor apropriado para a propriedade de tempo limite de sinal de atividade no proxy de API ou Processador de mensagens, de modo que a propriedade de tempo limite de sinal de atividade seja menor que o valor definido no de back-end da Web usando as etapas descritas em Como configurar o tempo limite de sinal de atividade em processadores de mensagens.

Se o problema persistir, acesse Precisa de informações de diagnóstico.

Prática recomendada

É altamente recomendável que os componentes downstream tenham sempre um tempo limite de sinal de atividade menor do que o configurado nos servidores upstream para evitar esses tipos de condições de corrida e 502 erro. Cada salto downstream precisa ser menor que cada salto upstream. Na Apigee é uma boa prática usar as seguintes diretrizes:

1. O tempo limite de sinal de atividade do cliente deve ser menor que o tempo limite de sinal de atividade do roteador de borda.
2. O tempo limite de sinal de atividade do roteador de borda deve ser menor que o tempo limite de atividade do processador de mensagens.
3. O tempo limite de sinal de atividade do processador de mensagens deve ser menor que o tempo limite de sinal de atividade do servidor de destino.
4. Se você tiver outros saltos na frente ou atrás da Apigee, a mesma regra precisará ser aplicada. Você deve sempre deixar como responsabilidade do cliente downstream encerrar o com o upstream.

É necessário coletar informações de diagnóstico

Se o problema persistir mesmo depois de seguir as instruções acima, colete as seguintes informações: informações de diagnóstico e entre em contato com o suporte do Apigee Edge.

Se você for um usuário da nuvem pública, forneça as seguintes informações:

• Nome da organização
• Nome do ambiente
• Nome do proxy da API
• Conclua o comando curl para reproduzir o erro 502.
• Arquivo de rastreamento contendo as solicitações com o erro 502 Bad Gateway - Unexpected EOF
• Se os erros 502 não estiverem ocorrendo atualmente, forneça o período com as informações de fuso horário quando erros 502 ocorreram no passado.

Se você for um usuário da nuvem privada, forneça estas informações:

• Mensagem de erro completa observada para as solicitações com falha
• Organização, nome do ambiente e nome do proxy da API que você está observando 502 erro
• Pacote de proxy de API
• Arquivo de rastreamento contendo as solicitações com o erro 502 Bad Gateway - Unexpected EOF
• Registros de acesso do NGINX
  /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log
• Registros do processador de mensagens
  /opt/apigee/var/log/edge-message-processor/logs/system.log
• O período com as informações de fuso horário em que os erros 502 ocorreram
• Tcpdumps coletadas nos processadores de mensagens, no servidor de back-end ou em ambos quando o erro ocorreu