503 Servizio non disponibile - NoActiveTarget - HealthCheckFailures

Stai visualizzando la documentazione di Apigee Edge.
Vai alla sezione Documentazione di Apigee X. Informazioni

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 la il messaggio Servizio non disponibile e il codice di errore NoActiveTarget per le richieste 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

In genere viene osservata la risposta HTTP 503 Service Unavailable con il codice di errore NoActiveTarget. quando utilizzi uno o più server di destinazione nella configurazione dell'endpoint di destinazione del proxy API.

Questa guida pratica riguarda il servizio 503 non disponibile con il codice di errore NoActiveTargets provocati da errori del controllo di integrità. Consulta questa guida pratica per conoscere altre cause di questo errore.

Errori del controllo di integrità

Gli errori del controllo di integrità verranno osservati solo se è stata configurata una Monitoraggio di integrità come parte 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 numero di errori del server. Se il numero di errori del controllo di integrità per il server raggiunge la soglia predefinita (<MaxFailures>), L'elaboratore di messaggi registra il messaggio di avviso come mostrato di seguito nel proprio file di log:

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. Questo ti aiuta a capire quale server di destinazione ha raggiunto il numero di MaxFailure:

• Nome server di destinazione
• Nomi di organizzazioni e ambienti
• Nome proxy API
• Nome endpoint di destinazione

Dopodiché, Edge smette di inviare ulteriori richieste a quel server specifico. Una volta che tutti i target i server configurati nella configurazione LoadBalancer raggiungono il conteggio di MaxFailure, le successive Le richieste API ricevono una risposta con 503 Service Unavailable con il codice di errore NoActiveTarget.

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

Di seguito sono riportate le possibili cause degli errori nel controllo di integrità:

Passaggi diagnostici 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 durante il tentativo dell'elaboratore di messaggi per connetterti al server di backend, vedrai alcuni messaggi di errore comuni nella Log del processore di messaggi. Questi errori vengono registrati dopo l'effettivo messaggio di errore/eccezione che ha portato all'errore.

Messaggi di errore comuni osservati nei log del processore di messaggi (/opt/apigee/var/log/edge-message-processor/logs/system.log) per 503 Servizio non disponibile con il codice di errore NoActiveTarget 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 non è stato possibile inviare la richiesta al server di backend a causa di un errore. Di conseguenza, il processore di messaggi invia un messaggio 503 Service Unavailable con il codice di errore NoActiveTargets come risposta al client.

Causa: timeout della 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. Vedrai l'icona messaggi di errore comuni corrispondenti all'ID messaggio. Tuttavia, per scoprire la causa effettiva degli errori del controllo di integrità, scorri sopra queste messaggi di errore comuni e verifica la presenza di eventuali errori HEALTH MONITOR.

   Ad esempio, il seguente messaggio di errore HEALTH MONITOR indica che il processore di messaggi non ha funzionato con errore di timeout della connessione durante l'invio della richiesta API per il 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 MaxFailure numero di volte configurato nel Monitoraggio salute, viene visualizzato un messaggio di avviso simile al seguente:

   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 contenute nel messaggio di avviso. Assicurati che MaxFailure per un server di destinazione usato nello specifico proxy API per il quale venga visualizzato il codice di risposta 503 con il codice di errore NoActiveTargets.

4. Nell'esempio precedente, il controllo di integrità non è riuscito e ha generato l'errore connection timed out. Verifica se riesci a connetterti al server di backend specifico direttamente da ciascun server Processori di messaggi che utilizzano il comando telnet:

telnet <BackendServer-HostName> 443
      

5. Se riesci a connetterti al server di backend, potresti visualizzare un messaggio simile a Connesso a backend-server. Potrebbe trattarsi di un problema temporaneo e potrebbe essere stato risolto o si tratta di un problema intermittente. Ripeti il passaggio 4 alcune volte (almeno 10 volte) e verifica l'output.
1. Se non ci sono costantemente errori con il comando telnet, il problema è risolto. Ricontrolla se gli errori del controllo di integrità sono stati interrotti. Se sì, non dovrai farlo altro ancora.
2. Se non riesci a connetterti al server di backend con il comando telnet a intermittenza: è possibile che ci sia un problema di rete o che il tuo server di backend sia occupato.
6. Se non riesci a connetterti al server di backend in modo coerente con il comando telnet: il traffico potrebbe non essere consentito dai processori di messaggi sullo specifico server di backend.

Risoluzione

Se l'errore connection timed out viene osservato costantemente, assicurati che il backend server non ha limitazioni firewall e consente il traffico dai processori di messaggi Apigee Edge. Ad esempio, su Linux, potresti utilizzare iptables per consentire il traffico proveniente Indirizzi IP del processore di messaggi sul server di backend.

Se il problema persiste, rivolgiti all'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 una 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 queste messaggi di errore comuni e verifica la presenza di eventuali errori HEALTH MONITOR.

   Ad esempio, potresti visualizzare l'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 MaxFailure numero di volte la configurazione nel Monitoraggio salute, viene visualizzato un messaggio di avviso come il 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 contenute nel messaggio di avviso. Assicurati che MaxFailure per un server di destinazione usato nello specifico proxy API per il quale viene visualizzato il codice di risposta 503 con il codice di errore NoActiveTargets.

4. Il controllo di integrità non è riuscito e si è verificato 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 del problema è che chiamata sicura (HTTPS) è stata effettuata sulla porta non sicura 80.

   Questo errore può verificarsi nei due seguenti scenari:

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

   Porta non sicura di destinazione

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

   Se avete definito un server di destinazione sicuro, ma con una porta non sicura come 80, 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 la Recupera l'API TargetServer per ottenere la definizione del server di destinazione.

   Output definizione 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 come indicato dal blocco SSLInfo. Tuttavia, è configurata con una porta 80 non sicura.

   2. Ora controlla la configurazione del Monitoraggio di integrità del server di destinazione nella configurazione dell'endpoint di destinazione:

      Configurazione del monitor 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 non è specificato alcun elemento <Port> nel Configurazione di Monitoraggio di integrità qui sopra. In questo caso, il processore di messaggi di Edge utilizza la porta specificato nella definizione del server di destinazione (che è 80) per effettuare chiamate API per il controllo di integrità.

   3. In base alle informazioni precedenti, questo errore è dovuto al fatto che il server di destinazione definito come un server sicuro (perché è abilitato il blocco SSLInfo), ma con una porta non sicura 80.

   Porta HM non sicura di destinazione

   Scenario 2: è stato definito un server di destinazione sicuro, ma Monitoraggio di integrità configurato con una porta non sicura

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

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

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

      Output definizione 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. Quindi, controlla la configurazione del Monitoraggio di integrità del server di destinazione nella configurazione dell'endpoint di destinazione:

      Configurazione del monitor di 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, Health Monitor è configurato con una porta 80 non sicura, come indicato dall'elemento <Port>.

   3. In base alle informazioni riportate sopra, questo errore è dovuto al fatto che il server di destinazione è definito Come server sicuro (poiché il blocco SSLInfo è abilitato) e utilizza la porta protetta 443, ma la funzionalità Monitoraggio Salute è configurata per eseguire controlli di integrità con una porta non sicura 80 (specificata nell'elemento <Port>).

      In questo caso, Edge rende le API di controllo di integrità come una chiamata sicura porta 80 e restituisce l'errore riportato sopra.

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. Vedrai l'icona messaggi di errore comuni corrispondenti all'ID messaggio. Tuttavia, per conoscere la causa effettiva degli errori del controllo di integrità, scorri sopra queste messaggi di errore comuni e verifica la presenza di eventuali errori HEALTH MONITOR.

   Ad esempio, potresti visualizzare l'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 MaxFailure numero di volte la configurazione nel Monitoraggio salute, viene visualizzato un messaggio di avviso come il 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 contenute nel messaggio di avviso. Assicurati che MaxFailure per un server di destinazione usato nello specifico proxy API per il quale viene visualizzato il codice di risposta 503 con il codice di errore NoActiveTargets.

4. Il controllo di integrità non è riuscito e si è verificato 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 del problema è che la chiamata non sicura (HTTP) è stata effettuata sulla porta protetta 443.

   Questo errore può verificarsi nei due seguenti scenari:

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

   Porta sicura di destinazione non sicura

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

   Se hai definito un server di destinazione non sicuro ma con una porta sicura come 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 la Ottieni l'API TargetServer per ottenere la definizione del server di destinazione.

      Output definizione 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 protetto in quanto non esiste un blocco SSLInfo. Tuttavia, non è corretto configurato con una porta 443 sicura.

   2. Ora controlla la configurazione del Monitoraggio di integrità del server di destinazione nella configurazione dell'endpoint di destinazione:

      Configurazione del monitor 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 non è specificato alcun elemento <Port> in Monitoraggio salute configurazione precedente. In questo caso, il processore di messaggi di Edge utilizzerà la porta specificata la definizione del server di destinazione, che è 443.

   3. In base alle informazioni riportate sopra, questo errore è dovuto al fatto che il server di destinazione è definito Come server non protetto (poiché il blocco SSLInfo non è definito), ma con una porta 443 protetta.

      In altre parole, Edge effettua i controlli di integrità come una chiamata non sicura con la porta sicura 443 e non va a buon fine con l'errore indicato sopra.

   Porta HM sicura di destinazione non sicura

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

   Se hai definito un server di destinazione non sicuro ma il monitoraggio dello stato di integrità è configurato con una porta sicura come 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 la Ottieni l'API TargetServer per ottenere la definizione del server di destinazione.

      Output definizione 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 non è sicuro (in quanto non è presente un blocco SSLInfo) configurato correttamente con una porta 80 non sicura.

   2. Quindi, controlla la configurazione del Monitoraggio di integrità del server di destinazione nella configurazione dell'endpoint di destinazione:

      Configurazione del monitor di 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, Health Monitor è configurato con una porta 443 sicura, come indicato dall'elemento <Port>.

   3. In base alle informazioni riportate sopra, questo errore è dovuto al fatto che il server di destinazione è definito come Un server non protetto (dal momento che il blocco SSLInfo non è definito) con correttamente la porta 80 non protetta; ma Monitoraggio di integrità è configurato per eseguire controlli di integrità con una porta sicura 443 (specificata nell'elemento <Port>).

      In questo caso, Edge esegue i controlli di integrità come chiamate non sicure con la porta sicura 443 e non va a buon fine con il suddetto errore.

Risoluzione

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

Causa: l'API per il controllo di 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 queste messaggi di errore comuni e verifica la presenza di errori/avvisi relativi a HEALTH MONITOR.

   Ad esempio, potresti visualizzare l'avviso HEALTH MONITOR 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 MaxFailure numero di volte la configurazione nel Monitoraggio salute, viene visualizzato un messaggio di avviso come il 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 contenute nel messaggio di avviso. Assicurati che MaxFailure per un server di destinazione usato nello specifico proxy API per il quale viene visualizzato 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 per il controllo di integrità era 200. ma la risposta effettiva ricevuta è 404. Pertanto, viene considerato un errore.

5. Prima di indagare sulla causa della risposta di errore da parte dell'API per il controllo di integrità, determina perché Edge prevede che il codice di risposta per l'API per il controllo di integrità sia 200. Per farlo, controlla il Monitoraggio del Salute per il server di destinazione nella configurazione dell'endpoint di destinazione:

   Configurazione del monitor di 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 di integrità è configurata con il codice di risposta 200 nell'elemento <SuccessResponse>. Ciò significa che se Edge riceve un qualsiasi codice di risposta (ad esempio 400, 401, 404, 500) diverso da 200 dall'API per il controllo di integrità, verrà trattata come un errore e il conteggio degli errori verrà incrementato.

6. Ora, per esaminare la causa della risposta di errore dall'API per il controllo di integrità, segui questi passaggi:
1. Esamina il messaggio prima del 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à contenuto in 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 un errore 404, come indicato 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 con 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 per il controllo di integrità di esempio fornita sopra, il problema si verifica perché nella configurazione di Monitoraggio di integrità è stato utilizzato un URL errato. È stato rilevato che l'URL corretto è https://mocktarget.apigee.net:443/statuscode/200 da API Mock Target.
7. Se ricevi un'altra risposta di errore, determina la causa seguendo le passaggi precedenti. Se necessario, collabora con il team di backend.

Risoluzione

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

   <Path>/statuscode/200</Path>
           

2. Salva le modifiche nel proxy API.

Se il problema persiste, vai a Raccogliere informazioni diagnostiche.

Diagnosi dei problemi utilizzando il monitoraggio delle API

Il monitoraggio delle API ti consente di isolare le aree in modo da diagnosticare rapidamente i problemi di errore, prestazioni e latenza e la loro origine, come come le app, i proxy API, i target di backend o la piattaforma API.

Presentazione di uno scenario di esempio che illustra come risolvere i problemi 5xx relativi alle API utilizzando il monitoraggio delle API. Ad esempio: ti consigliamo di impostare un avviso per ricevere una notifica quando il numero di messaging.adaptors.http.flow.NoActiveTargets di errore superano una determinata soglia.

Raccogliere dati diagnostici

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

1. Se sei un utente del cloud pubblico, fornisci le seguenti informazioni:
1. Nome dell'organizzazione
2. Nome ambiente
3. Nome proxy API
4. Completa il comando curl per riprodurre l'errore
5. File di traccia contenente le richieste con servizio 503 non disponibile con codice di errore NoActiveTarget
2. Se sei un utente del cloud privato, 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 servizio 503 non disponibile con codice di errore NoActiveTarget
   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)