Questa pagina è stata tradotta dall'API Cloud Translation.

Errore 503 servizio non disponibile del peering VPC con TARGET_CONNECT_TIMEOUT

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

Sintomo

Questo problema si manifesta sotto forma di errori "503 - Service Unavailable" in Monitoraggio API, Debug o altri strumenti. Il motivo "TARGET_CONNECT_TIMEOUT" indica un timeout della connessione tra l'istanza Apigee e il target quando si utilizza 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 Apigee configurato con il peering VPC. Consulta Opzioni di rete Apigee. Se la destinazione è PSC (collegamento endpoint), consulta invece il playbook PSC.

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

Passaggi di diagnostica comuni

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

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.
Nome host e indirizzo IP di destinazione. La visualizzazione dell'indirizzo IP errato potrebbe indicare un problema relativo al DNS. Potresti anche notare una correlazione tra diversi IP di destinazione e il problema.
Frequenza. Sono necessari approcci diversi a seconda che il problema sia intermittente o persistente.

Causa: configurazione errata della route

Diagnosi

Se il problema persiste, anche se si è verificato di recente, potrebbe essere causato da un'errata configurazione del percorso.

Ciò potrebbe interessare i target sia interni (instradati all'interno di un VPC con peering) sia esterni (internet).

Innanzitutto, identifica l'indirizzo IP del target risolto dall'istanza Apigee. Uno dei metodi è 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, è necessario implementare determinate misure di instradamento per garantire che Apigee possa raggiungere la destinazione.

Tieni presente che se la destinazione è su internet, devi seguire questo passaggio se i Controlli di servizio VPC sono abilitati per Apigee, poiché impediscono la connettività a internet.
Prendi nota della regione in cui è stato eseguito il deployment dell'istanza Apigee interessata. Nell'interfaccia utente di Apigee nella console Cloud, fai clic su Istanze. Nel campo Località, puoi trovare la regione esatta dell'istanza.
Nel progetto in peering con Apigee, vai alla sezione Rete VPC -> Peering di rete VPC nell'interfaccia utente. Tieni presente che se utilizzi VPC condiviso, questi passaggi devono essere eseguiti nel progetto host anziché nel progetto Apigee.
Fai clic su servicenetworking-googleapis-com, seleziona la scheda ROUTE ESEGUTE 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, significa che è la causa del problema.
Nota: se la destinazione è esterna, in genere i route non sono presenti in Route esportati e le richieste Apigee vengono instradate direttamente su internet. Non è sempre così, quindi assicurati di chiarire la topologia di rete che ti interessa. Ad esempio, se sono attivati i Controlli di servizio VPC, devi esportare anche le route predefinite o altre per raggiungere i target esterni.

Risoluzione

Esamina l'architettura di rete e assicurati che le route vengano esportate nel peering VPC con Apigee. Molto probabilmente il percorso mancante è statico o dinamico. La mancanza di 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 il peering di rete VPC.

Per ulteriori informazioni, consulta Pattern di networking verso sud.

Causa: problema di connettività al target

Diagnosi

La destinazione potrebbe non essere raggiungibile dal VPC o non essere in grado di accettare una connessione. Esistono 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 più comuni.

Identifica l'indirizzo IP della destinazione risolto dall'istanza Apigee. Uno dei metodi è 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. Si tratta di un indirizzo IP privato, il che significa che possiamo utilizzare il test di connettività.
Prendi nota dell'indirizzo IP dell'istanza Apigee che non riesce a connettersi al target. In Istanze nella console Apigee, trova l'indirizzo IP dell'istanza Apigee nel campo Indirizzo IP.
Vai a Connectivity Tests e fai clic su Crea test di connettività. Fornisci i seguenti dettagli:
1. Indirizzo IP di origine:utilizza l'indirizzo IP dell'istanza Apigee ottenuto nel passaggio 2 qui sopra. Tieni presente che non si tratta dell'indirizzo IP di origine esatto utilizzato da Apigee per inviare una richiesta al target, ma è sufficiente per il test, in quanto si trova nella stessa subnet.
2. Questo è un indirizzo IP utilizzato in Google Cloud: non selezionare l'opzione se l'indirizzo non si trova in uno dei tuoi progetti Google Cloud. Se selezioni questo valore, fornisci anche il progetto e la rete.
3. Inserisci l'indirizzo di destinazione (passaggio 1) e la porta rispettivamente come Indirizzo IP di destinazione e Porta di destinazione.
Fai clic su Crea e attendi il completamento della prima esecuzione del test.
Nell'elenco dei test di connettività, fai clic su Visualizza per visualizzare i risultati dell'esecuzione.
Se il risultato è "Impossibile da raggiungere", significa che c'è un problema con la configurazione. Lo strumento dovrebbe indirizzarti alla documentazione relativa agli stati dei test di connettività per procedere. Se lo stato è "Reachable" (Raggiungibile), vengono esclusi molti problemi di configurazione. Tuttavia, ciò non garantisce che la destinazione sia raggiungibile. Non è stato effettuato alcun tentativo di stabilire una connessione TCP con il target. Solo la prossima diagnosi riportata di seguito ti aiuterà a verificarlo.

Test di connettività della VM (tutti i target)

Nella stessa VPC in peering con Apigee, crea un'istanza VM su Linux.
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
```
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 errati e così via, non confermano il timeout della connessione e non sono correlati a questo problema.
Se la destinazione richiede l'inserimento nella lista consentita degli IP, potresti non essere in grado di eseguirne il test da una VM, a meno che non inserisci anche l'IP di origine dell'istanza VM nella lista consentita.

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 di connessione è riproducibile al di fuori di Apigee, esamina ulteriormente il problema dal VPC. Prova a testare la connettività il più vicino possibile al target.

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

Se la destinazione è su internet, puoi provare a riprodurre il problema all'esterno della console Google Cloud.

Se il problema si verifica nelle ore di punta, il target potrebbe essere sopraffatto dalle connessioni.

Se in questa fase devi aprire una richiesta all'assistenza Google Cloud, non devi più selezionare il componente Apigee, poiché il problema ora è riproducibile direttamente dal VPC.

Causa: lista consentita IP nel target con alcuni o tutti gli IP NAT di Apigee non aggiunti

Diagnosi

Questo riguarda i target esterni (internet) per i quali è attivata la lista consentita di IP. Assicurati che tutti gli IP NAT di Apigee siano aggiunti sul lato target 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 su Apigee siano abilitati gli IP NAT e recuperali seguendo 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, significa che gli IP NAT non sono stati aggiunti lato Apigee. Se ricevi indirizzi, ma nessuno è ACTIVE, significa che nessuno degli indirizzi utilizzati consente l'accesso a internet, il che rappresenta un altro problema.

Se hai almeno un indirizzo ATTIVO, può essere inserito nella lista consentita nel target, pertanto non è presente alcuna configurazione errata lato Apigee. In questo caso, l'indirizzo potrebbe non essere presente nella lista consentita nel target.

Se il problema è intermittente, potrebbe indicare che solo un sottoinsieme di IP NAT è stato inserito nella lista consentita nel target. Per identificarli:

Crea un nuovo proxy inverso in cui il target interessato è specificato in TargetEndpoint. Puoi anche riutilizzare il proxy esistente e passare al passaggio successivo:
Aggiungi un criterio ServiceCallout nel PreFlow 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. Questo è 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 memorizzare la risposta in una variabile personalizzata, ma devi leggere il ".content" di quella variabile con il criterio AssignMessage per visualizzarla nello strumento di debug.

Assicurati che la destinazione sia configurata nello stesso modo esatto del proxy interessato.

Nota: sia la richiesta ServiceCallout sia la richiesta Target devono essere eseguite in un'unica transazione. Questo serve ad assicurarti che lo stesso server elabori una richiesta in modo che l'IP NAT della richiesta interessata corrisponda all'IP NAT ottenuto da ServiceCallout.
Esegui una sessione di debug e fai clic sul passaggio ServiceCallout:
Nell'angolo in basso a destra, dovresti vedere una sezione Contenuti risposta che contiene l'IP NAT (nel corpo) dell'istanza Apigee che effettua la richiesta. In alternativa, se memorizzi la risposta di ServiceCallout in un altro posto, dovresti trovarla lì.

Tieni presente che, più avanti nel flusso, il proxy chiamerà il target e i contenuti della risposta verranno sovrascritti con l'errore o una risposta del target.
Prova a correlare gli IP NAT con il problema. Se noti che solo determinati IP non vanno a buon fine, è un segno che alcuni, ma non tutti, gli IP sono inclusi nella lista consentita nel target.
Se non noti una correlazione tra gli IP NAT e gli errori, ad esempio se lo stesso IP non funziona in una richiesta, ma nell'altra sì, è molto probabile che non si tratti di un problema con la lista consentita. Potrebbe trattarsi di un esaurimento del NAT. Vedi Causa: esaurimento della porta IP NAT.

Risoluzione

Assicurati di aver eseguito il provisioning e attivato gli IP NAT e che siano tutti aggiunti sul lato di destinazione.

Causa: esaurimento delle porte IP NAT

Diagnosi

Se il problema è riproducibile solo da Apigee e il provisioning degli IP NAT è stato eseguito per la tua organizzazione e si verifica contemporaneamente per target diversi, potresti non avere più porte di origine NAT:

Prendi nota dell'intervallo di tempo in cui si è verificato il problema. Ad esempio: ogni giorno tra le 17:58 e le 18:08.
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 posizione del target interessato originale.
Stabilisci se gli errori si verificano solo al di sopra di un determinato volume di traffico in TPS. Per farlo, prendi nota del periodo di tempo del problema e vai alla dashboard Rendimento proxy.
Prova a correlare la finestra temporale dell'errore con l'aumento delle transazioni medie al secondo (TPS).

In questo esempio, le ts/s aumentano a 1000 alle 17:58. Supponendo che in questo esempio le 17:58 sia esattamente il momento in cui si verifica il problema e che il problema riguardi due o più target non correlati, si tratta di un indicatore di un problema di esaurimento NAT.

Risoluzione

Ricalcula i requisiti per gli IP NAT utilizzando le istruzioni riportate in Calcolo dei requisiti per gli IP NAT statici.

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

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

Diagnosi

Il valore di timeout nel proxy potrebbe essere configurato in modo errato.

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, il valore è 50, ovvero 50 millisecondi, che in genere è troppo basso per garantire l'instaurazione di una connessione TCP. Se visualizza un valore inferiore a 1000, è probabile che sia la causa del problema. Se non vedi la proprietà "connect.timeout.millis", significa che è impostato il valore predefinito e la causa non è confermata.

Proxy con timeout

Risoluzione

Correggi il valore connect.timeout.millis, assicurandoti di notare che le unità di tempo sono in millisecondi. Il valore predefinito è 3000, ovvero 3000 millisecondi. Per ulteriori informazioni, 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 di diagnostica per l'assistenza Google Cloud:

ID progetto e nome dell'organizzazione Apigee
Nomi dei proxy e ambiente
Periodo di tempo del problema
Frequenza del problema
Nome host target
Sessione di debug con il problema
Risultato dei controlli eseguiti per le possibili cause sopra indicate. Ad esempio, l'output del comando curl da una VM