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

Você está vendo a documentação do Apigee Edge.
Acesse a 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 este código de resposta: 

HTTP/1.1 503 Service Unavailable

Além disso, talvez você veja 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 a conexão prematuramente enquanto o processador de mensagens ainda está enviando o payload da solicitação. Usuários de nuvens públicas e privadas de borda

Etapas comuns do diagnóstico

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

Ferramenta de rastreamento

Para determinar o ID da mensagem da solicitação com falha usando a ferramenta Trace:

  1. Se o problema ainda estiver ativo, ative a sessão de rastreamento para a API afetada.
  2. Faça a chamada de API e reproduza o problema: 503 Service Unavailable com o código do erro messaging.adaptors.http.flow.ServiceUnavailable..
  3. Selecione uma das solicitações com falha.
  4. Navegue até a fase AX e determine o ID da mensagem (X-Apigee.Message-ID) da solicitação rolando para baixo na seção Phase Details, conforme mostrado na figura a seguir.

    ID da mensagem na seção "Detalhes da fase"

Registros de acesso do NGINX

Para determinar o código da mensagem da solicitação com falha usando os registros de acesso do NGINX:

Também é possível consultar os registros de acesso do NGINX para determinar o ID da mensagem dos erros 503. Isso é particularmente útil se o problema tiver ocorrido no passado ou se ele for intermitente e você não conseguir capturar o rastro na IU. Siga estas etapas para determinar essas informações dos registros de acesso do NGINX:

  1. Verifique os registros de acesso do NGINX: (/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log)
  2. Pesquise se há erros 503 para o proxy de API específico durante um período específico (se o problema tiver acontecido anteriormente) ou se ainda há alguma solicitação com falha com 503.
  3. Se houver algum erro 503 com X-Apigee-fault-code messaging.adaptors.http.flow.Serviceavailable, anote o ID da mensagem para uma ou mais solicitações, conforme mostrado no exemplo a seguir:

    Exemplo de entrada mostrando o erro 503

    Entrada de exemplo mostrando o código de status, o ID da mensagem, a origem e o código da falha

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

Diagnóstico

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

      alt_text

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

      alt_text

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

      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: onExceptionWrite exceção: {}
      java.io.IOException: pipe quebrado

      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 da solicitação no 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.
    • O Remote:IP:PORT indica o endereço IP e o número da porta do servidor de back-end resolvido.
    • O atributo bytesWritten=76295 na mensagem de erro acima indica que o processador de mensagens enviou um payload de 76295 bytes para o servidor de back-end quando a conexão foi encerrada prematuramente.
    • O atributo bytesRead=0 indica que o processador de mensagens não recebeu dados (resposta) do servidor de back-end.
    • Para investigar mais o problema, reúna um tcpdump no servidor de back-end ou no processador de mensagens e analise-o conforme explicado abaixo.

Como usar o tcpdump

  1. Capture um tcpdump no servidor de back-end ou no processador de mensagens com os seguintes comandos:

    Comando para reunir 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 as tcpdump capturadas:

    Exemplo de saída do tcpdump (coletada no processador de mensagens):

    alt_text

    No tcpdump acima, você pode conferir o seguinte:

    1. No pacote 4, o processador de mensagens enviou uma solicitação POST ao servidor de back-end.
    2. No pacote 5, 8, 9, 10, 11, o processador de mensagens continuou enviando o payload da solicitação ao servidor de back-end.
    3. No pacote 6 e 7,o servidor de back-end respondeu com ACK para uma parte do payload da solicitação recebido do processador de mensagens.
    4. No entanto, no pacote 12, em vez de responder com um ACK para os pacotes de dados do aplicativo recebidos e, posteriormente, responder com o payload de resposta, 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 envia o payload da solicitação.
    6. Isso faz com que o processador de mensagens registre um erro IOException: Broken Pipe e retorne um 503 para o cliente

Resolução

  1. Trabalhe com suas equipes de aplicativos e de rede ou ambas para analisar e corrigir o problema com desconexões prematuras no lado do servidor de back-end.
  2. Verifique se o aplicativo do servidor de back-end não está atingindo o tempo limite ou redefinindo a conexão antes de receber todo o payload da solicitação.
  3. Se você tiver algum dispositivo ou camada de rede intermediário entre a Apigee e o servidor de back-end, verifique se eles não atingem o tempo limite antes de receber todo o payload da solicitação.

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 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 de 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 no momento, forneça o período com as informações de fuso horário em que os erros 503 ocorreram no passado.

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

  • Concluir a mensagem de erro observada para as solicitações com falha
  • Organização, nome do ambiente e nome do proxy de API em que você está observando erros 503
  • Pacote de proxy de API
  • Arquivo de rastreamento contendo as solicitações com 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 ocorreram os erros 503
  • Tcpdumps coletados nos processadores de mensagens e no servidor de back-end quando o erro ocorreu