Google utilizza la tecnologia AI per tradurre i contenuti nella tua lingua preferita. Le traduzioni generate dall'AI potrebbero contenere errori.

Risolvere i problemi relativi ai bilanciatori del carico delle applicazioni esterni

Questa guida descrive come risolvere i problemi di configurazione per i bilanciatori del carico delle applicazioni esterni. Prima di esaminare i problemi, acquisisci familiarità con le seguenti pagine:

I backend hanno modalità di bilanciamento incompatibili

Quando crei un bilanciatore del carico, potresti visualizzare l'errore:

Validation failed for instance group INSTANCE_GROUP:

backend services 1 and 2 point to the same instance group
but the backends have incompatible balancing_mode. Values should be the same.

Ciò si verifica quando tenti di utilizzare lo stesso backend in due bilanciatori del carico diversi e i backend non hanno modalità di bilanciamento compatibili.

Per ulteriori informazioni, consulta le seguenti risorse:

Risolvere i problemi di connettività generali

Errori "5XX" inspiegabili

Un errore "HTTP 5XX" può essere restituito da un GFE di primo livello, da un GFE di secondo livello o da un backend, a seconda di dove si verifica la condizione di errore.

Questa sezione descrive come risolvere i problemi relativi agli errori 5XX che possono verificarsi in diverse fasi del processo di distribuzione delle richieste per i bilanciatori del carico delle applicazioni esterni basati su GFE.

Identificare l'origine degli errori "5XX" utilizzando Cloud Logging

Per le condizioni di errore causate da un problema di comunicazione tra il proxy del bilanciatore del carico e i relativi backend, il bilanciatore del carico genera un codice di risposta di errore HTTP (5XX) e lo restituisce al client. Non tutti gli errori HTTP 5XX vengono generati dal bilanciatore del carico. Ad esempio, se un backend invia una risposta HTTP 5XX al bilanciatore del carico, quest'ultimo la inoltra al client.

Per determinare se una risposta HTTP 5XX è stata inoltrata da un backend o se è stata generata dal proxy del bilanciatore del carico, controlla il campo statusDetails in Cloud Logging.

Se statusDetails è response_sent_by_backend, il bilanciatore del carico ha inoltrato la risposta 5XX dal backend. Risolvi il problema sui tuoi backend.
Se statusDetails è un altro messaggio di errore, la risposta 5XX viene generata dal bilanciamento del carico.

Le modifiche alla configurazione del bilanciatore del carico delle applicazioni esterno globale, come l'aggiunta o la rimozione di un servizio di backend, possono comportare un breve periodo di tempo in cui vengono visualizzate risposte HTTP 502 con statusDetails come failed_to_pick_backend. Questo è normale durante la propagazione delle modifiche alla configurazione ai GFE a livello globale.

Prima di iniziare la risoluzione dei problemi, verifica l'integrità del backend

Prima di risolvere i problemi relativi agli errori 5XX, verifica che i backend siano integri e che i controlli di integrità vengano superati. Se i backend non sono integri, il GFE di secondo livello non può inoltrare le richieste, il che può causare errori 5XX anche se tutto il resto è configurato correttamente.

Verifica che esista una regola firewall configurata per consentire i controlli di integrità. In assenza di uno, i controlli di integrità non riescono e i log del bilanciatore del carico potrebbero mostrare un statusDetails di failed_to_pick_backend.
Verifica che il traffico del controllo di integrità raggiunga le VM di backend. Per farlo, abilita il logging del controllo di integrità e cerca le voci di log riuscite. Per i nuovi bilanciatori del carico, potresti non visualizzare immediatamente le voci di log del controllo di integrità riuscito. Ciò potrebbe essere dovuto al fatto che lo stato di integrità iniziale del backend non è ancora cambiato da UNHEALTHY a uno diverso. Le voci di log del controllo di integrità riuscite sono visibili solo dopo che il prober del controllo di integrità riceve una risposta HTTP 200 OK dal backend.

Se i controlli di integrità non riescono, risolvi i problemi relativi all'applicazione di backend e alle regole firewall. Se i controlli di integrità vengono superati, ma continui a visualizzare errori 5XX, controlla il campo statusDetails in Cloud Logging per identificare l'origine dell'errore, come descritto nella sezione seguente.

Risolvere gli errori in base a `statusDetails`

Se gli errori HTTP 5XX persistono, utilizza il campo statusDetails in Cloud Logging per identificare la causa e risolvere il problema di conseguenza.

Il bilanciatore del carico delle applicazioni esterno globale e il bilanciatore del carico delle applicazioni esterno regionale generano codici di stato HTTP significativi, come HTTP 503 Service Unavailable e HTTP 504 Gateway Timeout.
Il bilanciatore del carico delle applicazioni classico utilizza sempre il codice di stato HTTP 502 Bad Gateway per tutti gli errori generati dal bilanciatore del carico.

statusDetails	Possibile causa e soluzione
`failed_to_pick_backend` `failed_to_pick_backend_by_hash`	Causa: il GFE del secondo livello non è riuscito a selezionare un backend integro a cui indirizzare la richiesta. Questo errore può verificarsi per uno dei seguenti motivi: Tutte le regioni hanno raggiunto o superato la capacità. Il bilanciatore del carico non riesce a trovare alcun backend disponibile in base all'hash calcolato. Il bilanciatore del carico non riesce a trovare backend corrispondenti alla configurazione del servizio. Soluzione: Verifica che i backend siano integri seguendo i passaggi descritti in Verifica l'integrità del backend. Assicurati che i controlli di integrità siano configurati correttamente con porta, percorso e protocollo giusti. Assicurati che le regole firewall di backend consentano il traffico del controllo di integrità dai prober del controllo di integrità `35.191.0.0/16`. Se hai alcuni gruppi di istanza di backend non integri, tieni presente che il failover o l'overflow è limitato a un numero limitato di gruppi di istanze alternativi. Se osservi `failed_to_pick_backend` o `failed_to_pick_backend_by_hash` nonostante i gruppi di istanze siano integri, svuota i gruppi di istanze non integri impostando la loro capacità su zero. In questo modo, il bilanciatore del carico è costretto a inoltrare il traffico ai gruppi di istanze integri.
`failed_to_connect_to_backend`	Causa: il GFE di secondo livello non è riuscito a stabilire una connessione con un'istanza di backend (non è stato possibile ottenere un SYN-ACK). Questo errore può essere causato anche da un errore GFE interno che impedisce la connessione al backend o da un'interruzione regionale o di rete (ad esempio un taglio della fibra) che impedisce ai GFE di primo livello di comunicare con i GFE di secondo livello. Soluzione: Verifica che le regole firewall sulle VM di backend o nella tua rete VPC consentano il traffico verso i tuoi backend dagli intervalli GFE di secondo livello `35.191.0.0/16`. Verifica che l'applicazione sulle istanze di backend sia in esecuzione e in ascolto sulla porta configurata nel servizio di backend. Controlla le metriche dell'istanza di backend (CPU, memoria, connessioni) per rilevare segni di esaurimento delle risorse.
`backend_connection_closed_before_data_sent_to_client`	Causa: la connessione tra il GFE del secondo livello e il backend è stata chiusa in modo imprevisto prima che la risposta potesse essere inviata al client. Questo problema può essere causato dal server web di backend o da un dispositivo intermedio. Può verificarsi anche quando utilizzi GKE se i pod vengono ridimensionati o terminati e i backend del bilanciatore del carico sono di tipo NEG. Soluzione: Imposta il timeout keepalive HTTP sul server web di backend (come Apache o Nginx) in modo che sia superiore al timeout di 600 secondi del bilanciatore del carico. Il valore consigliato è 620 secondi. Se utilizzi GKE, ciò si verifica quando i pod vengono ridimensionati o terminati e i backend del bilanciatore del carico sono NEG. Per risolvere il problema, valuta la possibilità di aumentare `terminationGracePeriodSeconds` nella configurazione del pod o del deployment per consentire la chiusura controllata delle connessioni esistenti. Il valore ideale è: `T_grace > T_preStop + T_drain + T_buffer` Dove: `T_preStop` è la durata del riposo dell'hook `preStop` del container, che in genere è di 120 secondi per consentire la rimozione dell'endpoint dal NEG. `T_drain` è il timeout per lo svuotamento della connessione del servizio di backend, che in genere è di 60 secondi. `T_buffer` è un buffer aggiuntivo di 30-45 secondi per consentire l'arresto sicuro del pod. Per le configurazioni standard, il valore consigliato è almeno 210 secondi (3,5 minuti). Controlla i log dell'applicazione di backend per rilevare errori che potrebbero causare la chiusura della connessione. Controlla le metriche dell'istanza di backend (CPU, memoria, connessioni) per rilevare segni di esaurimento delle risorse.
`backend_timeout`	Causa: il GFE di secondo livello ha stabilito una connessione con il backend, ma il backend non ha inviato una risposta entro il timeout del servizio di backend configurato. Soluzione: Se la tua applicazione ha bisogno di più tempo per elaborare le richieste, aumenta il timeout del servizio di backend. Controlla la presenza di problemi di prestazioni nelle istanze di backend (CPU, I/O, ritardi dell'applicazione) che potrebbero impedire una risposta tempestiva. Se i backend sono sovraccarichi, valuta la possibilità di scalare le risorse di backend o ottimizzare l'applicazione.
`retriable_error`	Causa:questo errore 503 può verificarsi se gli strumenti di infrastruttura come codice (come Terraform) aggiornano le regole del bilanciatore del carico in modo da rimuovere temporaneamente le regole della mappa URL prima di aggiungerle di nuovo oppure a causa di problemi transitori di configurazione o di rete interna di Google durante le implementazioni o i push di configurazione. Soluzione: Se utilizzi l'automazione, verifica che esegua aggiornamenti in loco anziché aggiornamenti di eliminazione e creazione per le regole della mappa URL. Se visualizzi questo errore durante o dopo una modifica alla configurazione, potrebbe essere temporaneo; attendi qualche minuto affinché la configurazione venga propagata a livello globale.

Risoluzione degli errori HTTP `408`

Con il traffico HTTP, il tempo massimo a disposizione del client per completare l'invio della richiesta è pari al timeout del servizio di backend. Se visualizzi risposte HTTP 408 con jsonPayload.statusDetail client_timed_out, significa che non è stato fatto alcun progresso durante l'esecuzione del proxy della richiesta dal client o della risposta dal backend. Se il problema è dovuto a client che riscontrano problemi di prestazioni, puoi risolverlo aumentando il timeout del servizio di backend.

Il traffico con bilanciamento del carico non ha l'indirizzo di origine del client originale

L'indirizzo IP di origine per i pacchetti, come visto dai backend, non è l'indirizzo IP esterno del bilanciatore del carico. I bilanciatori del carico basati su proxy, come i bilanciatori del carico delle applicazioni esterni, utilizzano due connessioni TCP per trasmettere il traffico dal client ai backend:

Connessione 1, dal client originale al bilanciatore del carico (GFE o subnet solo proxy)
Connessione 2, dal bilanciatore del carico (GFE o subnet solo proxy) alla VM o all'endpoint di backend

Gli indirizzi IP di origine e di destinazione per ogni connessione variano in base al tipo di bilanciatore del carico delle applicazioni esterno che utilizzi. Per maggiori dettagli, consulta Indirizzi IP di origine per i pacchetti client .

Compare un errore di autorizzazione quando provo a visualizzare un oggetto nel mio bucket Cloud Storage

Per pubblicare oggetti tramite il bilanciamento del carico, gli oggetti Cloud Storage devono essere accessibili pubblicamente. Assicurati di aggiornare le autorizzazioni degli oggetti pubblicati in modo che siano leggibili pubblicamente.

L'URL non pubblica l'oggetto Cloud Storage previsto

L'oggetto Cloud Storage da pubblicare è determinato in base alla mappa URL e all'URL richiesto. Se il percorso della richiesta è mappato a un bucket di backend nella mappa URL, l'oggetto Cloud Storage viene determinato aggiungendo il percorso di richiesta completo al bucket Cloud Storage specificato dalla mappa URL.

Ad esempio, se mappi /static/* a gs://[EXAMPLE_BUCKET], la richiesta a https://<GCLB IP or Host>/static/path/to/content.jpg proverà a pubblicare gs://[EXAMPLE_BUCKET]/static/path/to/content.jpg. Se l'oggetto non esiste, riceverai il seguente messaggio di errore al posto dell'oggetto:


NoSuchKey
The specified key does not exist.

La compressione non funziona

Un bilanciatore del carico delle applicazioni esterno non comprime né decomprime le risposte, ma può fornire risposte generate dal servizio di backend compresse utilizzando strumenti come gzip o DEFLATE.

Se le risposte gestite dal bilanciatore del carico non sono compresse, ma dovrebbero esserlo, verifica che il software del server web in esecuzione sulle tue istanze sia configurato per comprimere le risposte. Per impostazione predefinita, alcuni software dei server web disattivano automaticamente la compressione per le richieste che includono un'intestazione Via, che indica che la richiesta è stata inoltrata da un proxy. Poiché è un proxy, il bilanciatore del carico delle applicazioni esterno aggiunge un'intestazione Via a ogni richiesta come richiesto dalla specifica HTTP. Per attivare la compressione, potresti dover sostituire la configurazione predefinita del server web per indicargli di comprimere le risposte anche se la richiesta possiede un'intestazione Via.

Per configurare i backend nginx in modo che gestiscano le risposte compresse sottoposte a proxy tramite un bilanciatore del carico delle applicazioni esterno:

Imposta la direttiva gzip_proxied in modo appropriato (ad esempio, su any) e
Imposta la direttiva gzip_vary su on.

Per configurare i backend Apache in modo che servano risposte compresse sottoposte a proxy tramite un bilanciatore del carico delle applicazioni esterno:

Utilizza il DEFLATE filtro e
Aggiungi Vary Accept-Encoding all'intestazione della risposta utilizzando il modulo mod_headers.

Risolvere i problemi relativi ai backend in stato non integro

Risolvere i problemi relativi a HTTP/2 ai backend

Assicurati che l'istanza di backend sia integra e supporti il protocollo HTTP/2. Puoi verificarlo testando la connettività all'istanza di backend utilizzando HTTP/2. Assicurati che la VM utilizzi suite di crittografia conformi alle specifiche HTTP/2. Ad esempio, alcune suite di crittografia TLS 1.2 non sono consentite da HTTP/2. Fai riferimento alla lista nera delle suite di crittografia TLS 1.2.

Dopo aver verificato che la VM utilizza il protocollo HTTP/2, assicurati che la configurazione del firewall consenta il passaggio del controllo di integrità e del bilanciatore del carico.

Se non ci sono problemi con la configurazione del firewall, assicurati che il bilanciamento del carico sia configurato per comunicare con la porta corretta sulla VM.

Risoluzione dei problemi relativi al backend esterno e ai NEG internet

Prima di esaminare i problemi, acquisisci familiarità con le seguenti pagine:

Il traffico non raggiunge gli endpoint

Dopo aver configurato un servizio, il nuovo endpoint diventa raggiungibile tramite il bilanciatore del carico delle applicazioni esterno quando:

L'endpoint è collegato al NEG internet.
Il nome di dominio completo associato può essere risolto correttamente tramite DNS (se utilizzi il tipo di endpoint FQDN).
L'endpoint è accessibile tramite internet.

Se il traffico non riesce a raggiungere l'endpoint, il che comporta un codice di errore 502, esegui una query sul record TXT DNS _cloud-eoips.googleusercontent.com utilizzando uno strumento come dig o nslookup. Prendi nota dei CIDR (dopo ip4:) e assicurati che questi intervalli siano consentiti dal firewall o dall'elenco di controllo dell'accesso (ACL) al cloud.

Dopo aver configurato un backend esterno, le richieste al backend esterno non sono riuscite e hanno restituito un errore 5xx

Seleziona Logging.
Verifica che il gruppo di endpoint di rete sia configurato con l'IP:porta o l'FQDN:porta corretti per il tuo backend esterno.
Se utilizzi un nome di dominio completo, assicurati che sia risolvibile tramite Google Public DNS. Puoi verificare che il nome di dominio completo sia risolvibile tramite Google Public DNS seguendo questi passaggi o utilizzando direttamente l'interfaccia web.
Se accedi al bilanciatore del carico solo sul suo IP esterno e il tuo web server di origine prevede un nome host, assicurati di inviare un'intestazione host HTTP valida al tuo backend configurando un'intestazione della richiesta personalizzata.
Se comunichi con un backend tramite HTTPS o HTTP2 (come impostato nel campo protocol del servizio di backend) configurato come endpoint di backend esterno INTERNET_FQDN_PORT, assicurati che l'origine presenti un certificato TLS (SSL) valido e che l'FQDN configurato corrisponda a un nome alternativo del soggetto (Subject Alternative Name) nell'elenco dei nomi alternativi del soggetto dei certificati. Un certificato valido è definito come un certificato firmato da un'autorità di certificazione pubblica e non scaduto.
Quando utilizzi endpoint di backend esterni INTERNET_FQDN_PORT, i certificati autofirmati non vengono accettati dal bilanciatore del carico e vengono rifiutati.
Quando utilizzi HTTPS o HTTP/2 con endpoint di tipo INTERNET_IP_PORT, non viene eseguita alcuna convalida del certificato SSL/controllo SAN. Ciò significa che è possibile utilizzare certificati autofirmati. Quando utilizzi SSL, ti consigliamo di utilizzare gli endpoint INTERNET_FQDN_PORT per assicurarti che i certificati del server e i SAN possano essere convalidati.

Risolvi i problemi di inserimento del gateway del tag Google

Il gateway del tag Google non inserisce i tag correttamente o causa errori.

Per risolvere il problema, utilizza Esplora log nella console Google Cloud per analizzare i log generati dal bilanciatore del carico. I problemi del gateway dei tag Google non influiscono sul codice di risposta HTTP complessivo o sul statusDetails della richiesta della pagina web. La risposta HTTP verrà inviata senza modifiche anche se l'inserimento del tag Google non va a buon fine. Per identificare gli errori del gateway, controlla grpcStatus dell'esecuzione del plug-in nel payload JSON del bilanciatore del carico.

Assicurati che Cloud Logging sia abilitato sui servizi di backend che pubblicano i contenuti del sito web per i domini in cui Google tag gateway è attivo. Configura questa impostazione nella console Google Cloud andando a Bilanciamento del carico > Modifica > Configurazione backend. Per saperne di più, consulta Abilitazione della registrazione su un servizio di backend esistente. Per il servizio di backend deve essere impostata una frequenza di campionamento del logging superiore a 0.0.

Nella console Google Cloud , vai alla pagina Esplora log e seleziona il progetto corretto.

Vai a Esplora log
Modifica l'intervallo di tempo in modo che copra il periodo in cui sospetti che si siano verificati problemi. Per ulteriori informazioni, vedi Utilizzare il selettore dell'intervallo di tempo.
Per visualizzare i log delle richieste gestite dal plug-in di inserimento del gateway del tag Google, utilizza questa query:
```
resource.type="http_load_balancer" logName="projects/PROJECT_ID/logs/requests"  \
jsonPayload.serviceExtensionInfo.extension="0-google-tag-gateway"
```
Sostituisci PROJECT_ID con l'ID progetto.
Identifica i potenziali errori esaminando il campo jsonPayload.serviceExtensionInfo.perProcessingRequestInfo.grpcStatus. Mostra lo stato dell'estensione del gateway del tag Google.
- OK: l'estensione ha completato l'elaborazione senza errori gRPC.
- Qualsiasi valore diverso da OK (ad esempio INTERNAL, UNAVAILABLE, DEADLINE_EXCEEDED): Indica un errore di esecuzione dell'estensione del gateway del tag Google.

Per trovare i log in cui l'estensione del gateway del tag Google ha segnalato un errore, utilizza la seguente query:

resource.type="http_load_balancer" logName="projects/PROJECT_IDlogs/requests" \
jsonPayload.serviceExtensionInfo.extension="0-google-tag-gateway" NOT jsonPayload.serviceExtensionInfo.perProcessingRequestInfo.grpcStatus="OK"

Quando la query precedente restituisce risultati, esamina l'intera voce di log per correlare lo stato dell'estensione con l'esito della richiesta:
- Errore dell'estensione del gateway del tag Google: un grpcStatus diverso da OK (soprattutto nell'evento RESPONSE_BODY) indica che il processo di inserimento del tag ha rilevato un errore. Il codice gRPC specifico fornisce indizi (ad esempio, DEADLINE_EXCEEDED indica un timeout).
- Impatto sulla richiesta dell'utente: se grpcStatus per l'estensione gateway del tag Google non è OK, controlla httpRequest.status e jsonPayload.statusDetails nella stessa voce di log. Ad esempio, un OK non grpcStatus combinato con httpRequest.status: 500 e jsonPayload.statusDetails: service_extensions_error suggerisce che l'errore dell'estensione gateway del tag Google ha causato la ricezione di un errore del server da parte dell'utente.
- Frequenza dei problemi: l'analisi dei timestamp e della frequenza di questi log degli errori consente di determinare se i problemi di inserimento del gateway dei tag Google sono in corso, intermittenti o legati a eventi specifici.

Se riscontri problemi durante la configurazione che la documentazione non riesce a risolvere, contatta l'assistenza Google Ads.

Risolvere i problemi relativi ai bilanciatori del carico delle applicazioni esterni Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.