Questa pagina è stata tradotta dall'API Cloud Translation.

503 Servizio non disponibile - NoActiveTarget - HealthCheckFailures

Stai visualizzando la documentazione di Apigee Edge.
Vai alla documentazione di Apigee X. informazioni

Video

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

Video	Descrizione
Risolvi i problemi del servizio 503 non disponibile - NoActiveTarget	Scopri di più su quanto segue: Importanza dei server di destinazione e dei monitor di integrità Risoluzione dei problemi e risoluzione di un servizio 503 in tempo reale non disponibile - Errore NoActiveTarget causato a causa di errori del controllo di integrità

Sintomo

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

Messaggio di errore

Visualizzerai 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 Disabled (Servizio non disponibile) con il codice di errore NoActiveTarget viene in genere osservata quando utilizzi uno o più server di destinazione nella configurazione dell'endpoint di destinazione nel proxy API.

Questo playbook illustra il servizio 503 non disponibile con il codice di errore NoActiveTarget causato a causa di errori del controllo di integrità. Consulta questo playbook per scoprire altre cause di questo errore.

Errori del controllo di integrità

Gli errori del controllo di integrità verranno osservati solo se hai configurato un 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 in questione 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 conteggio di MaxFailure:

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

Da quel momento in poi, 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 richieste API successive ricevono una risposta con 503 Service Non disponibile con il codice di errore NoActiveTarget.

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.

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

Causa	Descrizione	Chi può eseguire la procedura di risoluzione dei problemi
Errore di timeout della connessione	Il processore di messaggi non è in grado di connettersi al server di destinazione entro il periodo di timeout specificato nella configurazione LoadBalancer.	Utenti del cloud privato perimetrale
Richiesta protetta su porta non sicura	Se il server di destinazione è stato definito come un server sicuro, ma è stato configurato in modo errato con una porta non protetta. Se il server di destinazione è definito come un server sicuro, ma il monitoraggio di integrità è configurato per eseguire i controlli di integrità su una porta non sicura.	Utenti del cloud privato perimetrale
Richiesta non sicura su porta protetta	Se il server di destinazione viene definito come un server non protetto, ma configurato in modo errato con una porta sicura. Se il server di destinazione è definito come un server non sicuro, ma il monitoraggio di integrità è configurato per eseguire i controlli di integrità su una porta protetta.	Utenti del cloud privato perimetrale
L'API Health Check risponde con un errore	Se l'API per il controllo di integrità risponde con un errore o un codice di risposta, qualsiasi elemento diverso da quello specificato nell'elemento SuccessResponse del monitoraggio dell'integrità.	Utenti del cloud privato perimetrale

Passaggi di diagnosi più comuni

Determinare l'ID messaggio della richiesta non riuscita

Strumento Traccia

Per determinare l'ID messaggio della richiesta non riuscita utilizzando lo strumento Trace:

Abilita la trace session, effettua la chiamata API e riproduci il problema 503 Service Non disponibile con il codice di errore NoActiveTarget.
Seleziona una delle richieste con esito negativo.
Vai alla fase AX e determina l'ID messaggio (X-Apigee.Message-ID) della richiesta scorrendo verso il basso nella sezione Dettagli fase, come mostrato nella figura seguente.

Log degli accessi NGINX

Per determinare l'ID messaggio della richiesta non riuscita utilizzando i log degli accessi NGINX:

Puoi anche fare riferimento ai log di accesso NGINX per determinare l'ID messaggio per gli errori 503. Questa funzionalità è particolarmente utile se il problema si è verificato in passato o se è intermittente e non riesci ad acquisire la traccia nell'interfaccia utente. Per determinare queste informazioni dai log degli accessi di NGINX, segui questi passaggi:

Controlla i log degli accessi di NGINX: (/opt/apigee/var/log/edge-router/nginx/ <org>~ <env>.<port#>_access_log)
Cerca se sono presenti errori 503 per il proxy API specifico durante un periodo di tempo specifico (se il problema si è verificato in passato) o se ci sono ancora richieste che continuano a non funzionare con la risposta 503.
Se si verificano errori 503 con X-Apigee-fault-code Messaging.adaptors.http.flow.NoActiveTarget, prendi nota dell'ID messaggio per una o più richieste di questo tipo, come mostrato nell'esempio seguente:
Voce di esempio che mostra l'errore 503

Messaggi di errore comuni

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

Di seguito sono riportati i messaggi di errore comuni osservati nei log del processore di messaggi (/opt/apigee/var/log/edge-message-processor/logs/system.log) per il servizio 503 non disponibile con il codice di errore NoActiveTarget:

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 503 Service Non disponibile con il codice di errore NoActiveTarget come risposta al client.

Causa: timeout della connessione

Diagnostica

Determina l'ID del messaggio della richiesta non riuscita.
Cerca l'ID messaggio nel log dell'elaboratore di messaggi (/opt/apigee/var/log/edge-message-processor/logs/system.log).
Vedrai i messaggi di errore comuni corrispondenti all'ID messaggio. Tuttavia, per scoprire la causa effettiva degli errori del controllo di integrità, scorri sopra questi messaggi di errore comuni e verifica la presenza di eventuali errori di HEALTH MONITOR.
Ad esempio, il seguente messaggio di errore HEALTH MONITOR indica che il processore di messaggi non è riuscito con errore di timeout della connessione quando si effettua la 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 in Health Monitor, verrà visualizzato un messaggio di avviso come 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 contenute nel messaggio di avviso. Assicurati che sia stato raggiunto il conteggio MaxFailure per un server di destinazione utilizzato nel proxy API specifico per il quale visualizzi il codice di risposta 503 con codice di errore NoActiveTargets.
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

Se riesci a connetterti al server di backend, potresti visualizzare un messaggio come Connesso a backend-server. Potrebbe quindi trattarsi di un problema temporaneo risolto oppure intermittente. Ripeti il passaggio 4 alcune volte (almeno 10 volte) e verifica l'output.

Se il comando telnet non presenta regolarmente errori, il problema è stato risolto. Ricontrolla se gli errori del controllo di integrità sono stati interrotti. Se sì, non devi fare altro.
Se non riesci a connetterti al server di backend con il comando telnet a intermittenza, è possibile che si sia verificato un problema di rete o che il server di backend sia occupato.

Se non riesci a connetterti al server di backend con il comando telnet in modo coerente, è possibile che il traffico non sia consentito dai processori di messaggi sul server di backend specifico.

Risoluzione

Se l'errore connection timed out viene osservato costantemente, assicurati che il server di backend non abbia limitazioni del 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, rivolgiti all'amministratore di rete per individuarlo e risolverlo. Se hai bisogno di ulteriore assistenza da parte di Apigee, contatta l'assistenza Apigee.

Causa: richiesta protetta su porta non protetta

Diagnostica

Determina l'ID del messaggio della richiesta non riuscita.
Cerca l'ID messaggio nel log dell'elaboratore di messaggi (/opt/apigee/var/log/edge-message-processor/logs/system.log).

Vedrai 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 eventuali errori di 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 MaxFailure numero di volte configurato in Health Monitor, verrà visualizzato un messaggio di avviso come questo:

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 sia stato raggiunto il conteggio MaxFailure per un server di destinazione utilizzato nel proxy API specifico per il quale visualizzi il codice di risposta 503 con codice di errore NoActiveTargets.

Il controllo di integrità non è riuscito a causa dell'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 protetta (HTTPS) sulla porta non protetta 80.

Questo errore può verificarsi nei seguenti due scenari:
- Server di destinazione sicuro definito con una porta non sicura
- È stato definito un server di destinazione sicuro, ma Health Monitor è configurato con una porta non sicura
Porta non sicura di destinazione sicura

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

Se hai definito un server di destinazione sicuro ma con una porta non protetta come 80, viene visualizzato questo errore. Procedi nel seguente modo per verificare se il problema è causato da questa:
1. Controlla la definizione del server di destinazione utilizzato nella configurazione dell'endpoint di destinazione.
2. Ora, controlla la configurazione di Health Monitor per il server di destinazione nella configurazione dell'endpoint di destinazione:
  Configurazione monitoraggio 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 è stato specificato alcun elemento <Port> nella configurazione del monitoraggio integrità riportata sopra. In questo caso, il processore di messaggi di Edge utilizza la porta specificata nella definizione del server di destinazione (80) per effettuare chiamate all'API per il controllo di integrità.
3. In base alle informazioni riportate sopra, la causa di questo errore è che il server di destinazione è definito come server protetto (poiché è attivato il blocco SSLInfo), ma con una porta non protetta 80.
Porta HM non sicura di destinazione sicura

Scenario 2: server di destinazione sicuro definito, ma Health Monitor configurato con una porta non sicura

Se hai definito un server di destinazione sicuro, ma il Monitoraggio integrità è configurato con una porta non protetta come 80, viene visualizzato questo errore. Segui i passaggi riportati di seguito per verificare se il problema è causato da questa:
1. Controlla la definizione del server di destinazione utilizzato nella configurazione dell'endpoint di destinazione.
  Utilizza l' API 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. Quindi, controlla la configurazione di Health Monitor per il server di destinazione nella configurazione dell'endpoint di destinazione:
  Configurazione monitoraggio 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, la causa di questo errore è che il server di destinazione è definito come server protetto (poiché il blocco SSLInfo è abilitato) e utilizza la porta protetta 443, ma il Monitoraggio integrità è configurato per eseguire i controlli di integrità con una porta non sicura 80 (specificata nell'elemento <Port>).
  Cioè, in questo caso, Edge effettua le API per il controllo di integrità come una chiamata sicura con porta non sicura 80 e non riesce con l'errore riportato sopra.
  
  Nota: l'elemento <Port> configurato nel monitoraggio dell'integrità ha la precedenza sulla porta utilizzata nella definizione del server di destinazione.

Risoluzione

Porta non sicura di destinazione sicura

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

Per correggere questo errore, aggiorna la definizione del server di destinazione in modo che utilizzi una porta protetta appropriata.

Utilizza Aggiorna un'API TargetServer per aggiornare la definizione del server di destinazione e assicurati che venga utilizzata una porta sicura (ad esempio 443) , come mostrato nell'esempio seguente:

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

Porta HM non sicura di destinazione sicura

Scenario 2: server di destinazione sicuro definito, ma Health Monitor configurato con una porta non sicura

Per correggere questo errore:

Modifica la configurazione del monitoraggio dell'integrità in modo che utilizzi una porta sicura (ad esempio 443) per eseguire i controlli di integrità del server di destinazione nella configurazione dell'endpoint di destinazione del proxy API con errori, come mostrato di seguito:

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

Salva le modifiche apportate al proxy API.

Causa: richiesta non sicura su una porta protetta

Diagnostica

Determina l'ID del messaggio della richiesta non riuscita.
Cerca l'ID messaggio nel log dell'elaboratore di messaggi (/opt/apigee/var/log/edge-message-processor/logs/system.log).

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 MaxFailure numero di volte configurato in Health Monitor, verrà visualizzato un messaggio di avviso come questo:

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}

Il controllo di integrità non è riuscito a causa dell'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 protetta (HTTP) sulla porta protetta 443.

Questo errore può verificarsi nei seguenti due scenari:
- Server di destinazione non sicuro definito con porta protetta
- È stato definito un server di destinazione non sicuro, ma è stato configurato Health Monitor con una porta sicura
Porta protetta di destinazione non sicura

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

Se hai definito un server di destinazione non sicuro ma con una porta protetta come 443, viene visualizzato questo errore. Procedi nel seguente modo per verificare se il problema è causato da questa:
1. Controlla la definizione del server di destinazione utilizzato nella configurazione dell'endpoint di destinazione.
  Utilizza l' API 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 protetto in quanto non è presente un blocco SSLInfo. Tuttavia, è configurato in modo errato con una porta sicura 443.
2. Ora, controlla la configurazione di Health Monitor per il server di destinazione nella configurazione dell'endpoint di destinazione:
  Configurazione monitoraggio 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 è stato specificato alcun elemento <Port> nella configurazione del monitoraggio integrità riportata sopra. In questo caso, il processore di messaggi di Edge utilizzerà la porta specificata nella definizione del server di destinazione, ovvero 443.
3. In base alle informazioni riportate sopra, la causa di questo errore è che il server di destinazione è definito come un server non protetto (poiché non è definito il blocco SSLInfo), ma con una porta protetta 443.
  In altre parole, Edge effettua i controlli di integrità come una chiamata non sicura con la porta sicura 443 e non riesce con l'errore riportato sopra.
Porta HM sicura di destinazione non sicura

Scenario 2: server di destinazione non sicuro definito, ma Health Monitor configurato con una porta sicura

Se hai definito un server di destinazione non sicuro, ma il Monitoraggio integrità è configurato con una porta protetta, ad esempio 443, viene visualizzato questo errore. Procedi nel seguente modo per verificare se il problema è causato da questa:
1. Controlla la definizione del server di destinazione utilizzato nella configurazione dell'endpoint di destinazione.
  Utilizza l' API 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 protetto (in quanto non esiste un blocco SSLInfo) configurato con una porta non protetta 80 correttamente.
2. Quindi, controlla la configurazione di Health Monitor per il server di destinazione nella configurazione dell'endpoint di destinazione:
  Configurazione monitoraggio 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 sicura 443, 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 una porta non protetta 80, ma il Monitoraggio integrità è configurato per eseguire i controlli di integrità con una porta protetta 443 (specificata nell'elemento <Port>).
  Cioè, in questo caso, Edge esegue i controlli di integrità come una chiamata non sicura con porta sicura 443 e non riesce con l'errore riportato sopra.

Risoluzione

Porta protetta di destinazione non sicura

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

Per correggere questo errore, aggiorna la definizione del server di destinazione in modo che utilizzi una porta protetta appropriata.

Utilizza l' API Target Server per aggiornare la definizione del server di destinazione e assicurarti che venga utilizzata una porta non sicura (ad es. 80) come mostrato nell'esempio seguente:

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

Porta HM sicura di destinazione non sicura

Scenario 2: server di destinazione non sicuro definito, ma Health Monitor configurato con una porta sicura

Per correggere questo errore:

Rimuovi l'elemento <Port> dalla configurazione del monitoraggio integrità o modifica la configurazione di monitoraggio integrità in modo da utilizzare una porta non sicura (ad esempio: 80) per eseguire i controlli di integrità del server di destinazione nella configurazione dell'endpoint di destinazione del proxy API con errori, come mostrato di seguito:

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

Salva le modifiche apportate al proxy API.

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

Diagnostica

Determina l'ID del messaggio della richiesta non riuscita.
Cerca l'ID messaggio nel log dell'elaboratore di messaggi (/opt/apigee/var/log/edge-message-processor/logs/system.log).
Vedrai 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 eventuali errori/avvisi di HEALTH MONITOR.
Ad esempio, potresti visualizzare un 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 configurato in Health Monitor, verrà visualizzato un messaggio di avviso come questo:
```
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 sia stato raggiunto il conteggio MaxFailure per un server di destinazione utilizzato nel proxy API specifico per il quale visualizzi il codice di risposta 503 con codice di errore NoActiveTargets.
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. Di conseguenza, l'operazione viene considerata come un errore.
Prima di indagare sulla causa della risposta di errore dall'API per il controllo di integrità, determina il motivo per cui Edge prevede che il codice di risposta sia 200 per l'API per il controllo di integrità. Per questo, controlla la configurazione di Health Monitor per il server di destinazione nella configurazione dell'endpoint di destinazione:
Configurazione monitoraggio 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>
        
```
Nota che la configurazione di Monitoraggio integrità è configurata con il codice di risposta 200 sotto l'elemento <SuccessResponse>. Ciò significa che se Edge riceve dall'API per il controllo di integrità un codice di risposta (ad esempio 400, 401, 404, 500) diverso da 200, verrà considerato un errore e incrementa il numero di errori.
Ora, per esaminare la causa della risposta di errore dall'API per il controllo di integrità, segui questi passaggi:

Esamina il messaggio che precede il 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 per il controllo di integrità indicato in questo messaggio.

Puoi effettuare una chiamata diretta a questo URL dal processore di messaggi e verificare la risposta effettiva.
```
curl -i https://mocktarget.apigee.net:443/status/200
          
```
La risposta alla chiamata riportata sopra restituisce un errore 404, come indicato nei log del processore di messaggi:
```
< HTTP/2 404
          
```
Questo dimostra che anche la chiamata diretta all'URL del controllo di integrità ha esito negativo con lo stesso codice di risposta 404. Ciò significa che l'URL per il controllo di integrità potrebbe non essere corretto o che la risorsa a cui si accede come parte dell'URL non è più disponibile.
Nell'API per il controllo di integrità di esempio fornita in precedenza, il problema si verifica perché è stato utilizzato un URL non corretto nella configurazione di Health Monitor. Abbiamo rilevato che l'URL corretto è https://mocktarget.apigee.net:443/statuscode/200 dall'API target fittizia.

Se ricevi altre risposte di errore, determinane la causa seguendo i passaggi precedenti. Se necessario, collabora con il team di backend.

Risoluzione

Risolvi il problema con l'API per il controllo di integrità sul server di backend.
Per risolvere il problema nell'esempio discusso sopra:

Modifica l'elemento <Path> nella configurazione di Monitoraggio integrità in /statuscode/200 come mostrato di seguito:
```
<Path>/statuscode/200</Path>
        
```
Salva le modifiche nel proxy API.

Se il problema persiste, consulta la pagina Raccogliere informazioni diagnostiche.

Diagnostica i problemi utilizzando il monitoraggio delle API

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

Illustra uno scenario di esempio che illustra come risolvere i problemi 5xx relativi alle tue API utilizzando API Monitoring. Ad esempio, potresti voler configurare un avviso per ricevere una notifica quando il numero di errori messaging.adaptors.http.flow.NoActiveTargets supera una determinata soglia.

Devi raccogliere dati diagnostici

Se il problema persiste anche dopo aver seguito le istruzioni riportate sopra, raccogli le seguenti informazioni diagnostiche. Contatta e inviale all'assistenza Apigee:

Se sei un utente del cloud pubblico, fornisci le seguenti informazioni:

Nome organizzazione
Nome ambiente
Nome proxy API
Completa il comando curl per riprodurre l'errore
File di traccia contenente le richieste con il servizio 503 non disponibile con il codice di errore NoActiveTarget

Se sei un utente del cloud privato, fornisci le seguenti informazioni:
1. Rilevato messaggio di errore completo
2. Nome ambiente
3. Bundle del proxy API
4. File di traccia contenente le richieste con il servizio 503 non disponibile con il codice di errore NoActiveTarget
5. Log degli accessi 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)