Stai visualizzando la documentazione relativa a Apigee e Apigee ibrido.
Non esiste una equivalente
Documentazione di Apigee Edge per questo argomento.
Sintomo
Questo problema viene visualizzato come "503 - Servizio non disponibile" errori relativi a Monitoraggio delle API Debug o altro i nostri strumenti. "TARGET_CONNECT_TIMEOUT" indica un timeout della connessione l'istanza Apigee e la destinazione quando si utilizza il peering VPC.
L'errore non deve essere confuso con altri errori di timeout, come 504 Gateway Timeout (Timeout del gateway).
Messaggio di errore
Si tratta dell'errore tipico nella sessione di debug o nel payload della risposta. Nota 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 la configurazione di Apigee con peering VPC. Consulta Opzioni di networking Apigee. Se il target è PSC (Endpoint Allegato), consulta la guida pratica di PSC .
Causa | Descrizione |
---|---|
Configurazione errata delle route | Le route di destinazione non vengono esportate nel peering con l'istanza Apigee. |
Problema di connettività nell'obiettivo | La destinazione non è sempre in grado di accettare una connessione TCP. |
Lista consentita degli IP nella destinazione con alcuni o tutti gli IP Apigee NAT non aggiunti | Non tutti gli IP Apigee NAT sono nella lista consentita nella destinazione. |
Esaurimento delle porte IP NAT | Numero insufficiente di porte NAT per il traffico. |
Il valore diconnect.timeout.millis è impostato su un valore troppo basso | L'impostazione del timeout della connessione è troppo bassa sul lato Apigee. |
Passaggi diagnostici comuni
Il debug è un strumento essenziale per acquisire e valutare i seguenti dettagli del problema:
- Durata totale della richiesta. Di solito ci vogliono tre secondi (valore predefinito: connect.timeout.millis) fino al timeout della connessione. Se noti una durata inferiore, controlla la colonna Target Configurazione degli endpoint.
- Nome host e indirizzo IP di destinazione. 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. Sono necessari approcci diversi a seconda che il problema sia intermittente o permanente.
Causa: configurazione errata del percorso
Diagnosi
Se il problema persiste, anche se è iniziato di recente, potrebbe essere causato da un percorso e non è corretta.
Questo potrebbe influire sia su destinazioni interne (instradate all'interno di VPC in peering) sia su destinazioni esterne (internet).
-
Identifica innanzitutto l'indirizzo IP della destinazione risolta dall'istanza Apigee. Uno dei è utilizzare una funzione Debug durante la sessione. In Debug, vai ad AnalyticsPublisher (o AX nella versione classica di Debug):
Cerca il valore target.ip sul lato destro dello schermo.
In questo esempio, l'IP è 10.2.0.1. Poiché questo intervallo è privato, richiede alcune mettere in atto misure di routing per far sì che Apigee possa raggiungere il target.
Tieni presente che se il target è su Internet, devi seguire questo passaggio se Controlli di servizio VPC sono abilitate per Apigee, poiché ciò impedisce la connettività a internet.
- Osserva la regione in cui viene eseguito il deployment dell'istanza Apigee interessata. Nella
UI di Apigee nella console Cloud, fai clic su Istanze. Nel campo Località puoi
per trovare la regione esatta dell'istanza.
- Nel progetto in peering con Apigee, vai alla Rete VPC -> VPC
nella sezione peering di rete della UI. 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 il
ROUTE ESPORTATI e filtra in base alla regione ottenuta nel passaggio 2.
Questo esempio mostra la route 10.2.0.0/24 come esportata e include il target di esempio 10.2.0.1 IP. Se non vedi un percorso corrispondente al tuo target, è questo la causa del problema.
Risoluzione
Rivedi l'architettura di rete e assicurati che le route vengano esportate nel peering VPC con
Apigee. Molto probabilmente il percorso mancante è
statici o dinamici. Mancanza
di route dinamiche necessarie indica un problema con la caratteristica 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 collegate direttamente, rete VPC
N2 non può comunicare con la rete VPC N3 tramite peering di rete VPC.
Puoi leggere Pattern di networking verso sud per ulteriori informazioni.
Causa: problema di connettività nella destinazione
Diagnosi
La destinazione potrebbe non essere raggiungibile dal VPC o non essere in grado di accettare una connessione. Le due opzioni sono disponibili per diagnosticare il problema.
Connectivity Tests (indirizzi IP di destinazione privati)
Se la destinazione si trova su una rete privata, puoi utilizzare Test di connettività per diagnosticare le cause più comuni.
- Identifica l'indirizzo IP della destinazione risolta dall'istanza Apigee. Uno dei metodi è
per utilizzare una sessione di Debug.
In Debug, vai ad AnalyticsPublisher o ad AX nella versione classica di Debug. 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 Connectivity Tests.
- Prendi nota dell'indirizzo IP dell'istanza Apigee che non è in grado di connettersi alla destinazione.
In Istanze nella console Apigee, trova l'indirizzo IP dell'istanza Apigee in
nel campo Indirizzo IP.
- Vai a
Test di connettività
e fai clic su Crea test di connettività. Fornisci questi dettagli:
- Indirizzo IP di origine: utilizza l'IP dell'istanza Apigee ottenuto in Passaggio 2 qui sopra. Tieni presente che non si tratta dell'IP di origine esatto utilizzato da Apigee per inviare una richiesta alla destinazione, ma è sufficiente per il test, poiché si basa una subnet.
- Questo è un indirizzo IP usato in Google Cloud:lascia deselezionata questa opzione a meno che il parametro in uno dei tuoi progetti Google Cloud. Se selezioni questo valore, fornisci anche il valore progetto e rete.
- Inserisci l'indirizzo di destinazione (passaggio 1) e la porta come Indirizzo IP di destinazione e Porta di destinazione.
- Fai clic su Crea e attendi che il test termini la prima esecuzione.
- Nell'elenco dei test di connettività, fai clic su Visualizza per vedere i risultati dell'esecuzione.
-
Se il risultato è "Non raggiungibile", significa che hai un problema con
configurazione. Lo strumento dovrebbe indirizzarti alla
Documentazione sugli stati di Connectivity Tests
per procedere. Se lo stato è "Accessibile", sono esclusi molti problemi di configurazione.
Tuttavia, questo non garantisce che il target sia raggiungibile. Non c'è stato un vero e proprio
provare a stabilire una connessione TCP con la destinazione. Solo la prossima diagnostica riportata di seguito ti sarà utile
per testarlo.
Test di connettività delle VM (tutti i target)
- Nello stesso VPC in peering con Apigee, crea un'istanza VM su Linux.
- Esegui test di connettività dalla VM, preferibilmente nel momento in cui il problema
riproducibili da Apigee. Puoi usare telnet, curl e altre utilità per stabilire
connessione. Questo esempio di curl viene eseguito in un loop con un timeout di tre secondi. Se curl non è in grado di
stabilire una connessione TCP in tre secondi, non riesce.
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 vengono visualizzati 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 la lista consentita IP, potresti non essere in grado di testarla da una VM a meno che tu e inserire nella lista consentita anche l'IP di origine dell'istanza VM.
Risoluzione
Se hai identificato un problema in base ai Connectivity Tests, procedi con la documentazione passaggi per la risoluzione del problema.
Se il timeout viene riprodotto da una VM, non esistono indicazioni chiare su come risolvere sul lato target. Quando il timeout della connessione è riproducibile all'esterno di Apigee, a esaminare ulteriormente il problema dal VPC. Prova a verificare la connettività il più vicino alla destinazione possibile.
Se la destinazione è protetta da una connessione VPN, potresti essere in grado di testarla anche dalla rete locale in ogni rete.
Se la destinazione è su internet, potresti provare a riprodurre il problema all'esterno della console Google Cloud.
Se il problema si verifica nelle ore di punta, la destinazione potrebbe essere sovraccarica di connessioni.
Se hai bisogno di inviare una richiesta di assistenza per Google Cloud a questo punto non devi più selezionare il componente Apigee, poiché il problema ora riproducibili direttamente dal VPC.
Causa: lista consentita IP nella destinazione con alcune o tutte IP Apigee NAT non aggiunti
Diagnosi
Riguarda le destinazioni esterne (Internet) con la lista consentita degli IP abilitata. Assicurati che tutti gli IP Apigee NAT vengano aggiunti sul lato di destinazione interessato. In caso contrario, lista consentita nella destinazione, puoi saltare questa sezione.
Il problema è più facile da individuare se gli errori sono intermittenti, perché in tal caso potresti essere in grado di per 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 sono abilitati su Apigee e recuperarli seguendo questi passaggi:
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 sul lato Apigee. Se ricevi indirizzi, ma nessuno di questi è ATTIVO, poi nessuno degli indirizzi utilizzati consente l'accesso a a internet, il che rappresenta un problema.
Se almeno un indirizzo ATTIVO può essere inserito nella lista consentita per la destinazione, quindi non ci sono errori di configurazione su Apigee. In questo caso, l'indirizzo potrebbe non essere presente in nella lista consentita.
Se il problema è intermittente, potrebbe indicare che è stato eseguito solo un sottoinsieme di IP NAT nella lista consentita nella destinazione. Per identificarlo:
- Creare un nuovo proxy inverso in cui la destinazione interessata è specificata in TargetEndpoint. Tu
puoi anche riutilizzare il proxy esistente e andare al passaggio successivo:
- Aggiungi un criterio ServiceCallout in Request PreFlow. 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. Archivia la risposta nella "risposta" quindi
affinché il contenuto sia visibile 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 memorizzare la risposta in una variabile personalizzata, ma dovresti leggere il codice ".content" di quella variabile con il criterioAssignMessage per mostrarla nello strumento di debug.
Assicurati che la destinazione sia configurata nello stesso modo esatto del proxy interessato.
- Esegui una sessione di debug e fai clic sul passaggio ServiceCallout:
- Nell'angolo in basso a destra, dovresti vedere la sezione Contenuti della risposta,
contiene l'IP NAT (nel corpo) dell'istanza Apigee che effettua la richiesta.
In alternativa, se memorizzi la risposta ServiceCallout in una posizione diversa, dovresti vedere
li contiene.
Tieni presente che, più avanti nel flusso, il proxy chiamerà il target e il campo Risposta verranno sovrascritti con l'errore o una risposta del target. - Prova a correlare gli IP NAT al problema. Se noti che solo alcuni IP hanno errore, è un segnale che alcuni IP, ma non tutti, sono nella lista consentita nella destinazione.
- Se non vedi una correlazione tra gli IP NAT e gli errori, ad esempio se lo stesso indirizzo IP non riesce in una richiesta, ma non nell'altra, molto probabilmente non si tratta di un problema di inserimento nella lista consentita. Potrebbe trattarsi di un'esaurimento della funzionalità NAT. Vedi Causa: porta IP NAT esaurimento.
Risoluzione
Assicurati di aver eseguito il provisioning degli IP NAT e attivati e assicurati che vengano aggiunti tutti sul lato target.
Causa: esaurimento della porta IP NAT
Diagnosi
Se il problema è riproducibile solo da Apigee Viene eseguito il provisioning degli IP NAT dell'organizzazione e che avviene per obiettivi diversi nello stesso momento, potresti esaurire le porte di origine NAT:
- Prendi nota del periodo di tempo in cui si è verificato il problema. Ad esempio: ogni giorno tra le 17:58 e le 18:08.
- Verifica se altre destinazioni sono interessate dal problema nello stesso lasso di tempo. Quell'altro il target deve essere accessibile via Internet e non deve essere ospitato nella stessa località target originale interessato.
- Stabilisci se gli errori si verificano solo al di sopra di un determinato volume di traffico in TPS. A questo scopo, tieni presente di tempo in cui si è verificato il problema e passare Prestazioni del proxy Fitbit.com.
- Prova a correlare la finestra temporale dell'errore con l'aumento delle transazioni medie al secondo (tps).
In questo esempio, il tps sale a 1000 alle 17:58. Supponendo che in questo esempio le 17:58 siano esattamente nel momento in cui si verifica il problema e riguarda due o più obiettivi non correlati, segnale di un problema di esaurimento della funzionalità NAT.
Risoluzione
Ricalcola i requisiti IP NAT utilizzando le istruzioni in Calcolo dei requisiti IP NAT statici.
Puoi anche aggiungi altri IP NAT per vedere se il problema si risolve. Tieni presente che l'aggiunta di altri IP potrebbe richiedere l'inserimento nella lista consentita prima in tutti gli obiettivi.
Causa: il valore di connect.timeout.millis è impostato su un valore troppo basso
Diagnosi
Il valore di timeout potrebbe essere configurato in modo errato nel proxy.
Per verificare, vai al proxy interessato e controlla il TargetEndpoint in questione. Tieni presente
"connect.timeout.millis" e il suo valore. In questo esempio il valore è 50, che
è di 50 millisecondi e solitamente è troppo basso per garantire lo stabilire una connessione TCP. Se
un valore inferiore a 1000, probabilmente la causa del problema è questa. Se non vedi questo
"connect.timeout.millis" , viene impostato il valore predefinito e la causa non viene confermata.
Risoluzione
Correggi il valore connect.timeout.millis, assicurandoti che le unità di tempo siano in millisecondi. Il valore predefinito è 3000, ovvero 3000 millisecondi. Per ulteriori informazioni, vedi consulta il riferimento per le proprietà degli endpoint.
Contatta l'assistenza per ulteriore supporto
Se il problema persiste anche dopo aver seguito le istruzioni riportate sopra, raccogli i seguenti dati informazioni di diagnostica per l'assistenza Google Cloud:
- ID progetto e nome organizzazione Apigee
- Nomi del proxy e ambiente
- Periodo di tempo in cui si è verificato il problema
- Frequenza del problema
- Nome host di destinazione
- Sessione di debug con il problema
- Risultato dei controlli eseguiti per le possibili cause sopra indicate. Ad esempio, l'output
il comando
curl
da una VM