503 Serviço indisponível - NoActiveTargets - HealthCheckFailures

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:

Sintoma

O aplicativo cliente recebe o código de status de resposta HTTP 503 com a mensagem Service Invalid e o código de erro NoActiveDestination para as solicitações de proxy de API.

Mensagem de erro

Você verá a seguinte resposta de erro:

HTTP/1.1 503 Service Unavailable
  

Você verá a seguinte mensagem de erro na resposta HTTP:

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

Causas possíveis

A resposta HTTP 503 Service Unused com o código de erro NoActiveDestination normalmente é observada quando você usa um ou mais servidores de destino na configuração de endpoint de destino no seu proxy de API.

Este manual aborda 503 Service Unused com o código de erro NoActiveDestination causado devido a falhas na verificação de integridade. Consulte este manual para saber mais sobre outras causas desse erro.

Falhas na verificação de integridade

As falhas na verificação de integridade só serão observadas se você tiver configurado um Health Monitor como parte da configuração de balanceamento de carga do servidor de destino no endpoint de destino do proxy de API.

Quando um servidor de destino falha em uma verificação de integridade, o Edge aumenta a contagem de falhas desse servidor. Se o número de falhas da verificação de integridade para esse servidor atingir o limite predefinido (<MaxFailures>), o processador de mensagens registrará a mensagem de aviso no arquivo de registros, conforme mostrado abaixo:

Apigee-Timer-7 WARN  ADAPTORS.HTTP.FLOW - LBServer.incrementFailureCount() : Max failure count(10) reached for server : mocktarget2{Environment=<orgname>__prod,Application=mocktargetapigee__1,Target=default}
    

A mensagem de aviso apresenta as informações a seguir. Isso ajuda você a entender qual servidor de destino atingiu a contagem de MaxFailure:

• Nome do servidor de destino
• Nomes de organização e ambiente
• Nome do proxy de API
• Nome do endpoint de destino

Depois disso, o Edge interrompe o envio de outras solicitações para esse servidor específico. Depois que todos os servidores de destino configurados na configuração LoadBalancer atingirem a contagem de MaxFailure, as solicitações subsequentes de API serão respondidas com 503 Service Indisponível com o código de erro NoActiveTargets.

O uso do Health Monitor ajuda o Apigee Edge a incluir automaticamente um servidor de destino de volta na rotação quando ele se torna íntegro, sem precisar reimplantar o proxy da API.

Estas são as possíveis causas para as falhas na verificação de integridade:

Etapas comuns do diagnóstico

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

Mensagens de erro comuns

Quando os servidores de destino forem usados e um erro ocorrer enquanto o processador de mensagens estiver tentando se conectar com o servidor de back-end, você verá algumas mensagens de erro comuns nos registros do processador de mensagens. Esses erros são registrados após a mensagem de exceção/erro real que levou à falha.

As mensagens de erro comuns observadas nos registros do processador de mensagens (/opt/apigee/var/log/edge-message-processor/logs/system.log) para 503 Service Unused com o código de erro NoActiveTargets são:

org:myorg env:prod api:TestTargetServer rev:2 messageid:<messageid>  NIOThread@0 INFO  ADAPTORS.HTTP.FLOW - LBTargetRequestSender.sendRequest() : Failed to send request to target servers : [demo-target] for default{Organization=myorgEnvironment=prod,Application=TestTargetServer__2}

org:myorg env:prod api:TestTargetServer rev:2 messageid:<messageid>  NIOThread@0 ERROR ADAPTORS.HTTP.FLOW - LBTargetRequestSender.sendRequest() : No Active Target server Found for default{Organization=myorgEnvironment=prod,Application=TestTargetServer__2}

org:myorg env:prod api:TestTargetServer rev:2 messageid:<messageid>  NIOThread@0 ERROR ADAPTORS.HTTP.FLOW - LBTargetRequestSender.sendRequest() : Unexpected error while sending request
com.apigee.errors.http.server.ServiceUnavailableException: The Service is temporarily unavailable
	at com.apigee.messaging.adaptors.http.flow.data.LBTargetRequestSender.sendRequest(LBTargetRequestSender.java:299)
	at com.apigee.messaging.adaptors.http.flow.data.LBTargetRequestSender.access$400(LBTargetRequestSender.java:57)
	…<snipped>

Essas mensagens de erro indicam que não foi possível enviar a solicitação ao servidor de back-end devido a uma falha. Como resultado, o processador de mensagens envia 503 Service Available com o código de erro NoActiveTargets como resposta ao cliente.

Causa: tempo limite da conexão

Diagnóstico

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. Você verá as mensagens de erro comuns correspondentes ao código da mensagem. No entanto, para saber a causa real das falhas na verificação de integridade, role a tela acima dessas mensagens de erro comuns e verifique se há erros do HEALTH MONITOR.

   Por exemplo, a mensagem de erro HEALTH MONITOR a seguir indica que o processador de mensagens falhou com um erro de tempo limite de conexão ao fazer a solicitação de API de verificação de integridade:

   Apigee-Timer-6 ERROR SERVICES.HEALTH_MONITOR - HTTPMonitor.getResponseFromCache() : Error sending request Request URL : https://<BackendServer-Hostname>:443/status
   java.net.ConnectException: Connection timed out (Connection timed out)
   	at java.net.PlainSocketImpl.socketConnect(Native Method)
   	at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
   	at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
   …<snipped>
           

   Se esse erro se repetir pelo número de MaxFailure vezes configurados no Monitor de Saúde, você vai receber uma mensagem de aviso como esta:

   Apigee-Timer-7 WARN  ADAPTORS.HTTP.FLOW - LBServer.incrementFailureCount() : Max failure count(10) reached for server : mocktarget2{Environment=<orgname>__prod,Application=mocktargetapigee__1,Target=default}
           

   Leia atentamente as informações na mensagem de aviso. Verifique se a contagem de MaxFailure foi alcançada para um servidor de destino usado no proxy de API específico para o qual você está enfrentando o código de resposta 503 com o código de erro NoActiveTargets.

4. No exemplo acima, a verificação de integridade falhou com o erro connection timed out. Verifique se você pode se conectar ao servidor de back-end específico diretamente de cada um dos processadores de mensagens usando o comando telnet:

telnet <BackendServer-HostName> 443
      

5. Se você conseguir se conectar ao servidor de back-end, talvez receba uma mensagem como Connected to backend-server. Então, o problema pode ser temporário e ter sido resolvido ou é um problema intermitente. Repita a etapa 4 algumas vezes (mais de 10 vezes) e verifique a saída.
1. Se não houver erros com o comando telnet de forma consistente, o problema foi resolvido. Confira novamente se as falhas na verificação de integridade foram interrompidas. Em caso afirmativo, você não precisa fazer mais nada.
2. Se você não conseguir se conectar ao servidor de back-end com o comando telnet de forma intermitente, pode haver um problema de rede ou o servidor de back-end pode estar ocupado.
6. Se você não conseguir se conectar ao servidor de back-end com o comando telnet de forma consistente, é possível que o tráfego não seja permitido pelos processadores de mensagens do servidor de back-end específico.

Resolução

Se o erro connection timed out for observado com consistência, verifique se o servidor de back-end não tem restrições de firewall e permite o tráfego dos processadores de mensagens do Apigee Edge. 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.

Causa: solicitação segura na porta não segura

Diagnóstico

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. Serão exibidas mensagens de erro comuns correspondentes ao código da mensagem. No entanto, para saber a causa real das falhas na verificação de integridade, role acima dessas mensagens de erro comuns e verifique se há erros do HEALTH MONITOR.

   Por exemplo, você pode ver um erro de HEALTH MONITOR, conforme mostrado abaixo:

   Apigee-Timer-1 ERROR SERVICES.HEALTH_MONITOR - HTTPMonitor.getResponseFromCache() : Error sending request Request URL : https://mocktarget.apigee.net:80/status
   javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection?
           at sun.security.ssl.InputRecord.handleUnknownRecord(InputRecord.java:710)
           at sun.security.ssl.InputRecord.read(InputRecord.java:527)
           at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:983)
           at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1385)
           at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1413)
           at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1397)
   …<snipped>
           

   Se esse erro se repetir pelo número de MaxFailure vezes configurado no Monitor de Saúde, você vai receber uma mensagem de aviso como esta:

   Apigee-Timer-7 WARN  ADAPTORS.HTTP.FLOW - LBServer.incrementFailureCount() : Max failure count(10) reached for server : mocktarget{Environment=<orgname>__prod,Application=mocktargetapigee__1,Target=default}
           

   Leia atentamente as informações na mensagem de aviso. Verifique se a contagem de MaxFailure foi alcançada para um servidor de destino usado no proxy de API específico para o qual você está enfrentando o código de resposta 503 com o código de erro NoActiveTargets.

4. A verificação de integridade falhou com o erro:

   Error sending request Request URL : https://mocktarget.apigee.net:80/statuscode/200
   javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection?
         

   A mensagem de erro e o URL indicam que a causa do problema é que uma chamada segura (HTTPS) foi feita na porta 80 não segura.

   Esse erro pode ocorrer nestes dois cenários:

   • Servidor de destino seguro definido com porta não segura
   • Servidor de destino seguro definido, mas o Health Monitor configurado com uma porta não segura

   Porta não segura de destino segura

   Cenário 1: servidor de destino seguro definido com porta não segura

   Se você definiu um servidor de destino seguro, mas com uma porta não segura, como 80, esse erro vai aparecer. Siga as etapas abaixo para verificar se essa é a causa do problema:

   1. Verifique a definição do servidor de destino usado na configuração do endpoint de destino.

   Use a API Get TargetServer para receber a definição do servidor de destino.

   Saída da definição do servidor de destino

   <TargetServer name="mocktarget">
     <Host>mocktarget.apigee.net</Host>
     <Port>80</Port>
     <IsEnabled>true</IsEnabled>
     <SSLInfo>
         <Enabled>true</Enabled>
     </SSLInfo>
   </TargetServer>
             

   No exemplo acima, a definição mostra que o servidor de destino mocktarget é um servidor seguro, conforme indicado pelo bloco SSLInfo. No entanto, ele é configurado com uma Porta 80 não segura.

   2. Agora, verifique a configuração do Health Monitor para o servidor de destino na configuração do endpoint de destino:

      Configuração do monitor de integridade

      <HealthMonitor>
        <IsEnabled>true</IsEnabled>
        <IntervalInSec>5</IntervalInSec>
        <HTTPMonitor>
          <Request>
            <ConnectTimeoutInSec>10</ConnectTimeoutInSec>
            <SocketReadTimeoutInSec>30</SocketReadTimeoutInSec>
            <Verb>GET</Verb>
            <Path>/statuscode/200</Path>
          </Request>
          <SuccessResponse>
            <ResponseCode>200</ResponseCode>
          </SuccessResponse>
        </HTTPMonitor>
      </HealthMonitor>
                

      Observe que não há um elemento <Port> especificado na configuração do Health Monitor acima. Nesse caso, o processador de mensagens do Edge usa a porta especificada na definição do servidor de destino (que é 80) para fazer chamadas da API de verificação de integridade.

   3. Com base nas informações acima, a causa desse erro é que o servidor de destino está definido como um servidor seguro (conforme o bloco SSLInfo está ativado), mas com uma porta 80 não segura.

   Porta HM não segura de destino segura

   Cenário 2: um servidor de destino seguro definido, mas o Health Monitor configurado com uma porta não segura

   Se você definiu um servidor de destino seguro, mas o Health Monitor estiver configurado com uma porta não segura, como 80, você vai receber esse erro. Siga as etapas abaixo para verificar se essa é a causa do problema:

   1. Verifique a definição do servidor de destino usado na configuração do endpoint de destino.

      Use a API Get TargetServer para receber a definição do servidor de destino.

      Saída da definição do servidor de destino

      <TargetServer name="mocktarget">
        <Host>mocktarget.apigee.net</Host>
        <Port>443</Port>
        <IsEnabled>true</IsEnabled>
        <SSLInfo>
            <Enabled>true</Enabled>
        </SSLInfo>
      </TargetServer>
              

      No exemplo acima, a definição mostra que o servidor de destino mocktarget é um servidor seguro, como indicado pelo bloco SSLInfo.

   2. Em seguida, verifique a configuração do Health Monitor para o servidor de destino na configuração do endpoint de destino:

      Configuração do monitor de integridade

      <HealthMonitor>
        <IsEnabled>true</IsEnabled>
        <IntervalInSec>5</IntervalInSec>
        <HTTPMonitor>
          <Request>
            <ConnectTimeoutInSec>10</ConnectTimeoutInSec>
         	<SocketReadTimeoutInSec>30</SocketReadTimeoutInSec>
            <Port>80</Port>
            <Verb>GET</Verb>
            <Path>/statuscode/200</Path>
          </Request>
          <SuccessResponse>
            <ResponseCode>200</ResponseCode>
          </SuccessResponse>
        </HTTPMonitor>
              

      No exemplo acima, o Health Monitor é configurado com uma porta 80 não segura, conforme indicado pelo elemento <Port>.

   3. Com base nas informações acima, a causa desse erro é que o servidor de destino está definido como um servidor seguro (conforme o bloco SSLInfo está ativado) e usa a porta segura 443, mas o Health Monitor está configurado para realizar verificações de integridade com uma porta não segura 80 (especificada no elemento <Port>).

      Ou seja, nesse caso, o Edge faz as APIs de verificação de integridade como uma chamada segura com a porta 80 não segura e falha com o erro mencionado acima.

Resolução

<TargetServer name="mocktarget">
  <Host>mocktarget.apigee.net</Host>
  <Port>443</Port>
  <IsEnabled>true</IsEnabled>
  <SSLInfo>
      <Enabled>true</Enabled>
  </SSLInfo>
</TargetServer>
    

Causa: solicitação não segura em uma porta segura

Diagnóstico

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. Você verá as mensagens de erro comuns correspondentes ao código da mensagem. No entanto, para saber a causa real das falhas na verificação de integridade, role acima dessas mensagens de erro comuns e verifique se há erros do HEALTH MONITOR.

   Por exemplo, você pode ver um erro de HEALTH MONITOR, conforme mostrado abaixo:

   Apigee-Timer-2 ERROR SERVICES.HEALTH_MONITOR - HTTPMonitor.getResponseFromCache() : Error sending request Request URL : http://mocktarget.apigee.net:443/status
   java.net.SocketException: Unexpected end of file from server
   	at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:851)
   	at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:678)
   	at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:848)
   	at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:678)
   	at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1587)
   …<snipped>
             

   Se esse erro se repetir pelo número de MaxFailure vezes configurado no Monitor de Saúde, você vai receber uma mensagem de aviso como esta:

   Apigee-Timer-7 WARN  ADAPTORS.HTTP.FLOW - LBServer.incrementFailureCount() : Max failure count(10) reached for server : mocktarget{Environment=<orgname>__prod,Application=mocktargetapigee__1,Target=default}
             

   Leia atentamente as informações na mensagem de aviso. Verifique se a contagem de MaxFailure foi alcançada para um servidor de destino usado no proxy de API específico para o qual você está enfrentando o código de resposta 503 com o código de erro NoActiveTargets.

4. A verificação de integridade falhou com o erro:

   Error sending request Request URL : http://mocktarget.apigee.net:443/status
   java.net.SocketException: Unexpected end of file from server
         

   A mensagem de erro e o URL indicam que a causa do problema é que uma chamada não segura (HTTP) foi feita na porta segura 443.

   Esse erro pode ocorrer nestes dois cenários:

   • Servidor de destino não seguro definido com porta segura
   • Servidor de destino não seguro definido, mas o Health Monitor configurado com uma porta segura

   Porta segura de destino não segura

   Cenário 1: servidor de destino não seguro definido com porta segura

   Se você definiu um servidor de destino não seguro, mas com uma porta segura, como 443, você receberá esse erro. Siga as etapas abaixo para verificar se essa é a causa do problema:

   1. Verifique a definição do servidor de destino usado na configuração do endpoint de destino.

      Use a API Get TargetServer para receber a definição do servidor de destino.

      Saída da definição do servidor de destino

      <TargetServer name="mocktarget">
        <Host>mocktarget.apigee.net</Host>
        <Port>443</Port>
        <IsEnabled>true</IsEnabled>
      </TargetServer>
                    

      No exemplo acima, a definição mostra que o servidor de destino mocktarget é um servidor não seguro, porque não há um bloco SSLInfo. No entanto, ele foi configurado incorretamente com uma porta 443 segura.

   2. Agora, verifique a configuração do Health Monitor para o servidor de destino na configuração do endpoint de destino:

      Configuração do monitor de integridade

      <HealthMonitor>
        <IsEnabled>true</IsEnabled>
        <IntervalInSec>5</IntervalInSec>
        <HTTPMonitor>
          <Request>
            <ConnectTimeoutInSec>10</ConnectTimeoutInSec>
            <SocketReadTimeoutInSec>30</SocketReadTimeoutInSec>
            <Verb>GET</Verb>
            <Path>/statuscode/200</Path>
          </Request>
          <SuccessResponse>
            <ResponseCode>200</ResponseCode>
          </SuccessResponse>
        </HTTPMonitor>
      </HealthMonitor>
                      

      Não há um elemento <Port> especificado na configuração do Health Monitor acima. Nesse caso, o processador de mensagens do Edge usará a porta especificada na definição do servidor de destino, que é 443.

   3. Com base nas informações acima, a causa desse erro é que o servidor de destino está definido como um servidor não seguro (já que o bloco SSLInfo não está definido), mas com uma porta segura 443.

      Ou seja, o Edge faz as verificações de integridade como uma chamada não segura com a porta segura 443 e falha com o erro mencionado acima.

   Porta HM segura de destino não segura

   Cenário 2: servidor de destino não seguro definido, mas o Health Monitor configurado com uma porta segura

   Se você definiu um servidor de destino não seguro, mas o Health Monitor estiver configurado com uma porta segura, como 443, você vai receber esse erro. Siga as etapas abaixo para verificar se essa é a causa do problema:

   1. Verifique a definição do servidor de destino usado na configuração do endpoint de destino.

      Use a API Get TargetServer para receber a definição do servidor de destino.

      Saída da definição do servidor de destino

      <TargetServer name="mocktarget">
        <Host>mocktarget.apigee.net</Host>
        <Port>80</Port>
        <IsEnabled>true</IsEnabled>
      </TargetServer>
              

      No exemplo acima, a definição mostra que o servidor de destino mocktarget é um servidor não seguro (porque não há um bloco SSLInfo) configurado com uma porta não segura 80 corretamente.

   2. Em seguida, verifique a configuração do Health Monitor para o servidor de destino na configuração do endpoint de destino:

      Configuração do monitor de integridade

      <HealthMonitor>
        <IsEnabled>true</IsEnabled>
        <IntervalInSec>5</IntervalInSec>
        <HTTPMonitor>
          <Request>
            <ConnectTimeoutInSec>10</ConnectTimeoutInSec>
         	<SocketReadTimeoutInSec>30</SocketReadTimeoutInSec>
            <Port>443</Port>
            <Verb>GET</Verb>
            <Path>/statuscode/200</Path>
          </Request>
          <SuccessResponse>
            <ResponseCode>200</ResponseCode>
          </SuccessResponse>
        </HTTPMonitor>
      </HealthMonitor>
            

      No exemplo acima, o Health Monitor é configurado com uma porta 443 segura, conforme indicado pelo elemento <Port>.

   3. Com base nas informações acima, a causa desse erro é que o servidor de destino é definido como um servidor não seguro (já que o bloco SSLInfo não está definido) com a porta não segura 80 corretamente, mas o monitor de integridade está configurado para executar verificações de integridade com uma porta segura 443 (especificada no elemento <Port>).

      Ou seja, nesse caso, o Edge faz as verificações de integridade como uma chamada não segura com a porta segura 443 e falha com o erro mencionado acima.

Resolução

<TargetServer name="mocktarget">
  <Host>mocktarget.apigee.net</Host>
  <Port>80</Port>
  <IsEnabled>true</IsEnabled>
</TargetServer>
              

Causa: a API de verificação de integridade responde com um erro

Diagnóstico

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. Serão exibidas mensagens de erro comuns correspondentes ao código da mensagem. No entanto, para saber a causa real das falhas na verificação de integridade, role acima dessas mensagens de erro comuns e verifique se há erros/avisos do MONITOR DE SAÚDE.

   Por exemplo, você pode receber um alerta de MONITOR DE SAÚDE, conforme mostrado abaixo:

   Apigee-Timer-7 INFO  SERVICES.HEALTH_MONITOR - HTTPMonitor.sendRequest() : HTTPMonitor.monitor() : Connecting to https://mocktarget.apigee.net:443/status/200
   Apigee-Timer-7 WARN  SERVICES.HEALTH_MONITOR - HTTPMonitor.monitor() : HTTP response code from health monitoring service does not match.Expected response code : [200]. Received response code : 404
           

   Se esse erro se repetir pelo número de MaxFailure vezes configurado no Monitor de Saúde, você vai receber uma mensagem de aviso como esta:

   Apigee-Timer-7 WARN  ADAPTORS.HTTP.FLOW - LBServer.incrementFailureCount() : Max failure count(10) reached for server : mocktarget{Environment=<orgname>__prod,Application=mocktargetapigee__1,Target=default}
           

   Leia atentamente as informações na mensagem de aviso. Verifique se a contagem de MaxFailure foi alcançada para um servidor de destino usado no proxy de API específico para o qual você está enfrentando o código de resposta 503 com o código de erro NoActiveTargets.

4. A verificação de integridade retornou a mensagem de aviso:

   HTTP response code from health monitoring service does not match.Expected response code : [200]. Received response code : 404
         

   A mensagem de aviso acima informa que o código de resposta esperado para a API de verificação de integridade era 200, mas a resposta real recebida é 404. Portanto, isso é tratado como uma falha.

5. Antes de investigar a causa da resposta de erro da API de verificação de integridade, determine o motivo pelo qual o Edge espera que o código de resposta seja 200 para a API de verificação de integridade. Para isso, verifique a configuração do Health Monitor para o servidor de destino na configuração do endpoint de destino:

   Configuração do monitor de integridade

   <HealthMonitor>
     <IsEnabled>true</IsEnabled>
     <IntervalInSec>5</IntervalInSec>
     <HTTPMonitor>
       <Request>
         <ConnectTimeoutInSec>10</ConnectTimeoutInSec>
      	<SocketReadTimeoutInSec>30</SocketReadTimeoutInSec>
         <Port>443</Port>
         <Verb>GET</Verb>
         <Path>/status/200</Path>
       </Request>
       <SuccessResponse>
         <ResponseCode>200</ResponseCode>
       </SuccessResponse>
     </HTTPMonitor>
   </HealthMonitor>
           

   A configuração do Health Monitor está definida com o código de resposta 200 no elemento <SuccessResponse>. Isso significa que, se o Edge receber um código de resposta (como 400, 401, 404, 500) diferente de 200 da API de verificação de integridade, ele será tratado como um erro e vai aumentar a contagem de falhas.

6. Agora, para investigar a causa da resposta de erro da API de verificação de integridade, siga as etapas abaixo:
1. Verifique a mensagem anterior à mensagem de aviso no registro do Processador de mensagens.

   Apigee-Timer-7 INFO  SERVICES.HEALTH_MONITOR - HTTPMonitor.sendRequest() : HTTPMonitor.monitor() : Connecting to https://mocktarget.apigee.net:443/status/200
             

   Anote o URL da verificação de integridade dessa mensagem.

2. Você pode fazer uma chamada direta para esse URL pelo processador de mensagens e verificar a resposta real.

   curl -i https://mocktarget.apigee.net:443/status/200
             

   A resposta da chamada acima fornece o erro 404, como aparece nos registros do processador de mensagens:

   < HTTP/2 404
             

3. Isso mostra que até mesmo a chamada direta para o URL de verificação de integridade falha com o mesmo código de resposta 404. Isso significa que o URL de verificação de integridade pode estar incorreto ou o recurso que está sendo acessado como parte do URL não está mais disponível.
4. No exemplo de API de verificação de integridade fornecido acima, o problema ocorre porque um URL incorreto foi usado na configuração do Health Monitor. Foi encontrado o URL correto https://mocktarget.apigee.net:443/statuscode/200 da API Mock Target.
7. Se você receber qualquer outra resposta de erro, siga as etapas acima para determinar a causa do problema. Se necessário, trabalhe com sua equipe de back-end.

Resolução

1. Corrija o problema com a API de verificação de integridade no servidor de back-end.
2. Para corrigir o problema no exemplo discutido acima:
1. Modifique o elemento <Path> na configuração do Health Monitor para /statuscode/200, conforme mostrado abaixo:

   <Path>/statuscode/200</Path>
           

2. Salve as alterações no proxy de API.

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

Diagnosticar problemas usando o monitoramento de APIs

O Monitoramento de APIs permite isolar áreas problemáticas rapidamente para diagnosticar erros, desempenho e latência, bem como a origem delas, 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 solucionar problemas de 5xx com suas APIs usando o API Monitoring. Por exemplo, é possível configurar um alerta para receber uma notificação quando o número de falhas messaging.adaptors.http.flow.NoActiveTargets exceder um limite específico.

É 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. Entre em contato e compartilhe com o suporte da Apigee:

1. Se você é usuário da nuvem pública, forneça as seguintes informações:
1. Nome da organização
2. Nome do ambiente
3. Nome de proxy da API
4. Concluir o comando curl para reproduzir o erro
5. Arquivo de rastreamento que contém as solicitações com o erro "503 Service Indisponível" com o código de erro NoActiveTargets
2. Se você é um usuário da nuvem privada, forneça as seguintes informações:
   1. Mensagem de erro concluída observada
   2. Nome do ambiente
   3. Pacote de proxy de API
   4. Arquivo de rastreamento que contém as solicitações com o erro "503 Service Indisponível" com o código de erro NoActiveTargets
   5. Registros de acesso do NGINX

      (/opt/apigee/var/log/edge-router/nginx/<org>~<env>.<port#>_access_log)

   6. Registros do processador de mensagens

      (/opt/apigee/var/log/edge-message-processor/logs/system.log)