503 Service Unavailable

Você está vendo a documentação do Apigee Edge.
Acesse a documentação da Apigee X. informações

Vídeos

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

Vídeo Descrição
Como solucionar problemas de erro "503 de serviço indisponível" devido a um problema de DNS Saiba mais sobre:
  • Erro 503 "Serviço indisponível" causado pela resolução de DNS e por problemas relacionados à rede no Apigee Edge.
  • Solução de problemas e resolução de um erro 503 de serviço indisponível em tempo real causado por um problema de resolução de DNS
Como solucionar problemas e corrigir o erro 503 de indisponibilidade de serviço devido a um problema de rede Solução de problemas e resolução do erro 503 de serviço indisponível em tempo real causado por um problema de rede no Apigee Edge

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

A seguinte mensagem de erro será exibida:

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 Serviço Indisponível 503 com o código de erro messaging.adaptors.http.flow.ServiceUnavailable ocorre se o processador de mensagens do Apigee Edge apresentar erros devido ao tempo limite da conexão, nome do host incorreto ou falhas de handshake de SSL durante a comunicação com o servidor de back-end.

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

Causa Descrição Quem pode executar as etapas de solução de problemas
Erros de conexão devido à resolução incorreta de DNS A resolução DNS do servidor de destino resultou em endereços IP inválidos, o que gerou erros de conexão. Usuários da nuvem privada do Edge
Erros de conexão Problemas de rede ou conectividade impedem que o cliente se conecte ao servidor. Usuários da nuvem privada do Edge
Nome de host do servidor de destino incorreto O host do servidor de destino especificado está incorreto ou tem caracteres indesejados (por exemplo, espaço). Usuários de nuvens públicas e privadas de borda
Falhas de handshake de SSL Falha no handshake de TLS/SSL entre o cliente e o servidor. A solução de problemas para essa classe de problema é abordada em um tópico separado. 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 Serviço indisponível 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 aconteceu anteriormente) ou se há alguma solicitação que ainda falha com 503.
  3. Se houver algum erro 503 com X-Apigee-fault-code messaging.adaptors.http.flow.ServiceStorage, anote o ID da mensagem para uma ou mais solicitações, conforme mostrado no exemplo a seguir:

    Entrada de exemplo que mostra o erro 503

    Entrada de exemplo mostrando o código de status, o ID da mensagem, a origem e o código da 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). Você pode observar os seguintes erros:

    Um erro onConnectTimeout indica que o processador de mensagens não conseguiu se conectar ao servidor de back-end dentro do 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. Anote o endereço IP resolvido no erro onConnectTimeout e verifique se o endereço IP é 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, o motivo mais provável pode ser problemas com a 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 o mesmo ou qualquer outro endereço IP inválido.
  6. Pesquise no registro do processador de mensagens (/opt/apigee/var/log/edge-message-processor/logs/system.log) mensagens com a palavra-chave DNS Refresh. Verifique se endereços IP inválidos ou inválidos 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 acontecer quando há algum problema com os servidores DNS autoritativos ou com os servidores de nomes configurados no /etc/resolv.conf.

    Normalmente, pode haver um ou mais servidores DNS autoritativos configurados para executar a resolução de DNS. Se não houver servidores DNS autoritativos, ele vai voltar à configuração do /etc/resolv.conf e executar a resolução de DNS conforme necessário. Por exemplo: se a /etc/resolv.conf estiver configurada para usar servidores de nomes específicos, eles serão usados para realizar a resolução de DNS.
  8. Se houver algum problema 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/inválidos. Os endereços IP inválidos/inválidos serão armazenados no cache DNS do processador de mensagens.
    1. Se o problema com servidores DNS autoritativos ou servidores de nomes especificados em /etc/resolv.conf for persistente, os endereços IP inválidos/inválidos continuarão a permanecer no cache DNS do processador de mensagens. Contanto que os endereços IP inválidos sejam armazenados no cache de DNS do processador de mensagens, as solicitações para todas as APIs que usam o servidor de back-end específico falharão com o erro 503.
    2. Se o problema com servidores DNS autoritativos ou de nomes especificados em /etc/resolv.conf for intermitente, os endereços IP bons e ruins serão armazenados de maneira intermitente no cache do DNS. Neste caso, você verá erros 503 de forma intermitente para todas as APIs que usam o servidor de back-end específico.
  9. Se o problema com os servidores DNS for persistente, você terá falhas contínuas. Se o problema com os servidores DNS for intermitente, você verá falhas intermitentes. Ou seja, sempre que o nome do host do servidor de back-end for resolvido com endereços IP inválidos, você observa erros 503. E quando os nomes de host do servidor de back-end forem resolvidos com bons endereços IP, você vai observar respostas bem-sucedidas.

Resolução

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

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

Erros de conexão

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

  • O processador de mensagens não consegue se conectar dentro do 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. Pesquise 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). Os erros a seguir podem ocorrer:
    1. Um erro onConnectTimeout indica que o processador de mensagens não conseguiu se conectar ao servidor de back-end dentro do 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 restrictedd 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 você consegue 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 para um único endereço IP, use o seguinte comando: 
      telnet BackendServer-IPaddress 443
    2. Se o servidor de back-end resolver vários endereços IP, use o nome do host do servidor de back-end no comando telnet, conforme mostrado abaixo: 
      telnet BackendServer-HostName 443
  4. Se você conseguir se conectar ao servidor de back-end, talvez veja uma mensagem como Connected to backend-server. Se você não consegue se conectar ao servidor de back-end, pode ser que os endereços IP dos processadores de mensagens não estejam na lista de permissões do servidor de back-end específico.

Resolução

Conceda 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 de borda 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 o administrador da rede para determinar e corrigir o problema. Se precisar de mais ajuda da Apigee, entre em contato com o suporte da Apigee.

Nome de 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 Unused com o código de erro messaging.adaptors.http.flow.ServiceUnavailable.

Ferramenta de rastreamento

Para diagnosticar 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 Serviço indisponível com o código do erro messaging.adaptors.http.flow.ServiceUnavailable.
  3. Selecione uma das solicitações com falha.
  4. Navegue pelas várias fases do rastro e localize onde a falha ocorreu.
  5. Selecione o FlowInfo que contém o erro. Você pode encontrar mais informações no campo error.cause, que pode informar a causa da falha, como mostrado no exemplo a seguir:

    Exemplo de solicitação mostrando error.causa no trace

    Exemplo de solicitação mostrando error.Cause no rastro
  6. Se você perceber que error.cause mostra error.cause, a causa provável do erro é uma destas:
    • O nome do host especificado na configuração do servidor de destino/endpoint do endpoint está incorreto ou tem espaços indesejados ou caracteres especiais.

      Por exemplo, há um espaço indesejado no nome do host, conforme mostrado abaixo:
      "demo-target.apigee.net "
    • O nome do host substituído pela variável target.url no proxy da API usando a política AssignMessage ou JavaScript está incorreto ou tem um espaço ou outros caracteres especiais indesejados.
  7. Verifique a configuração do endpoint de destino e/ou a definição do servidor de destino para ver se o nome do host do servidor de destino está incorreto ou tem espaços ou caracteres especiais indesejados.
  8. Se o host do servidor de destino for criado dinamicamente, verifique a política apropriada (a política AssignMessage/JavaScript, por exemplo) usada para criá-lo. Verifique se o nome do host do servidor de destino está incorreto ou tem espaços indesejados ou caracteres especiais.
  9. Depois de determinar o nome do host do servidor de destino, execute o comando nslookup/dig no nome do host para ver se o problema pode ser resolvido.

    Por exemplo, executar o comando nslookup no nome do host com um espaço indesejado retorna a seguinte saída:

    nslookup "demo-target.apigee.net "
Server:	49.205.75.2
Address:	49.205.75.2#53

** server can't find demo-target.apigee.net\032: NXDOMAIN
  10. Se o comando nslookup do sistema operacional também não resolver o nome do host, a causa do problema é o nome de host incorreto usado para o servidor de destino.

    Acesse Resolução.

Registros do processador de mensagens

Para diagnosticar usando os registros do processador de mensagens:

  1. Determine o ID da mensagem da solicitação com falha.
  2. Procure o ID da mensagem no registro do Processador de mensagens. (/opt/apigee/var/log/edge-message-processor/logs/system.log)
  3. Se você vir as seguintes mensagens de aviso/erro, o processador de mensagens não conseguiu resolver o nome do host. Como a mensagem será adiada, talvez você não veja esse aviso para todos os IDs/solicitações de mensagens. 
    org:myorg env:prod api:TestTargetServer rev:2 messageid:<messageid>  NIOThread@0 WARN S.HTTPCLIENTSERVICE - DNSCache$2.failed() : Failed to resolve hostname www.somehost.com . Reason mocktarget.apigee.net : Name or service not known. This log message will snooze for 2 hours
  4. Isso será seguido por uma mensagem de aviso, em que o processador de mensagens remove o endereço do cache do DNS, já que o host do servidor de destino não pôde ser alcançado. 
    org:myorg env:prod api:TestTargetServer rev:2 messageid:<messageid> NIOThread@0 WARN  c.a.p.h.d.DNSCachedAddress - DNSCachedAddress.addressNotReachable() : The last address has been removed from Address list null refreshing
  5. Talvez você veja uma mensagem em que o processador de mensagens falha com a exceção "Host not reachable". Às vezes, o nome do host aparece na mensagem de erro: 
    org:myorg env:prod api:TestTargetServer rev:2 messageid:<messageid>  NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context.onConnectFailure() :  connect to demo-target.apigee.net  failed with exception {}
java.lang.RuntimeException: Host not reachable
	at com.apigee.protocol.http.HTTPClient$Context.initConnect(HTTPClient.java:704)
	at com.apigee.protocol.http.HTTPClient$Context.send(HTTPClient.java:675)
	at com.apigee.messaging.adaptors.http.flow.data.TargetRequestSender.sendRequest(TargetRequestSender.java:234)
	…<snipped>
  6. Às vezes, ele pode aparecer como null, já que o nome do host não pode ser resolvido ou acessível, conforme mostrado abaixo: 
    org:myorg env:prod api:TestTargetServer rev:2 messageid:<messageid>  NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context.onConnectFailure() :  connect to null failed with exception {}
java.lang.RuntimeException: Host not reachable
	at com.apigee.protocol.http.HTTPClient$Context.initConnect(HTTPClient.java:704)
	at com.apigee.protocol.http.HTTPClient$Context.send(HTTPClient.java:675)
	at com.apigee.messaging.adaptors.http.flow.data.TargetRequestSender.sendRequest(TargetRequestSender.java:234)
	…<snipped>
  7. O erro Host not reachable geralmente ocorre em um dos seguintes casos:
    • O nome do host especificado na configuração do servidor de destino/endpoint do endpoint está incorreto ou tem espaços indesejados ou caracteres especiais.

      Por exemplo, há um espaço indesejado no nome do host "demo-target.apigee.net " na seguinte mensagem de erro: 
      NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context.onConnectFailure() :  connect to demo-target.apigee.net  failed with exception
    • O nome do host substituído pela variável target.url no proxy da API usando a política AssignMessage ou o JavaScript está incorreto ou tem um espaço ou outros caracteres especiais indesejados.
  8. Determine o nome do host do servidor de destino com o qual o processador de mensagens está tentando se comunicar usando uma destas opções:
    1. Analise a mensagem de erro que contém Host not reachable com atenção.
    2. Se a mensagem de erro mostrar o nome do host, copie-o incluindo os espaços ou caracteres especiais.
    3. Se a mensagem de erro mostrar null para o nome do host, conforme visto na mensagem de erro a seguir, 
      org:myorg env:prod api:TestTargetServer rev:2 messageid:<messageid>  NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context.onConnectFailure() :  connect to null failed with exception {}
      1. Determine o nome do host verificando a definição do servidor de destino usada no proxy de API com falha.
      2. Se o host do servidor de destino for criado dinamicamente, verifique a política apropriada (por exemplo, a política AssignMessage/JavaScript) usada para criá-lo.
  9. Depois de determinar o nome do host do servidor de destino, execute o comando nslookup/dig no nome do host e verifique se o problema pode ser resolvido.

    Por exemplo, execute o comando nslookup no nome do host que tenha um espaço

    nslookup "demo-target.apigee.net "
Server:	49.205.75.2
Address:	49.205.75.2#53

** server can't find demo-target.apigee.net\032: NXDOMAIN
  10. Se o comando nslookup do sistema operacional também não resolver o nome do host, a causa desse problema é um nome de host incorreto usado para o servidor de destino.

Resolução

  1. Verifique se o nome de 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 indesejados ou caracteres especiais.
  2. Se você usar qualquer política AttributionMessage/JavaScript para gerar dinamicamente o nome de host do servidor de destino, investigue a definição da política e o código e verifique se esse nome foi gerado corretamente.

Falhas de handshake de SSL

Todo o manual de solução de problemas é dedicado aos erros de handshake de TLS/SSL. Consulte Falhas do handshake de SSL.

Determinar a origem do problema

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

Como entender as conexões norte e sul

No Edge, você pode encontrar o erro 503 Service Indisponível na conexão de entrada ou de saída:

  • Conexão de entrada (ou norte): a conexão entre o aplicativo cliente e o roteador de borda. O roteador é o componente do Apigee Edge que lida com as solicitações de entrada feitas para o sistema.
  • Conexão de saída (ou sul): a conexão entre o processador de mensagens de borda 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ê é um usuário de nuvem pública de borda, provavelmente não tem conhecimento de componentes internos, como o roteador ou o processador de mensagens. Esses componentes internos não ficam visíveis nem acessíveis para usuários da nuvem pública. Sempre que possível, oferecemos maneiras alternativas de investigar o problema que não exigem acesso direto a esses componentes.

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

Fluxo do aplicativo cliente (conexão no sentido norte) pela borda para o servidor de back-end (conexão no sentido sul)

Como determinar onde ocorreu o erro 503 Service Indisponível

Use um dos procedimentos a seguir para determinar se o erro 503, serviço indisponível ocorreu no sentido norte ou sul.

Rastreamento de interface

Para determinar onde o erro ocorreu usando o UI Trace:

  1. Se o problema continuar ativo, ative o rastreamento de interface da API afetada.
  2. Se o rastreamento da IU para a solicitação de API com falha mostrar que o erro 503, serviço indisponível ocorre durante o fluxo de solicitação de destino ou é enviado pelo servidor de back-end, o problema é southbound (ou seja, entre o processador de mensagens e o servidor de back-end).
  3. Se você não receber o rastro da chamada de API específica, o problema estará no sentido norte, entre o aplicativo cliente e o roteador.

Monitoramento de APIs

O Monitoramento de APIs permite isolar áreas problemáticas para diagnosticar erros, desempenho e latência rapidamente, além da origem, como apps de desenvolvedores, proxies de API, destinos de back-end ou a plataforma da API.

Consulte um exemplo de cenário que demonstra como resolver problemas de 5xx com suas APIs usando o monitoramento de APIs. Por exemplo, você pode configurar um alerta para receber uma notificação quando o número de falhas messaging.adaptors.http.flow.ServiceUnavailable exceder um limite específico.

Registros de acesso do NGINX

Para determinar onde o erro ocorreu usando o UI Trace:

Se o problema já tiver acontecido ou se ele for intermitente e não for possível capturar o rastro, siga estas etapas:

  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 um proxy de API específico.
  3. Se você conseguir identificar erros 503 para a API específica em um momento específico, isso significa que o problema ocorreu na conexão southbound (entre o processador de mensagens e o servidor de back-end).
  4. Caso contrário, o problema ocorreu na conexão northbound (entre o aplicativo cliente e o roteador).