503 Servizio non disponibile - NoActiveTarget - HealthCheckFailures

Stai visualizzando la documentazione di Apigee Edge.
Consulta la documentazione di Apigee X. info

Video

Per ulteriori informazioni sugli errori 503, guarda i seguenti video:

Sintomo

L'applicazione client riceve il codice di stato della risposta HTTP 503 con il messaggio Servizio non disponibile e il codice di errore NoActiveTargets per le richieste del proxy API.

Messaggio di errore

Verrà visualizzata la seguente risposta di errore:

HTTP/1.1 503 Service Unavailable
  

Nella risposta HTTP viene visualizzato il seguente messaggio di errore:

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

Possibili cause

La risposta HTTP 503 Service Unavailable con il codice di errore NoActiveTargets viene in genere osservata quando utilizzi uno o più server di destinazione nella configurazione dell'endpoint di destinazione nel proxy API.

Questo playbook riguarda l'errore 503 Servizio non disponibile con il codice di errore NoActiveTargets causato da errori di controllo di integrità. Per scoprire altre cause di questo errore, consulta questa guida pratica.

Errori del controllo di integrità

Gli errori del controllo di integrità verranno osservati solo se hai configurato un monitor di integrità nell'ambito della configurazione del bilanciamento del carico del server di destinazione nell'endpoint di destinazione del proxy API.

Quando un server di destinazione non supera un controllo di integrità, Edge incrementa il conteggio degli errori del server. Se il numero di errori di controllo dell'integrità per il server raggiunge la soglia predefinita (<MaxFailures>), il processore di messaggi registra il messaggio di avviso nel file di log come mostrato di seguito:

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}
    

Il messaggio di avviso fornisce le seguenti informazioni. In questo modo puoi capire quale server di destinazione ha raggiunto il conteggio MaxFailure:

• Nome server di destinazione
• Nomi dell'organizzazione e dell'ambiente
• Nome del proxy API
• Nome endpoint di destinazione

Dopodiché, Edge smette di inviare ulteriori richieste a quel server specifico. Una volta che tutti i server di destinazione configurati nella configurazione LoadBalancer raggiungono il conteggio MaxFailure, le successive richieste API rispondono con 503 Servizio non disponibile con il codice di errore NoActiveTargets.

L'utilizzo di Health Monitor consente ad Apigee Edge di includere automaticamente un server di destinazione nella rotazione quando diventa integro, senza dover eseguire nuovamente il deployment del proxy API.

Ecco le possibili cause degli errori del controllo di integrità:

Passaggi di diagnostica comuni

Determinare l'ID messaggio della richiesta non riuscita

Messaggi di errore comuni

Quando vengono utilizzati i server di destinazione e si verifica un errore mentre il processore di messaggi tenta di connettersi al server di backend, nei log del processore di messaggi vengono visualizzati alcuni messaggi di errore comuni. Questi errori vengono registrati dopo il messaggio di eccezione/errore effettivo che ha causato l'errore.

I messaggi di errore comuni osservati nei log del processore di messaggi (/opt/apigee/var/log/edge-message-processor/logs/system.log) per 503 Service Unavailable con il codice di errore NoActiveTargets sono i seguenti:

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>

Questi messaggi di errore indicano che la richiesta non è stata inviata al server di backend a causa di un errore. Di conseguenza, il processore di messaggi invia 503 Service Unavailable con il codice di errore NoActiveTargets come risposta al client.

Causa: timeout connessione

Diagnosi

1. Determina l'ID messaggio della richiesta non riuscita.
2. Cerca l'ID messaggio nel log del processore di messaggi (/opt/apigee/var/log/edge-message-processor/logs/system.log).
3. Verranno visualizzati i messaggi di errore comuni corrispondenti all'ID messaggio. Tuttavia, per conoscere la causa effettiva degli errori del controllo di integrità, scorri sopra questi messaggi di errore comuni e verifica la presenza di errori HEALTH MONITOR.

   Ad esempio, il seguente messaggio di errore HEALTH MONITOR indica che il processore di messaggi non è riuscito con l'errore di timeout della connessione durante l'invio della richiesta API di controllo di integrità:

   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 questo errore si ripete per il numero di volte configurato in Monitoraggio integrità per MaxFailure, viene visualizzato un messaggio di avviso simile a questo:

   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}
           

   Leggi attentamente le informazioni riportate nel messaggio di avviso. Assicurati che il conteggio MaxFailure sia stato raggiunto per un server di destinazione utilizzato nel proxy API specifico per il quale riscontri il codice di risposta 503 con il codice di errore NoActiveTargets.

4. Nell'esempio precedente, il controllo di integrità non è riuscito a causa dell'errore connection timed out. Verifica se riesci a connetterti al server di backend specifico direttamente da ciascuno dei processori di messaggi utilizzando il comando telnet:

telnet <BackendServer-HostName> 443
      

5. Se riesci a connetterti al server di backend, potresti visualizzare un messaggio come Connesso a backend-server. In questo caso, il problema potrebbe essere temporaneo e potrebbe essersi risolto o essere intermittente. Ripeti il passaggio 4 alcune volte (più di 10 volte) e verifica l'output.
1. Se non si verificano errori con il comando telnet, il problema è risolto. Controlla di nuovo se gli errori del controllo di integrità sono stati risolti. In caso affermativo, non devi fare altro.
2. Se non riesci a connetterti al server di backend con il comando telnet in modo intermittente, potrebbe esserci un problema di rete o il server di backend potrebbe essere occupato.
6. Se non riesci a connetterti al server di backend con il comando telnet in modo coerente, potrebbe essere perché il traffico non è consentito dai processori di messaggi sul server di backend specifico.

Risoluzione

Se l'errore connection timed out viene osservato in modo coerente, assicurati che il server di backend non abbia restrizioni firewall e consenta il traffico dai processori di messaggi Apigee Edge. Ad esempio, su Linux puoi utilizzare iptables per consentire il traffico dagli indirizzi IP del processore di messaggi sul server di backend.

Se il problema persiste, collabora con l'amministratore di rete per determinare e risolvere il problema. Se hai bisogno di ulteriore assistenza da parte di Apigee, contatta l'assistenza Apigee.

Causa: richiesta sicura su porta non sicura

Diagnosi

1. Determina l'ID messaggio della richiesta non riuscita.
2. Cerca l'ID messaggio nel log del processore di messaggi (/opt/apigee/var/log/edge-message-processor/logs/system.log).
3. Verranno visualizzati i messaggi di errore comuni corrispondenti all'ID messaggio. Tuttavia, per conoscere la causa effettiva degli errori del controllo di integrità, scorri sopra questi messaggi di errore comuni e verifica la presenza di errori HEALTH MONITOR.

   Ad esempio, potresti visualizzare un errore HEALTH MONITOR come mostrato di seguito:

   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 questo errore si ripete per il MaxFailure numero di volte configurato in Monitoraggio integrità, visualizzerai un messaggio di avviso simile al seguente:

   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}
           

   Leggi attentamente le informazioni riportate nel messaggio di avviso. Assicurati che il conteggio MaxFailure sia stato raggiunto per un server di destinazione utilizzato nel proxy API specifico per il quale riscontri il codice di risposta 503 con il codice di errore NoActiveTargets.

4. Il controllo di integrità non è riuscito e ha generato l'errore:

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

   Il messaggio di errore e l'URL indicano che la causa di questo problema è che è stata effettuata una chiamata sicura (HTTPS) sulla porta non sicura 80.

   Questo errore può verificarsi nei seguenti due scenari:

   • Server di destinazione sicuro definito con porta non sicura
   • Server di destinazione sicuro definito, ma Health Monitor configurato con una porta non sicura

   Proteggi la porta non protetta di destinazione

   Scenario 1: server di destinazione sicuro definito con porta non sicura

   Se hai definito un server di destinazione sicuro, ma con una porta non sicura come la 80, ricevi questo errore. Per verificare se questa è la causa del problema, procedi nel seguente modo:

   1. Controlla la definizione del server di destinazione utilizzato nella configurazione dell'endpoint di destinazione.

   Utilizza l'API Get TargetServer per ottenere la definizione del server di destinazione.

   Output della definizione del server di destinazione

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

   Nell'esempio precedente, la definizione mostra che il server di destinazione mocktarget è un server sicuro, come indicato dal blocco SSLInfo. Tuttavia, è configurato con la porta 80 non sicura.

   2. Ora, controlla la configurazione di Health Monitor per il server di destinazione nella configurazione dell'endpoint di destinazione:

      Configurazione del monitoraggio dell'integrità

      <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>
                

      Tieni presente che non è specificato alcun elemento <Port> nella configurazione del monitoraggio dell'integrità riportata sopra. In questo caso, il processore di messaggi di Edge utilizza la porta specificata nella definizione del server di destinazione (ovvero 80) per effettuare chiamate API di controllo di integrità.

   3. In base alle informazioni riportate sopra, la causa di questo errore è che il server di destinazione è definito come server sicuro (poiché il blocco SSLInfo è abilitato), ma con una porta non sicura 80.

   Proteggere la porta HM non sicura di destinazione

   Scenario 2: server di destinazione sicuro definito, ma monitoraggio dell'integrità configurato con una porta non sicura

   Se hai definito un server di destinazione sicuro, ma il monitoraggio dell'integrità è configurato con una porta non sicura come la 80, viene visualizzato questo errore. Per verificare se questa è la causa del problema, procedi nel seguente modo:

   1. Controlla la definizione del server di destinazione utilizzato nella configurazione dell'endpoint di destinazione.

      Utilizza l' API Get TargetServer per ottenere la definizione del server di destinazione.

      Output della definizione del server di destinazione

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

      Nell'esempio precedente, la definizione mostra che il server di destinazione mocktarget è un server sicuro, come indicato dal blocco SSLInfo.

   2. Successivamente, controlla la configurazione di Health Monitor per il server di destinazione nella configurazione dell'endpoint di destinazione:

      Configurazione del monitoraggio dell'integrità

      <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>
              

      Nell'esempio precedente, il monitor di integrità è configurato con una porta 80 non sicura, come indicato dall'elemento <Port>.

   3. In base alle informazioni riportate sopra, la causa di questo errore è che il server di destinazione è definito come server sicuro (poiché il blocco SSLInfo è abilitato) e utilizza la porta sicura 443, ma il monitoraggio dell'integrità è configurato per eseguire i controlli di integrità con una porta non sicura 80 (specificata nell'elemento <Port>).

      ovvero, in questo caso, Edge esegue le API di controllo di integrità come chiamata sicura con la porta non sicura 80 e non riesce a causa dell'errore menzionato in precedenza.

Risoluzione

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

Causa: richiesta non sicura su una porta sicura

Diagnosi

1. Determina l'ID messaggio della richiesta non riuscita.
2. Cerca l'ID messaggio nel log del processore di messaggi (/opt/apigee/var/log/edge-message-processor/logs/system.log).
3. Verranno visualizzati i messaggi di errore comuni corrispondenti all'ID messaggio. Tuttavia, per conoscere la causa effettiva degli errori del controllo di integrità, scorri sopra questi messaggi di errore comuni e verifica la presenza di errori HEALTH MONITOR.

   Ad esempio, potresti visualizzare un errore HEALTH MONITOR come mostrato di seguito:

   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 questo errore si ripete per il MaxFailure numero di volte configurato in Monitoraggio integrità, visualizzerai un messaggio di avviso simile al seguente:

   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}
             

   Leggi attentamente le informazioni riportate nel messaggio di avviso. Assicurati che il conteggio MaxFailure sia stato raggiunto per un server di destinazione utilizzato nel proxy API specifico per il quale riscontri il codice di risposta 503 con il codice di errore NoActiveTargets.

4. Il controllo di integrità non è riuscito e ha generato l'errore:

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

   Il messaggio di errore e l'URL indicano che la causa di questo problema è che è stata effettuata una chiamata non sicura (HTTP) sulla porta sicura 443.

   Questo errore può verificarsi nei seguenti due scenari:

   • Server di destinazione non sicuro definito con porta sicura
   • Server di destinazione non sicuro definito, ma monitor di integrità configurato con una porta sicura

   Porta sicura di destinazione non sicura

   Scenario 1: server di destinazione non sicuro definito con porta sicura

   Se hai definito un server di destinazione non sicuro, ma con una porta sicura come la 443, viene visualizzato questo errore. Per verificare se questa è la causa del problema, procedi nel seguente modo:

   1. Controlla la definizione del server di destinazione utilizzato nella configurazione dell'endpoint di destinazione.

      Utilizza l' API Get TargetServer per ottenere la definizione del server di destinazione.

      Output della definizione del server di destinazione

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

      Nell'esempio precedente, la definizione mostra che il server di destinazione mocktarget è un server non sicuro perché non è presente alcun blocco SSLInfo. Tuttavia, è configurato in modo errato con una porta 443 sicura.

   2. Ora, controlla la configurazione di Health Monitor per il server di destinazione nella configurazione dell'endpoint di destinazione:

      Configurazione del monitoraggio dello stato di integrità

      <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>
                      

      Tieni presente che nella configurazione di monitoraggio dell'integrità riportata sopra non è specificato alcun elemento <Port>. In questo caso, il processore di messaggi di Edge utilizzerà la porta specificata nella definizione del server di destinazione, ovvero la porta 443.

   3. In base alle informazioni riportate sopra, la causa di questo errore è che il server di destinazione è definito come server non sicuro (poiché il blocco SSLInfo non è definito), ma con una porta sicura 443.

      ovvero Edge esegue i controlli di integrità come chiamata non sicura con la porta sicura 443 e non riesce con l'errore menzionato in precedenza.

   Porta HM sicura di destinazione non sicura

   Scenario 2: server di destinazione non sicuro definito, ma monitoraggio dell'integrità configurato con una porta sicura

   Se hai definito un server di destinazione non sicuro, ma il monitoraggio dell'integrità è configurato con una porta sicura come la 443, viene visualizzato questo errore. Per verificare se questa è la causa del problema, procedi nel seguente modo:

   1. Controlla la definizione del server di destinazione utilizzato nella configurazione dell'endpoint di destinazione.

      Utilizza l' API Get TargetServer per ottenere la definizione del server di destinazione.

      Output della definizione del server di destinazione

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

      Nell'esempio precedente, la definizione mostra che il server di destinazione mocktarget è un server non sicuro (in quanto non è presente alcun blocco SSLInfo) configurato con una porta non sicura 80 correttamente.

   2. Successivamente, controlla la configurazione di Health Monitor per il server di destinazione nella configurazione dell'endpoint di destinazione:

      Configurazione del monitoraggio dell'integrità

      <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>
            

      Nell'esempio precedente, il monitor di integrità è configurato con la porta 443 sicura, come indicato dall'elemento <Port>.

   3. In base alle informazioni riportate sopra, la causa di questo errore è che il server di destinazione è definito come un server non sicuro (poiché il blocco SSLInfo non è definito) con la porta non sicura 80 correttamente, ma il monitoraggio dello stato di integrità è configurato per eseguire controlli di integrità con una porta sicura 443 (specificata nell'elemento <Port>).

      ovvero, in questo caso, Edge esegue i controlli di integrità come chiamata non sicura con la porta sicura 443 e non riesce a causa dell'errore menzionato in precedenza.

Risoluzione

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

Causa: l'API di controllo dell'integrità risponde con un errore

Diagnosi

1. Determina l'ID messaggio della richiesta non riuscita.
2. Cerca l'ID messaggio nel log del processore di messaggi (/opt/apigee/var/log/edge-message-processor/logs/system.log).
3. Verranno visualizzati i messaggi di errore comuni corrispondenti all'ID messaggio. Tuttavia, per conoscere la causa effettiva degli errori del controllo di integrità, scorri sopra questi messaggi di errore comuni e verifica la presenza di errori/avvisi di MONITORAGGIO DELL'INTEGRITÀ.

   Ad esempio, potresti visualizzare un avviso di MONITORAGGIO DELLA SALUTE come mostrato di seguito:

   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 questo errore si ripete per il MaxFailure numero di volte configurato in Monitoraggio integrità, visualizzerai un messaggio di avviso simile al seguente:

   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}
           

   Leggi attentamente le informazioni riportate nel messaggio di avviso. Assicurati che il conteggio MaxFailure sia stato raggiunto per un server di destinazione utilizzato nel proxy API specifico per il quale riscontri il codice di risposta 503 con il codice di errore NoActiveTargets.

4. Il controllo di integrità ha restituito il messaggio di avviso:

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

   Il messaggio di avviso riportato sopra indica che il codice di risposta previsto per l'API di controllo di integrità era 200, ma la risposta effettiva ricevuta è 404. Pertanto, viene considerato un errore.

5. Prima di esaminare la causa della risposta di errore dell'API di controllo di integrità, determina perché Edge si aspetta che il codice di risposta sia 200 per l'API di controllo di integrità. A questo scopo, controlla la configurazione del monitoraggio dell'integrità per il server di destinazione nella configurazione dell'endpoint di destinazione:

   Configurazione del monitoraggio dell'integrità

   <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>
           

   Tieni presente che la configurazione di Monitoraggio integrità è configurata con il codice di risposta 200 nell'elemento <SuccessResponse>. Ciò significa che se Edge riceve un codice di risposta (ad esempio 400, 401, 404, 500) diverso da 200 dall'API di controllo di integrità, verrà trattato come un errore e il conteggio degli errori verrà incrementato.

6. Ora, per esaminare la causa della risposta di errore dell'API per il controllo di integrità, segui questi passaggi:
1. Esamina il messaggio precedente al messaggio di avviso nel log del processore di messaggi.

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

   Prendi nota dell'URL del controllo di integrità da questo messaggio.

2. Puoi effettuare una chiamata diretta a questo URL dal processore di messaggi e controllare la risposta effettiva.

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

   La risposta alla chiamata precedente restituisce 404, come mostrato nei log del processore di messaggi:

   < HTTP/2 404
             

3. Ciò dimostra che anche la chiamata diretta all'URL del controllo di integrità non va a buon fine e restituisce lo stesso codice di risposta 404. Ciò significa che l'URL del controllo di integrità potrebbe non essere corretto o che la risorsa a cui si accede come parte dell'URL non è più disponibile.
4. Nell'API di controllo di integrità di esempio fornita sopra, il problema si verifica perché è stato utilizzato un URL errato nella configurazione di Health Monitor. È stato rilevato che l'URL corretto è https://mocktarget.apigee.net:443/statuscode/200 dall'API Mock Target.
7. Se ricevi un'altra risposta di errore, determina la causa seguendo i passaggi precedenti. Se necessario, collabora con il team di backend.

Risoluzione

1. Risolvi il problema relativo all'API di controllo di integrità sul server di backend.
2. Per risolvere il problema nell'esempio discusso sopra:
1. Modifica l'elemento <Path> nella configurazione del monitor di integrità in /statuscode/200 come mostrato di seguito:

   <Path>/statuscode/200</Path>
           

2. Salva le modifiche nel proxy API.

Se il problema persiste, vai a Must Gather Diagnostic Information.

Diagnostica i problemi utilizzando il monitoraggio delle API

Il monitoraggio delle API ti consente di isolare rapidamente le aree problematiche per diagnosticare errori, problemi di prestazioni e latenza e la loro origine, ad esempio app per sviluppatori, proxy API, target di backend o la piattaforma API.

Esamina uno scenario di esempio che mostra come risolvere i problemi 5xx con le API utilizzando API Monitoring. Ad esempio, potresti voler configurare un avviso per ricevere una notifica quando il numero di guasti messaging.adaptors.http.flow.NoActiveTargets supera una determinata soglia.

Deve raccogliere informazioni diagnostiche

Se il problema persiste anche dopo aver seguito le istruzioni riportate sopra, raccogli le seguenti informazioni diagnostiche. Contattali e condividili con l'assistenza Apigee:

1. Se sei un utente di Public Cloud, fornisci le seguenti informazioni:
1. Nome dell'organizzazione
2. Nome ambiente
3. Nome proxy API
4. Comando curl completo per riprodurre l'errore
5. File di traccia contenente le richieste con errore 503 Servizio non disponibile con codice di errore NoActiveTargets
2. Se sei un utente di Private Cloud, fornisci le seguenti informazioni:
   1. Messaggio di errore completo osservato
   2. Nome ambiente
   3. Bundle proxy API
   4. File di traccia contenente le richieste con errore 503 Servizio non disponibile con codice di errore NoActiveTargets
   5. Log di accesso NGINX

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

   6. Log del processore di messaggi

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