503 Service Unavailable

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

Vídeos

Assista aos vídeos a seguir para mais informações sobre erros 503:

Vídeo Descrição
Solucionar e resolver o erro "503 serviço indisponível devido a um problema de DNS" Saiba mais sobre o seguinte:
  • Erro de serviço indisponível 503 causado por resolução de DNS e problemas relacionados à rede no Apigee Edge
  • Solução de problemas e solução em tempo real de um erro "Serviço Indisponível" 503 causado por um problema de resolução de DNS
Solucionar e resolver o erro "Serviço 503 indisponível" devido a um problema de rede Solução de problemas e resolução em tempo real de um erro de serviço indisponível 503 causado por um problema de rede no Apigee Edge

Sintoma

O aplicativo cliente recebe um status de resposta HTTP 503 com a mensagem Service Unavailable 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 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 ao tempo limite de conexão, erro nome do host ou falhas de handshake de SSL ao se comunicar com o servidor de back-end.

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

Causa Descrição Quem pode realizar as etapas de solução de problemas
Erros de conexão devido à resolução incorreta de DNS A resolução de DNS do servidor de destino resultou em endereços IP incorretos que levaram a erros de conexão. Usuários da nuvem privada de borda
Erros de conexão Problemas de rede ou conectividade impedem que o cliente se conecte ao servidor. Usuários da nuvem privada de borda
Nome de host do servidor de destino incorreto O host do servidor de destino especificado está incorreto ou tem caracteres indesejados (como espaço). Usuários de nuvem pública e privada de borda
Falhas de handshake de SSL O handshake de TLS/SSL falhou entre o cliente e o servidor. (Solução de problemas para esta classe de o problema é abordado em um tópico separado.) 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

Ferramenta Trace

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 da API afetada.
  2. Faça a chamada de API e reproduza o problema: serviço 503 indisponível com o código de 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, como mostrado na figura a seguir.

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

Registros de acesso do NGINX

Para determinar o ID 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 para os erros 503. Isso será útil principalmente se o problema tiver ocorrido no passado ou se for intermitente e você não consegue capturar o rastro na interface. Siga as etapas a seguir 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 no passado) ou se alguma solicitação ainda falha com 503.
  3. Se houver erros 503 com X-Apigee-fault-code messaging.adaptors.http.flow.ServiceUnavailable, anote o ID da mensagem para uma ou mais dessas 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

Erros de conexão devido a uma resolução de DNS incorreta

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 seguintes erros podem ocorrer:

    O 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: três 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 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, a causa pode ser um problema 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 o endereço IP é o mesmo ou um 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 incorretos ou inválidos estão sendo adicionados ao cache do 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 poderá acontecer se houver 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 usará a configuração do /etc/resolv.conf e executará a resolução de DNS conforme apropriado. 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 algum problema com os servidores DNS autoritativos ou com os 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 do DNS do processador de mensagens.
    1. Se o problema com os servidores DNS autoritativos ou com os servidores de nomes especificados em /etc/resolv.conf persistir, os endereços IP inválidos/inválidos vão continuar no cache do DNS do processador de mensagens. Se os endereços IP incorretos forem armazenados no cache de DNS do processador de mensagens, as solicitações de todas essas APIs que usam o servidor de back-end específico falharão com o erro 503.
    2. Se o problema com os servidores DNS autoritativos ou com os servidores de nomes especificados em /etc/resolv.conf for intermitente, os endereços IP bons e inválidos serão armazenados de maneira intermitente no cache do DNS. Nesse caso, você verá erros 503 de maneira intermitente para todas as APIs que usam o servidor de back-end específico.
  9. Se o problema com os servidores DNS persistir, você vai perceber falhas contínuas. Se o problema com os servidores DNS for intermitente, você verá falhas intermitentes. Ou seja, sempre que o nome de host do servidor de back-end for resolvido para endereços IP inválidos, você observará erros 503. E quando os nomes de host do servidor de back-end estiverem resolvidos para bons endereços IP, você observará respostas bem-sucedidas.

Resolução

Entre em contato 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 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 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 back-end. servidor, e um destes problemas ocorre:

  • O processador de mensagens não conseguiu 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). Você pode encontrar os seguintes erros:
    1. Um erro onConnectTimeout indica que o processador de mensagens não conseguiu 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. O erro java.net.ConnectException: Connection denied indica 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 que usam 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 para vários endereços IP, use o nome do host do o 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 conseguir se conectar ao servidor de back-end, pode ser porque os processadores de mensagens Os endereços IP não estão na lista de permissões do back-end específico servidor.

Resolução

Dar acesso aos endereços IP do processador de mensagens no servidor de back-end específico para permitir tráfego dos processadores de mensagens de borda para acessar seu servidor de back-end. Por exemplo, no Linux, é possível 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 Unavailable com o código do erro. messaging.adaptors.http.flow.ServiceUnavailable.

Ferramenta Trace

Para diagnosticar usando a ferramenta Trace:

  1. Se o problema ainda estiver ativo, ative a sessão de rastreamento da API afetada.
  2. Faça a chamada de API e reproduza o problema: serviço 503 indisponível com o código de erro messaging.adaptors.http.flow.ServiceUnavailable..
  3. Selecione uma das solicitações com falha.
  4. Navegue pelas várias fases do trace e localize onde a falha ocorreu.
  5. Selecione o FlowInfo que contém o erro. É possível encontrar mais informações no campo error.cause (em inglês) que podem informar a causa da falha, conforme mostrado no exemplo a seguir:

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

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

      Por exemplo, há um espaço indesejado no nome do host, como mostrado abaixo:
      "demo-target.apigee.net "
    • O nome do host substituído pela variável target.url no proxy de API usando AssignMessage ou A política de JavaScript está incorreta ou tem um espaço ou qualquer outro caractere especial indesejado.
  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 indesejados ou caracteres especiais.
  8. Se o host do servidor de destino for criado dinamicamente, verifique a política apropriada usada para criá-lo, por exemplo, AssignMessage/JavaScript. Marque para verifique se o nome do host do servidor de destino está incorreto ou tem algum espaço indesejado 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 ele 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 desse problema é o nome do host incorreto usado no servidor de destino.

    Acesse Resolução.

Registros do processador de mensagens

Para diagnosticar usando 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 mensagens de aviso/erro a seguir, significa que o processador de mensagens não conseguiu resolver o nome do host. Como a mensagem será adiada, talvez você não veja isto 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. Em seguida, você verá uma mensagem em que o processador de mensagens falha com a exceção "Host not reachable". Às vezes, ele mostra o nome do host como parte da 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 endpoint do servidor/servidor de destino está incorreto ou tem espaços ou caracteres especiais indesejados.

      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 de API usando a política AssignMessage ou 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 das opções a seguir:
    1. Analise cuidadosamente a mensagem de erro que contém Host not reachable .
    2. Se a mensagem de erro mostrar o nome do host, copie-o, incluindo espaços ou caracteres especiais.
    3. Se a mensagem de erro mostrar null para o nome do host, como 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, AssignMessage/JavaScript, usada para criá-lo.
  9. Após determinar o nome do host do servidor de destino, execute o comando nslookup/dig no nome do host e verifique se isso pode ser resolvido.

    Por exemplo, execute o comando nslookup no nome do host que tem 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 é o nome do host incorreto usado para o servidor de destino.

Resolução

  1. Verifique se o nome do host do servidor de destino foi especificado na configuração do endpoint de destino ou no servidor de destino. está correta e não contém espaços indesejados ou caracteres especiais.
  2. Se você usar qualquer política AssignMessage/JavaScript para gerar dinamicamente o nome do host do servidor de destino, analise 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 de handshake de SSL

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

Como determinar a origem do problema

Certos tipos de erros podem ocorrer na entrada (sentido norte) ou na saída (sentido sul) uma conexão com a Internet. Um erro de entrada (no sentido norte) ocorre entre o aplicativo cliente e o Edge. Um um erro de saída (sentido sul) ocorre entre a borda e o servidor de destino do back-end. Para diagnosticar essas tipos de problemas, seu primeiro trabalho é descobrir se o erro ocorre no sentido norte ou conexão sul.

Entender as conexões norte-sul e sul

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

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

Se você é usuário da nuvem pública do Edge, provavelmente não conhece os componentes internos, como entre o roteador ou o processador de mensagens. Esses componentes internos não são visíveis ou acessíveis para e usuários da nuvem pública. Sempre que possível, oferecemos maneiras alternativas de investigar o problema que não exigem acesso direto a eles.

A figura a seguir ilustra as conexões norte e sul da Apigee Borda

Fluxo do aplicativo cliente (conexão norte-americana) por meio de borda para o servidor de back-end (conexão sul)

Determinar onde o erro "503 Serviço indisponível" ocorreu

Use um dos procedimentos a seguir para determinar se o erro "503 Serviço indisponível" ocorreu na conexão sentido norte ou sul.

Trace de interface

Para determinar onde o erro ocorreu usando o rastreamento da interface:

  1. Se o problema persistir, ative o trace da interface da API afetada.
  2. Se o trace de IU da solicitação de API com falha mostrar que o erro 503 Serviço indisponível ocorrer durante o fluxo de solicitações de destino ou for enviado pelo servidor de back-end, o problema será southbound (ou seja, entre o processador de mensagens e o back-end do servidor).
  3. Se você não receber o rastro da chamada de API específica, o problema é northbound, entre o aplicativo cliente e o roteador.

Monitoramento de APIs

O API Monitoring permite isolar rapidamente as áreas problemáticas para diagnosticar problemas de erro, desempenho, latência e a origem deles. como apps para desenvolvedores, proxies de API, destinos de back-end ou a plataforma de API.

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

Registros de acesso do NGINX

Para determinar onde o erro ocorreu usando o rastreamento da interface:

Se o problema já aconteceu ou se for intermitente e você não conseguir capture o rastro e execute as seguintes 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 em um proxy de API específico.
  3. Se você conseguir identificar Erros 503 para a API específica em um momento específico, então o 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 no sentido norte (entre o aplicativo cliente e o roteador).