Errore 503 Servizio non disponibile con TARGET_CONNECT_TIMEOUT (target di peering di internet e VPC)

Stai visualizzando la documentazione di Apigee e Apigee hybrid.
Non esiste una documentazione Apigee Edge equivalente per questo argomento.

Sintomo

Questo problema viene visualizzato come errori "503 - Service Unavailable" in API Monitoring, Debug o altri strumenti. Il motivo "TARGET_CONNECT_TIMEOUT" indica un timeout della connessione tra l'istanza Apigee e la destinazione internet o una destinazione raggiungibile con il peering VPC.

L'errore non deve essere confuso con altri errori di timeout, ad esempio 504 Gateway Timeout.

Messaggio di errore

Questo è l'errore tipico nella sessione di debug o nel payload della risposta. Tieni presente il motivo: TARGET_CONNECT_TIMEOUT.

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

Possibili cause

Tieni presente che queste cause sono specifiche per le destinazioni internet o le destinazioni raggiungibili con il peering VPC. Vedi Opzioni di rete Apigee. Se la destinazione è PSC (collegamento endpoint), consulta il playbook PSC.

Causa	Descrizione
Errata configurazione delle route	Le route di destinazione non vengono esportate nel peering con l'istanza Apigee.
Problema di connettività nella destinazione	La destinazione non è sempre in grado di accettare una connessione TCP.
Inserimento nella lista consentita di IP nella destinazione con alcuni o tutti gli IP NAT di Apigee non aggiunti	Non tutti gli indirizzi IP NAT Apigee sono inclusi nella lista consentita nella destinazione.
Esaurimento delle porte IP NAT	Porte NAT insufficienti per il traffico.
Il valore di connect.timeout.millis è impostato su un valore troppo basso	L'impostazione del timeout della connessione è troppo bassa sul lato Apigee.

Passaggi comuni per la diagnostica

Debug è uno strumento essenziale per acquisire e valutare i seguenti dettagli del problema:

• La durata totale della richiesta. In genere, sono necessari tre secondi (valore predefinito connect.timeout.millis) prima che si verifichi un timeout della connessione. Se noti una durata inferiore, controlla la configurazione dell'endpoint di destinazione.
• Il nome host di destinazione e l'indirizzo IP. L'indirizzo IP errato visualizzato potrebbe indicare un problema relativo al DNS. Potresti anche notare una correlazione tra diversi IP di destinazione e il problema.
• Frequenza. A seconda che il problema sia intermittente o persistente, sono necessari approcci diversi.

Causa: configurazione errata della route

Diagnosi

Se il problema persiste, anche se è iniziato di recente, potrebbe essere causato da un'errata configurazione della route.

Ciò potrebbe influire sia sulle destinazioni interne (instradate all'interno del VPC con peering) sia su quelle esterne (internet).

1. Innanzitutto, identifica l'indirizzo IP del target risolto dall'istanza Apigee. Uno dei metodi consiste nell'utilizzare una sessione di debug. In Debug, vai ad AnalyticsPublisher (o AX in Debug classico):
   
   

   Cerca il valore target.ip sul lato destro dello schermo.

   In questo esempio, l'IP è 10.2.0.1. Poiché questo intervallo è privato, richiede l'implementazione di determinate misure di routing per garantire che Apigee possa raggiungere la destinazione.

   Tieni presente che se la destinazione si trova su internet, devi seguire questo passaggio se i Controlli di servizio VPC sono abilitati per Apigee, poiché impediscono la connettività a internet.

2. Prendi nota della regione in cui è stato eseguito il deployment dell'istanza Apigee interessata. Nell'interfaccia utente Apigee nella console Cloud, fai clic su Istanze. Nel campo Località, puoi trovare la regione esatta dell'istanza.
   
   
   
3. Nel progetto in peering con Apigee, vai alla sezione Peering di rete VPC -> Rete VPC nell'interfaccia utente. Tieni presente che se utilizzi il VPC condiviso, questi passaggi devono essere eseguiti nel progetto host anziché nel progetto Apigee.
   
   
4. Fai clic su servicenetworking-googleapis-com, seleziona la scheda ROUTE ESPORTATE e filtra in base alla regione ottenuta nel passaggio 2.
   
   Questo esempio mostra la route 10.2.0.0/24 esportata e include l'IP di destinazione di esempio 10.2.0.1. Se non vedi un percorso corrispondente al tuo target, questo è il motivo del problema.
   
   Nota: se la destinazione è esterna, in genere le route non sono presenti in Exported Routes e le richieste Apigee vengono instradate direttamente a internet. Potrebbe non essere sempre così, quindi assicurati di chiarire la topologia di rete desiderata. Ad esempio, se sono abilitati i Controlli di servizio VPC, devi anche esportare le route predefinite o altre route per raggiungere le destinazioni esterne.
   
   

Risoluzione

Rivedi l'architettura di rete e assicurati che le route vengano esportate nel peering VPC con Apigee. Molto probabilmente la route mancante è statica o dinamica. La mancanza delle route dinamiche necessarie indica un problema con la funzionalità corrispondente, ad esempio Cloud Interconnect.

Tieni presente che il peering transitivo non è supportato. In altre parole, se la rete VPC N1 è in peering con N2 e N3, ma N2 e N3 non sono connesse direttamente, la rete VPC N2 non può comunicare con la rete VPC N3 tramite peering di rete VPC.

Per ulteriori informazioni, leggi Pattern di networking verso sud.

Causa: problema di connettività nella destinazione

Diagnosi

Il target potrebbe non essere raggiungibile dal VPC o non essere in grado di accettare una connessione. Sono disponibili due opzioni per diagnosticare il problema.

Test di connettività (indirizzi IP di destinazione privati)

Se la destinazione si trova in una rete privata, puoi utilizzare la funzionalità Test di connettività per diagnosticare le cause comuni.

1. Identifica l'indirizzo IP della destinazione risolto dall'istanza Apigee. Uno dei metodi è utilizzare una sessione Debug.
   
   In Debug, vai ad AnalyticsPublisher (o AX in Debug classico). Cerca il valore target.ip sul lato destro dello schermo.
   
   In questo esempio, l'IP è 10.2.0.1. Si tratta di un indirizzo IP privato, il che significa che possiamo utilizzare il test di connettività.
   
   
2. Prendi nota dell'indirizzo IP dell'istanza Apigee che non riesce a connettersi alla destinazione. In Istanze nella console Apigee, trova l'indirizzo IP dell'istanza Apigee nel campo Indirizzo IP.
   
   
3. Vai a Connectivity Tests e fai clic su Crea test di connettività. Fornisci questi dettagli:
   1. Indirizzo IP di origine:utilizza l'IP dell'istanza Apigee ottenuto nel passaggio 2 precedente. Tieni presente che questo non è l'IP di origine esatto utilizzato da Apigee per inviare una richiesta alla destinazione, ma è sufficiente per il test, in quanto si trova nella stessa subnet.
   2. Questo è un indirizzo IP utilizzato in Google Cloud: lascia la casella deselezionata a meno che l'indirizzo non si trovi in uno dei tuoi progetti Google Cloud. Se controlli questo valore, fornisci anche il progetto e la rete.
   3. Inserisci l'indirizzo di destinazione (passaggio 1) e la porta come Indirizzo IP di destinazione e Porta di destinazione rispettivamente.
   
4. Fai clic su Crea e attendi il completamento della prima esecuzione del test.
5. Nell'elenco dei test di connettività, fai clic su Visualizza per vedere i risultati dell'esecuzione.
6. Se il risultato è "Non raggiungibile", significa che c'è un problema con la configurazione. Lo strumento dovrebbe indirizzarti alla documentazione sugli stati dei test di connettività per procedere. Se lo stato è "Raggiungibile", vengono esclusi molti problemi di configurazione. Tuttavia, questa non è una garanzia che la destinazione sia raggiungibile. Non è stato effettuato alcun tentativo di stabilire una connessione TCP con la destinazione. Solo la diagnosi successiva riportata di seguito ti aiuterà a testare questa ipotesi.
   
   

Test di connettività VM (tutti i target)

1. Nello stesso VPC sottoposto a peering con Apigee, crea un'istanza VM su Linux.
2. Esegui test di connettività dalla VM, preferibilmente nel momento in cui il problema è riproducibile da Apigee. Puoi utilizzare telnet, curl e altre utilità per stabilire una connessione. Questo esempio di curl viene eseguito in un ciclo con un timeout di tre secondi. Se curl non riesce a stabilire una connessione TCP in tre secondi, l'operazione non va a buon fine.

   for i in {1..100}; do curl -m 3 -v -i https://[TARGET_HOSTNAME] ; sleep 0.5 ; done

3. Controlla l'output completo e cerca questo errore:

   * Closing connection 0
    curl: (28) Connection timed out after 3005 milliseconds

   La presenza di questo errore conferma che il problema è riproducibile al di fuori di Apigee.

   Tieni presente che se visualizzi altri errori, ad esempio errori relativi a TLS, codici di stato non validi e così via, non confermano il timeout della connessione e non sono correlati a questo problema.

4. Se la destinazione richiede l'inserimento nella lista consentita degli IP, potresti non essere in grado di testarla da una VM, a meno che tu non inserisca nella lista consentita anche l'IP di origine dell'istanza VM.

Risoluzione

Se hai identificato un problema in base a Connectivity Tests, procedi con i passaggi di risoluzione documentati.

Se il timeout viene riprodotto da una VM, non esistono indicazioni precise su come risolvere il problema sul lato di destinazione. Una volta che il timeout della connessione è riproducibile al di fuori di Apigee, approfondisci il problema dal VPC. Cerca di testare la connettività il più vicino possibile alla destinazione.

Se la destinazione si trova dietro una connessione VPN, potresti essere in grado di testarla anche dalla rete locale.

Se la destinazione si trova su internet, puoi provare a riprodurre il problema al di fuori della console Google Cloud.

Se il problema si verifica nelle ore di punta, la destinazione potrebbe essere sovraccarica di connessioni.

Se a questo punto devi aprire una richiesta di assistenza Google Cloud, non devi più selezionare il componente Apigee, poiché il problema è ora riproducibile direttamente dal VPC.

Causa: lista consentita IP nella destinazione con alcuni o tutti gli IP NAT Apigee non aggiunti

Diagnosi

Ciò riguarda i target esterni (internet) per i quali è abilitata la lista consentita di IP. Assicurati che tutti gli IP NAT Apigee siano aggiunti al lato di destinazione interessato. Se non è presente alcuna lista consentita nel target, puoi saltare questa sezione.

Il problema è più facile da individuare se gli errori sono intermittenti, perché in questo caso potresti essere in grado di trovare una correlazione tra determinati IP NAT e gli errori.

Se il problema persiste (tutte le chiamate non vanno a buon fine), assicurati che gli IP NAT siano abilitati su Apigee e recuperali con questa procedura:

Elenca gli IP NAT per un'istanza:

curl -H "Authorization: Bearer $TOKEN" \
"https://apigee.googleapis.com/v1/organizations/$ORG_ID/instances/$INSTANCE_NAME/natAddresses"

Esempio di risposta:

{
  "natAddresses": [
    {
      "name": "nat-1",
      "ipAddress": "35.203.160.18",
      "state": "ACTIVE"
    },
    {
      "name": "nat-2",
      "ipAddress": "35.230.14.174",
      "state": "RESERVED"
    }
  ]
}

Se non ricevi indirizzi nell'output, gli IP NAT non vengono aggiunti lato Apigee. Se ottieni indirizzi, ma nessuno è ATTIVO, significa che nessuno degli indirizzi utilizzati consente l'accesso a internet, il che è un problema.

Se hai almeno un indirizzo ATTIVO, può essere inserito nella lista consentita nella destinazione, quindi non si verifica un errore di configurazione lato Apigee. In questo caso, l'indirizzo potrebbe non essere presente nella lista consentita della destinazione.

Se il problema è intermittente, è possibile che solo un sottoinsieme di IP NAT sia stato inserito nella lista consentita nella destinazione. Per identificarlo:

1. Crea un nuovo proxy inverso in cui la destinazione interessata è specificata in TargetEndpoint. Puoi anche riutilizzare il proxy esistente e passare al passaggio successivo:
   
   
2. Aggiungi una policy ServiceCallout al pre-flusso della richiesta. ServiceCallout deve chiamare "https://icanhazip.com", "https://mocktarget.apigee.net/ip" o qualsiasi altro endpoint pubblico che restituisce l'indirizzo IP del chiamante nella risposta. Memorizza la risposta nella variabile "response" in modo che i contenuti siano visibili in Debug. Ecco un esempio di configurazione del criterio ServiceCallout:
   

   <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
   <ServiceCallout continueOnError="false" enabled="true" name="Service-Callout-1">
       <DisplayName>Service Callout-1</DisplayName>
       <Properties/>
       <Request clearPayload="true" variable="myRequest">
           <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
       </Request>
       <Response>response</Response>
       <HTTPTargetConnection>
           <Properties/>
           <URL>https://icanhazip.com</URL>
       </HTTPTargetConnection>
   </ServiceCallout>

   Puoi anche archiviare la risposta in una variabile personalizzata, ma devi leggere ".content" di quella variabile con il criterio AssignMessage per visualizzarla nello strumento di debug.

   Assicurati che la destinazione sia configurata esattamente come nel proxy interessato.

   Nota: la richiesta ServiceCallout e la richiesta Target devono avvenire in un'unica transazione. In questo modo, la stessa richiesta viene elaborata dallo stesso server, in modo che l'IP NAT della richiesta interessata corrisponda all'IP NAT ottenuto da ServiceCallout.
3. Esegui una sessione di debug e fai clic sul passaggio ServiceCallout:
   
   
4. Nell'angolo in basso a destra, dovresti vedere una sezione Contenuto della risposta che contiene l'IP NAT (nel corpo) dell'istanza Apigee che effettua la richiesta. In alternativa, se memorizzi la risposta ServiceCallout in un'altra posizione, dovresti vederla lì.
   
   Tieni presente che, più avanti nel flusso, il proxy chiamerà il target e il contenuto della risposta verrà sovrascritto con l'errore o una risposta dal target.
5. Prova a correlare gli IP NAT al problema. Se noti che solo determinati IP non vanno a buon fine, questo è un segnale che indica che alcuni IP, ma non tutti, sono inclusi nella lista consentita della destinazione.
6. Se non vedi una correlazione tra gli IP NAT e gli errori, ad esempio se lo stesso IP non riesce in una richiesta, ma non nell'altra, è molto probabile che non si tratti di un problema di lista consentita. Potrebbe trattarsi di un esaurimento NAT. Vedi Causa: esaurimento della porta IP NAT.

Risoluzione

Assicurati di aver provisionato e attivato gli IP NAT e che tutti siano stati aggiunti sul lato di destinazione.

Causa: esaurimento delle porte IP NAT

Diagnosi

Nota: questa causa non è comune ed è pertinente se il problema non è riproducibile dal tuo VPC o da qualsiasi altro luogo al di fuori di Apigee. Se non hai eseguito il test, segui le indicazioni della sezione Problema di connettività nella destinazione riportata sopra. Questa sezione non è pertinente anche se non utilizzi IP NAT.

Se il problema è riproducibile solo da Apigee e gli IP NAT vengono forniti per la tua organizzazione e si verifica contemporaneamente per target diversi, potresti esaurire le porte di origine NAT:

1. Prendi nota dell'intervallo di tempo del problema. Ad esempio: tutti i giorni tra le 17:58 e le 18:08.
2. Verifica se altri target sono interessati dal problema nello stesso periodo di tempo. L'altro target deve essere accessibile tramite internet e non deve essere ospitato nella stessa località del target originale interessato.
3. Stabilisci se gli errori si verificano solo al di sopra di un determinato volume di traffico in TPS. Per farlo, annota il periodo di tempo del problema e vai alla dashboard Rendimento proxy.
4. Prova a correlare la finestra temporale dell'errore con l'aumento delle transazioni medie al secondo (tps).

In questo esempio, le tps aumentano fino a 1000 alle 17:58. Supponendo che in questo esempio le 17:58 siano esattamente il momento in cui si verifica il problema e che il problema interessi due o più target non correlati, si tratta di un segnale di un problema di esaurimento NAT.

Risoluzione

Ricalcola i requisiti IP NAT seguendo le istruzioni riportate in Calcolo dei requisiti IP NAT statici.

Puoi anche aggiungere altri IP NAT e vedere se il problema si risolve. Tieni presente che l'aggiunta di altri IP potrebbe richiedere l'inserimento nella lista consentita di tutti i target.

Causa: il valore di connect.timeout.millis è impostato su un valore troppo basso

Diagnosi

Potresti aver configurato in modo errato il valore di timeout nel proxy.

Per verificare, vai al proxy interessato e controlla il TargetEndpoint in questione. Prendi nota della proprietà "connect.timeout.millis" e del relativo valore. Nell'esempio riportato di seguito, il valore è 50, ovvero 50 millisecondi, che di solito è troppo basso per garantire la creazione di una connessione TCP. Se vedi un valore inferiore a 1000, è probabilmente la causa del problema. Se non vedi la proprietà "connect.timeout.millis", il valore predefinito è impostato e la causa non è confermata.

Risoluzione

Correggi il valore di connect.timeout.millis, assicurandoti di annotare che le unità di tempo sono in millisecondi. Il valore predefinito è 3000, ovvero 3000 millisecondi. Per saperne di più, consulta il Riferimento per le proprietà degli endpoint.

Contatta l'assistenza per ulteriore supporto

Se il problema persiste dopo aver seguito le istruzioni riportate sopra, raccogli le seguenti informazioni diagnostiche per l'assistenza Google Cloud:

1. ID progetto e nome dell'organizzazione Apigee
2. Nome o nomi del proxy e l'ambiente
3. Intervallo di tempo in cui si è verificato il problema
4. Frequenza del problema
5. Nome host di destinazione
6. Sessione di debug con il problema
7. Risultato dei controlli eseguiti per le possibili cause sopra indicate. Ad esempio, l'output del comando curl da una VM