503 Service Unavailable

Você está lendo a documentação do Apigee Edge.
Acesse a documentação da Apigee X. info

Vídeos

Confira os vídeos a seguir para mais informações sobre erros 503:

Sintoma

O aplicativo cliente recebe um status de resposta HTTP 503 com a mensagem Serviço indisponível após uma chamada de proxy de API.

Mensagens de erro

Você vai ver a seguinte mensagem de erro:

HTTP/1.1 503 Service Unavailable
      

Você também pode ver a seguinte mensagem de erro na resposta HTTP:

Serviço indisponível

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

Causas possíveis

A resposta HTTP 503 Service Unavailable com o código de erro messaging.adaptors.http.flow.ServiceUnavailable ocorre se o processador de mensagens do Apigee Edge apresentar erros devido a tempo limite de conexão, nome de host incorreto ou falhas de handshake SSL ao se comunicar com o servidor de back-end.

As possíveis causas para a resposta 503 Service Unavailable são:

Etapas comuns do diagnóstico

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

Erros de conexão devido à resolução incorreta de DNS

Diagnóstico

1. Determine o ID da mensagem da solicitação com falha.
2. Procure o ID da mensagem de solicitação específica no registro do processador de mensagens (/opt/apigee/var/log/edge-message-processor/logs/system.log). Talvez você encontre os seguintes erros:
   
   Um erro onConnectTimeout indica que o processador de mensagens não conseguiu se conectar ao servidor de back-end no período de tempo limite de conexão predefinido (padrão: 3 segundos).

   2019-08-14 09:11:49,314 org:myorg env:prod api:Employees rev:1 messageid:mo-96cf6757a-9401-21-1 NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context.onTimeout() : ClientChannel[Connected:]@164162 useCount=1 bytesRead=0 bytesWritten=0 age=3001ms lastIO=3001ms .onConnectTimeout connectAddress=www.abc.com/11.11.11.11  resolvedAddress=www.abc.com/22.22.22.22
   
   2019-08-14 09:11:49,333 org:myorg env:prod api:Employees rev:1 messageid:mo-96cf6757a-9401-21-1 NIOThread@0 ERROR ADAPTORS.HTTP.FLOW - RequestWriteListener.onTimeout() : RequestWriteListener.onTimeout(HTTPRequest@6b393600)
         

3. Observe o endereço IP resolvido no erro onConnectTimeout e verifique se ele é válido para seu servidor de back-end. Se o endereço IP for válido, acesse Erros de conexão.
4. Se o endereço IP for inválido, provavelmente o problema é causado por falhas na resolução de DNS.
5. Repita as etapas 3 e 4 para mais algumas solicitações de API com falha e verifique se você está vendo os mesmos ou outros endereços IP inválidos.
6. Pesquise no registro do processador de mensagens (/opt/apigee/var/log/edge-message-processor/logs/system.log) mensagens com a palavra-chave Atualização de DNS. Verifique se endereços IP inválidos ou incorretos estão sendo adicionados ao cache DNS no processador de mensagens de vez em quando.

   2019-08-14 09:11:49,314 org:myorg env:prod api:Employees rev:1 messageid:mo-96cf6757a-9401-21-1 NIOThread@0 INFO c.a.p.h.d.DNSCachedAddress - DNSCachedAddress.reportDifferences() : DNS Refresh for host: apitarget-uat.schemeweb.co.uk:4436. Added 2 IPs [www.abc.com/22.22.22.22, www.abc.com/33.33.33.33] Removed 1 IPs [www.abc.com/11.11.11.11]
         

7. Esse problema pode ocorrer se houver problemas com os servidores DNS autorizados ou com os servidores de nomes configurados em /etc/resolv.conf.
   
   Normalmente, pode haver um ou mais servidores DNS autoritativos configurados para realizar a resolução de DNS. Se não houver servidores DNS autoritativos, o sistema vai voltar à configuração em /etc/resolv.conf e realizar a resolução de DNS conforme necessário. Por exemplo, se o /etc/resolv.conf estiver configurado para usar servidores de nomes específicos, eles serão usados para realizar a resolução de DNS.
8. Se houver problemas com servidores DNS autoritativos ou servidores de nomes especificados em /etc/resolv.conf, os nomes de host do servidor de back-end serão resolvidos para endereços IP inválidos. Os endereços IP inválidos/incorretos serão armazenados no cache DNS do processador de mensagens.
   1. Se o problema com os servidores DNS autoritativos ou de nomes especificados em /etc/resolv.conf persistir, os endereços IP inválidos/incorretos vão continuar no cache DNS do processador de mensagens. Enquanto os endereços IP incorretos estiverem armazenados no cache DNS do processador de mensagens, as solicitações de todas essas APIs usando o servidor de back-end específico vão falhar com o erro 503.
   2. Se o problema com os servidores DNS autoritativos ou de nomes especificados em /etc/resolv.conf for intermitente, os endereços IP bons e ruins serão armazenados de forma intermitente no cache DNS. Nesse caso, você vai receber erros 503 intermitentemente para todas as APIs que usam o servidor de back-end específico.
9. Se o problema com os servidores DNS persistir, você vai notar falhas contínuas. Se o problema com os servidores DNS for intermitente, você vai notar falhas intermitentes. Ou seja, sempre que o nome do host do servidor de back-end é resolvido para endereços IP incorretos, você observa erros 503. Quando os nomes de host do servidor de back-end são resolvidos em endereços IP válidos, você observa respostas bem-sucedidas.

Resolução

Trabalhe com o administrador do sistema operacional e corrija os problemas com os servidores DNS.

1. Se houver um problema com seus servidores DNS autoritativos ou servidores de nomes especificados em /etc/resolv.conf, corrija o problema com o servidor apropriado.
2. Se houver algum problema com a configuração em /etc/resolv.conf nos sistemas com processadores de mensagens, corrija o problema.

Erros de conexão

Um erro de conexão ocorre quando um processador de mensagens do Apigee Edge tenta se conectar a um servidor de back-end e um destes problemas acontece:

• O processador de mensagens não consegue se conectar dentro do período de tempo limite de conexão predefinido. Padrão: 3 segundos
• O servidor de back-end recusa a conexão.

Diagnóstico

1. Determine o ID da mensagem da solicitação com falha.
2. Procure o ID da mensagem de solicitação específica no registro do processador de mensagens (/opt/apigee/var/log/edge-message-processor/logs/system.log). Talvez você encontre os seguintes erros:
   1. Um erro onConnectTimeout indica que o processador de mensagens não conseguiu se conectar ao servidor de back-end no período de tempo limite de conexão predefinido.

      2016-06-23 09:11:49,314 org:myorg env:prod api:Employees rev:1 messageid:mo-96cf6757a-9401-21-1 NIOThread@2 ERROR HTTP.CLIENT - HTTPClient$Context.onTimeout() : ClientChannel[C:]@10 useCount=1 bytesRead=0 bytesWritten=0 age=3001ms lastIO=3001ms .onConnectTimeout connectAddress=www.abc.com/11.11.11.11:80 resolvedAddress=www.abc.com/11.11.11.11
      2016-06-23 09:11:49,333 org:myorg env:prod api:Employees rev:1 messageid:mo-96cf6757a-9401-21-1 NIOThread@2 ERROR ADAPTORS.HTTP.FLOW - RequestWriteListener.onTimeout() : RequestWriteListener.onTimeout(HTTPRequest@6b393600)

   2. Um erro java.net.ConnectException: Connection refused indica que a conexão foi recusada pelo servidor de back-end.

      14:40:16.531 +0530
      2016-06-17 09:10:16,531 org:myorg env:prod api:www.abc.com rev:1 rrt07eadn-22739-40983870-15 NIOThread@2 ERROR HTTP.CLIENT - HTTPClient$Context.onConnectFailure() : connect to www.abc.com:11.11.11.11:443 failed with exception {}
      java.net.ConnectException: Connection refused
      at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method) ~[na:1.7.0_75]
      at sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:739) ~[na:1.7.0_75]
      at com.apigee.nio.ClientChannel.finishConnect(ClientChannel.java:121) ~[nio-1.0.0.jar:na]
      at com.apigee.nio.handlers.NIOThread.run(NIOThread.java:108) ~[nio-1.0.0.jar:na]

3. Verifique se é possível se conectar ao servidor de back-end específico diretamente de cada um dos Processadores de mensagens usando o comando telnet:
   1. Se o servidor de back-end for resolvido em um único endereço IP, use o seguinte comando:

      telnet BackendServer-IPaddress 443
                

   2. Se o servidor de back-end for resolvido para vários endereços IP, use o nome do host do servidor de back-end no comando telnet, como mostrado abaixo:

      telnet BackendServer-HostName 443
                

4. Se você conseguir se conectar ao servidor de back-end, poderá ver uma mensagem como Connected to backend-server. Se não for possível se conectar ao servidor de back-end, talvez seja porque os endereços IP dos processadores de mensagens não estão na lista de permissões do servidor de back-end específico.

Resolução

Dê acesso aos endereços IP do processador de mensagens no servidor de back-end específico para permitir que o tráfego dos processadores de mensagens do Edge acesse seu servidor de back-end. Por exemplo, no Linux, você pode usar iptables para permitir o tráfego dos endereços IP do processador de mensagens no servidor de back-end.

Se o problema persistir, trabalhe com seu administrador de rede para determinar e corrigir o problema. Se precisar de mais ajuda da Apigee, entre em contato com o suporte da Apigee.

Nome do host do servidor de destino incorreto

Diagnóstico

Se o nome do host especificado no servidor de destino estiver incorreto, você poderá receber a resposta 503 Service Unavailable com o código de erro messaging.adaptors.http.flow.ServiceUnavailable.

Resolução

1. Verifique se o nome do host do servidor de destino especificado na configuração do endpoint de destino ou na definição do servidor de destino está correto e não tem espaços ou caracteres especiais indesejados.
2. Se você usar uma política AssignMessage/JavaScript para gerar dinamicamente o nome do host do servidor de destino, investigue a definição da política e o código e garanta que o nome do host do servidor de destino seja gerado corretamente.

Falhas no handshake de SSL

Um playbook inteiro de solução de problemas é dedicado a erros de handshake TLS/SSL. Consulte Falhas no handshake de SSL.

Determinar a origem do problema

Alguns tipos de erros podem ocorrer na conexão de entrada (norte) ou de saída (sul). Um erro de entrada (norte) ocorre entre o aplicativo cliente e o Edge. Um erro de saída (sul) ocorre entre o Edge e o servidor de destino de back-end. Para diagnosticar esses tipos de problemas, seu primeiro trabalho é descobrir se o erro ocorre na conexão de entrada ou de saída.

Noções básicas sobre conexões de entrada e saída

No Edge, você pode encontrar um erro 503 "Serviço indisponível" na conexão de entrada ou saída:

• Conexão de entrada (ou northbound): a conexão entre o aplicativo cliente e o roteador de borda. O roteador é o componente do Apigee Edge que processa solicitações recebidas feitas ao sistema.
• Conexão de saída (ou de sentido sul): a conexão entre o processador de mensagens do Edge e o servidor de back-end. O processador de mensagens é um componente do Apigee Edge que encaminha solicitações de API para servidores de destino de back-end.

Se você usa a nuvem pública do Edge, provavelmente não conhece componentes internos, como o roteador ou o processador de mensagens. Esses componentes internos não são visíveis nem acessíveis para usuários da nuvem pública. Quando possível, oferecemos outras maneiras de investigar o problema que não exigem acesso direto a esses componentes.

A figura a seguir ilustra as conexões nos sentidos norte e sul do Apigee Edge.

Determinar onde ocorreu o erro "503 Service Unavailable"

Use um dos procedimentos a seguir para determinar se o erro 503 "Serviço indisponível" ocorreu na conexão de entrada ou de saída.