servizio non disponibile (503)

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
Risoluzione dei problemi relativi all'errore 503 del servizio non disponibile a causa di un problema del DNS	Scopri di più su quanto segue: Errore 503 Servizio non disponibile causato dalla risoluzione DNS e da problemi relativi alla rete in Apigee Edge Risolvere i problemi relativi a un servizio 503 non disponibile in tempo reale causato da un problema di risoluzione DNS
Risoluzione dei problemi relativi al servizio 503 non disponibile a causa di un problema di rete	Risoluzione dei problemi e risoluzione di un errore in tempo reale del servizio 503 non disponibile causato da un problema di rete in Apigee Edge

Sintomo

L'applicazione client riceve uno stato di risposta HTTP 503 con il messaggio Servizio non disponibile a seguito di una chiamata proxy API.

Messaggi di errore

Potresti visualizzare il seguente messaggio di errore:

HTTP/1.1 503 Service Unavailable
      

Puoi anche visualizzare il seguente messaggio di errore nella risposta HTTP:

Servizio non disponibile

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

Possibili cause

La risposta HTTP 503 Service available (Servizio non disponibile) con il codice di errore messaging.adaptors.http.flow.ServiceUnavailable si verifica se il processore di messaggi di Apigee Edge riscontra errori dovuti a timeout di connessione, nome host errato o errori di handshake SSL durante la comunicazione con il server di backend.

Le possibili cause della risposta 503 Service available (Servizio non disponibile) sono:

Causa	Descrizione	Chi può eseguire la procedura di risoluzione dei problemi
Errori di connessione dovuti a una risoluzione DNS errata	La risoluzione DNS del server di destinazione ha generato indirizzi IP errati che causano errori di connessione.	Utenti del cloud privato perimetrale
Errori di connessione	I problemi di rete o di connettività impediscono al client di connettersi al server.	Utenti del cloud privato perimetrale
Nome host del server di destinazione non corretto	L'host del server di destinazione specificato non è corretto o contiene caratteri indesiderati (ad esempio gli spazi).	Utenti di cloud pubblico e privato perimetrale
Errori di handshake SSL	L'handshake TLS/SSL tra client e server non è riuscito. La risoluzione dei problemi per questa classe di problemi viene trattata in un argomento a parte.	Utenti di cloud pubblico e privato perimetrale

Passaggi di diagnosi più comuni

Determinare l'ID messaggio della richiesta non riuscita

Errori di connessione dovuti a una risoluzione DNS errata

Diagnostica

1. Determinare l'ID messaggio della richiesta non riuscita.
2. Cerca l'ID messaggio della richiesta specifico nel log del processore di messaggi (/opt/apigee/var/log/edge-message-processor/logs/system.log). Potresti riscontrare i seguenti errori:
   
   Un errore onConnectTimeout indica che il processore di messaggi non è riuscito a connettersi al server di backend entro il periodo di timeout della connessione preimpostato (valore predefinito: 3 secondi).

   2019-08-14 09:11:49,314 org:myorg env:prod api:Employees rev:1 messageid:mo-96cf6757a-9401-21-1 NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context.onTimeout() : ClientChannel[Connected:]@164162 useCount=1 bytesRead=0 bytesWritten=0 age=3001ms lastIO=3001ms .onConnectTimeout connectAddress=www.abc.com/11.11.11.11  resolvedAddress=www.abc.com/22.22.22.22
   
   2019-08-14 09:11:49,333 org:myorg env:prod api:Employees rev:1 messageid:mo-96cf6757a-9401-21-1 NIOThread@0 ERROR ADAPTORS.HTTP.FLOW - RequestWriteListener.onTimeout() : RequestWriteListener.onTimeout(HTTPRequest@6b393600)
         

3. Prendi nota dell'indirizzo IP risolto nell'errore onConnectTimeout e controlla se l'indirizzo IP è valido per il server di backend. Se l'indirizzo IP è valido, vai a Errori di connessione.
4. Se l'indirizzo IP non è valido, è molto probabile che il problema sia dovuto a problemi di risoluzione del DNS.
5. Ripeti i passaggi 3 e 4 per alcune richieste API con errori e verifica se vedi indirizzi IP uguali o non validi.
6. Cercare nel log del processore di messaggi (/opt/apigee/var/log/edge-message-processor/logs/system.log) i messaggi con la parola chiave DNS refresh (Aggiorna DNS). Verifica se ogni tanto vengono aggiunti indirizzi IP non validi o non validi alla cache DNS del processore di messaggi.

   2019-08-14 09:11:49,314 org:myorg env:prod api:Employees rev:1 messageid:mo-96cf6757a-9401-21-1 NIOThread@0 INFO c.a.p.h.d.DNSCachedAddress - DNSCachedAddress.reportDifferences() : DNS Refresh for host: apitarget-uat.schemeweb.co.uk:4436. Added 2 IPs [www.abc.com/22.22.22.22, www.abc.com/33.33.33.33] Removed 1 IPs [www.abc.com/11.11.11.11]
         

7. Questo problema può verificarsi se ci sono problemi con i server DNS autorevoli o con i server dei nomi configurati in /etc/resolv.conf.
   
   In genere, potrebbero essere presenti uno o più server DNS autorevoli configurati per eseguire la risoluzione DNS. Se non esistono server DNS autorevoli, questo potrebbe ricorrere alla configurazione della configurazione in /etc/resolv.conf ed eseguire la risoluzione DNS a seconda dei casi. Ad esempio, se /etc/resolv.conf è configurato per l'utilizzo di server dei nomi specifici, questi verranno utilizzati per eseguire la risoluzione DNS.
8. In caso di problemi relativi ai server DNS o ai server dei nomi autorevoli specificati in /etc/resolv.conf, i nomi host del server di backend verranno risolti in indirizzi IP non validi o non validi. Gli indirizzi IP non validi o non validi verranno quindi memorizzati nella cache DNS del processore di messaggi.
   1. Se il problema con i server DNS o i server dei nomi autorevoli specificati in /etc/resolv.conf persiste, gli indirizzi IP non validi o non validi continueranno a rimanere nella cache DNS del processore di messaggi. Finché gli indirizzi IP errati sono archiviati nella cache DNS del processore di messaggi, le richieste per tutte le API che utilizzano il server di backend specifico avranno esito negativo con errore 503.
   2. Se il problema relativo ai server DNS autorevoli o ai server dei nomi specificati in /etc/resolv.conf è intermittente, gli indirizzi IP validi e non validi verranno memorizzati a intermittenza nella cache DNS. In questo caso, vedrai errori 503 a intermittenza per tutte le API che utilizzano il server di backend specifico.
9. Se il problema con i server DNS è persistente, vedrai errori continui. Se il problema con i server DNS è intermittente, si verificheranno errori intermittenti. In altre parole, ogni volta che il nome host del server di backend viene risolto in indirizzi IP non validi, riscontri errori 503. E quando i nomi host del server di backend vengono risolti con indirizzi IP validi, osserverai risposte positive.

Risoluzione

Rivolgiti all'amministratore del tuo sistema operativo e risolvi i problemi dei server DNS.

1. Se si verifica un problema con i server DNS o i server dei nomi autorevoli specificati in /etc/resolv.conf, correggilo con il server appropriato per risolverlo.
2. Se si verificano problemi di configurazione in /etc/resolv.conf sui sistemi con processori di messaggi, correggi il problema di configurazione.

Errori di connessione

Un errore di connessione si verifica quando un processore di messaggi Apigee Edge tenta di connettersi a un server di backend e si verifica uno dei seguenti problemi:

• Il processore di messaggi non è in grado di connettersi entro il periodo di timeout della connessione preimpostato. (valore predefinito: 3 secondi)
• Il server di backend rifiuta la connessione.

Diagnostica

1. Determinare l'ID messaggio della richiesta non riuscita.
2. Cerca l'ID messaggio della richiesta specifico nel log dell'elaboratore di messaggi (/opt/apigee/var/log/edge-message-processor/logs/system.log). Potresti notare i seguenti errori:
   1. Un errore onConnectTimeout indica che il processore di messaggi non è riuscito a connettersi al server di backend entro il periodo di timeout della connessione preimpostato.

      2016-06-23 09:11:49,314 org:myorg env:prod api:Employees rev:1 messageid:mo-96cf6757a-9401-21-1 NIOThread@2 ERROR HTTP.CLIENT - HTTPClient$Context.onTimeout() : ClientChannel[C:]@10 useCount=1 bytesRead=0 bytesWritten=0 age=3001ms lastIO=3001ms .onConnectTimeout connectAddress=www.abc.com/11.11.11.11:80 resolvedAddress=www.abc.com/11.11.11.11
      2016-06-23 09:11:49,333 org:myorg env:prod api:Employees rev:1 messageid:mo-96cf6757a-9401-21-1 NIOThread@2 ERROR ADAPTORS.HTTP.FLOW - RequestWriteListener.onTimeout() : RequestWriteListener.onTimeout(HTTPRequest@6b393600)
      

   2. Un errore java.net.ConnectEccezione: connessione rifiutata indica che la connessione è stata rifiutata dal server di backend.

      14:40:16.531 +0530
      2016-06-17 09:10:16,531 org:myorg env:prod api:www.abc.com rev:1 rrt07eadn-22739-40983870-15 NIOThread@2 ERROR HTTP.CLIENT - HTTPClient$Context.onConnectFailure() : connect to www.abc.com:11.11.11.11:443 failed with exception {}
      java.net.ConnectException: Connection refused
      at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method) ~[na:1.7.0_75]
      at sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:739) ~[na:1.7.0_75]
      at com.apigee.nio.ClientChannel.finishConnect(ClientChannel.java:121) ~[nio-1.0.0.jar:na]
      at com.apigee.nio.handlers.NIOThread.run(NIOThread.java:108) ~[nio-1.0.0.jar:na]
      

3. Verifica se riesci a connetterti al server di backend specifico direttamente da ciascuno dei processori di messaggi utilizzando il comando telnet:
   1. Se il server di backend si risolve in un singolo indirizzo IP, utilizza il seguente comando:

      telnet BackendServer-IPaddress 443
                

   2. Se il server di backend risolve più indirizzi IP, utilizza il nome host del server di backend nel comando telnet come mostrato di seguito:

      telnet BackendServer-HostName 443
                

4. Se riesci a connetterti al server di backend, potresti visualizzare un messaggio come Connected to backend-server. Se non riesci a connetterti al server di backend, è possibile che gli indirizzi IP dei processori di messaggi non siano inclusi nella lista consentita sul server di backend specifico.

Risoluzione

Concedi l'accesso agli indirizzi IP del processore di messaggi sul server di backend specifico per consentire al traffico proveniente dai processori di messaggi periferici di accedere al server di backend. Ad esempio, su Linux, puoi utilizzare iptables per consentire il traffico proveniente 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.

Nome host del server di destinazione non corretto

Diagnostica

Se il nome host specificato nel server di destinazione non è corretto, puoi ricevere la risposta 503 Servizio non disponibile con il codice di errore messaging.adaptors.http.flow.ServiceUnavailable.

Risoluzione

1. Assicurati che il nome host del server di destinazione specificato nella configurazione dell'endpoint di destinazione o nella definizione del server di destinazione sia corretto e non contenga spazi o caratteri speciali indesiderati.
2. Se utilizzi un qualsiasi criterio AssegnaMessage/JavaScript per generare in modo dinamico il nome host del server di destinazione, esamina la definizione del criterio e il codice e assicurati che il nome host del server di destinazione venga generato correttamente.

Errori di handshake SSL

Un intero playbook per la risoluzione dei problemi è dedicato agli errori di handshake TLS/SSL. Consulta la sezione Errori di handshake SSL.

Determinare l'origine del problema

Alcuni tipi di errori possono verificarsi sulla connessione in entrata (in direzione nord) o in uscita (in direzione sud). Si verifica un errore in entrata (northbound) tra l'applicazione client e Edge. Si verifica un errore in uscita (in direzione sud) tra Edge e il server di destinazione del backend. Per diagnosticare questo tipo di problemi, il primo compito è capire se l'errore si verifica sulla connessione in direzione nord o sud.

Capire le connessioni in direzione nord e sud

In Edge, puoi riscontrare un errore 503 Service Non disponibile sulla connessione in entrata o in uscita:

• Connessione in entrata (o in direzione nord): la connessione tra l'applicazione client e il router perimetrale. Il router è il componente di Apigee Edge che gestisce le richieste in entrata inviate al sistema.
• Connessione in uscita (o in direzione sud): la connessione tra il processore di messaggi Edge e il server di backend. Il processore di messaggi è un componente di Apigee Edge che esegue il proxy delle richieste API ai server di destinazione del backend.

Se sei un utente di Edge Public Cloud, probabilmente non conosci componenti interni come il router o il processore di messaggi. Questi componenti interni non sono visibili o accessibili agli utenti del cloud pubblico. Ove possibile, forniamo metodi alternativi per esaminare il problema che non richiedono l'accesso diretto a questi componenti.

La figura seguente illustra le connessioni in direzione nord e sud per Apigee Edge.

Individuazione della posizione in cui si è verificato l'errore 503 Servizio non disponibile

Utilizza una delle procedure seguenti per determinare se l'errore 503 Servizio non disponibile si è verificato con la connessione in direzione nord o sud.