503 Serviço indisponível - fechamento prematuro pelo servidor de back-end

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

Sintoma

O aplicativo cliente recebe um status de resposta HTTP 503 com a mensagem Service Unavailable após uma chamada de proxy de API.

Mensagem de erro

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

HTTP/1.1 503 Service Unavailable

Além disso, você poderá encontrar a seguinte mensagem de erro:

{
   "fault": {
      "faultstring": "The Service is temporarily unavailable",
      "detail": {
           "errorcode": "messaging.adaptors.http.flow.ServiceUnavailable"
       }
    }
}

Causas possíveis

Causa	Descrição	Instruções de solução de problemas aplicáveis para
O servidor de destino encerra a conexão prematuramente	O servidor de destino encerra prematuramente a conexão enquanto o processador de mensagens ainda está enviar o payload da solicitação.	Usuários de nuvem pública e privada de borda

Etapas comuns do diagnóstico

Determinar o ID da mensagem da solicitação com falha

Causa: o servidor de destino fecha prematuramente a conexão

Diagnóstico

1. Se você for usuário de nuvem pública ou nuvem privada:
   1. Usar a ferramenta Trace (conforme explicado nas Etapas comuns de diagnóstico) e verifique se você tem os dois conjuntos a seguir no painel Dados do Analytics registrados:
      • X-Apigee.fault-code: messaging.adaptors.http.flow.ServiceUnavailable
      • X-Apigee.fault-source: target

      

   2. Usar a ferramenta Trace (conforme explicado nas Etapas comuns de diagnóstico) e verifique se você tem ambos os itens a seguir definidos no painel Erro imediatamente após a propriedade state TARGET_REQ_FLOW:
      • error.class::com.apigee.errors.http.server.ServiceUnavailableException
      • error.cause: Broken pipe

      

   3. Acesse Como usar o tcpdump para mais detalhes.
2. Se você é usuário de nuvem privada:
   • Determine o ID da mensagem da solicitação com falha.
   • Pesquisar o ID da mensagem no registro do processador de mensagens (/opt/apigee/var/log/edge-message-processor/logs/system.log).
   • Você verá uma das seguintes exceções:

     Exceção 1: java.io.IOException: ocorreu um pipe corrompido ao gravar no canal ClientOutputChannel

     2021-01-30 15:31:14,693 org:anotherorg env:prod api:myproxy
     rev:1 messageid:myorg-opdk-test-1-30312-13747-1  NIOThread@1
     INFO  HTTP.SERVICE - ExceptionHandler.handleException() :
     Exception java.io.IOException: Broken pipe occurred while writing to channel
     ClientOutputChannel(ClientChannel[Connected:
     Remote:IP:PORT Local:0.0.0.0:42828]@8380 useCount=1
     bytesRead=0 bytesWritten=76295 age=2012ms  lastIO=2ms  isOpen=false)
     

     ou

     Exceção 2: exceção onExceptionWrite: {}
     java.io.IOException: pipeline corrompido

     2021-01-31 15:29:37,438 org:anotherorg env:prod api:503-test
     rev:1 messageid:leonyoung-opdk-test-1-18604-13978-1
     NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context$2.onException() :
     ClientChannel[Connected: Remote:IP:PORT
     Local:0.0.0.0:57880]@8569 useCount=1 bytesRead=0 bytesWritten=76295 age=3180ms  lastIO=2
     ms  isOpen=false.onExceptionWrite exception: {}
     java.io.IOException: Broken pipe
     

   • Essas duas exceções indicam que, enquanto o processador de mensagens ainda estava gravando o payload de solicitação ao servidor de back-end, a conexão foi encerrada prematuramente pelo servidor de back-end. Portanto, o processador de mensagens gera a exceção java.io.IOException: Broken pipe.
   • Remote:IP:PORT indica o servidor de back-end resolvido o endereço IP e o número da porta.
   • O atributo bytesWritten=76295 na mensagem de erro acima indica que o processador de mensagens enviou um payload de 76295 bytes para o back-end ao servidor quando a conexão foi encerrada prematuramente.
   • O atributo bytesRead=0 indica que o processador de mensagens não receberam quaisquer dados (resposta) do servidor de back-end.
   • Para investigar mais o problema, colete um tcpdump no back-end ou processador de mensagens e analisá-lo conforme explicado abaixo.

Como usar o tcpdump

1. Capture uma tcpdump no servidor de back-end ou no processador de mensagens com estes comandos:

   Comando para coletar tcpdump no servidor de back-end:

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

   Comando para coletar tcpdump no processador de mensagens:

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

2. Analise a tcpdump capturada:

   Exemplo de resposta do tcpdump (coletada no processador de mensagens):

   

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

   1. No pacote 4, o processador de mensagens enviou uma solicitação POST para no servidor de back-end.
   2. No pacote 5, 8, 9, 10, 11, o processador de mensagens continuou a enviar o payload da solicitação para o servidor de back-end.
   3. Nos pacotes 6 e 7,o servidor de back-end respondeu com ACK para uma parte do payload de solicitação recebida do processador de mensagens.
   4. No entanto, no pacote 12, em vez de responder com uma ACK dos pacotes de dados de aplicativos recebidos e subsequentemente respondendo com a resposta payload, o servidor de back-end responde com um FIN ACK iniciando o encerramento da conexão.
   5. Isso mostra claramente que o servidor de back-end está fechando a conexão prematuramente. enquanto o processador de mensagens ainda estava enviando a carga útil da solicitação.
   6. Isso faz com que o processador de mensagens grave um IOException: Broken Pipe. e retornam um 503 ao cliente.

Resolução

1. Trabalhe com uma ou ambas as equipes de aplicativo e rede para analisar e corrigir o de desconexões prematuras no lado do servidor de back-end.
2. Verifique se o aplicativo de servidor de back-end não está expirando ou redefinindo a conexão antes de receber todo o payload da solicitação.
3. Se você tiver um dispositivo de rede ou camada intermediária entre a Apigee e o servidor de back-end, Verifique se eles não expiram antes que toda a carga útil da solicitação seja recebida.

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

É 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 503.
• Arquivo de rastreamento que contém a solicitação com o erro 503 Service Unavailable
• Se os erros 503 não estiverem ocorrendo atualmente, forneça o período com as informações de fuso horário quando erros 503 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 503 erro
• Pacote de proxy de API
• Arquivo de rastreamento contendo as solicitações com o erro 503 Service Unavailable
• 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 503 ocorreram
• Tcpdumps são reunidas nos processadores de mensagens e no servidor de back-end quando a ocorreu um erro