Google verwendet KI-Technologie, um Inhalte in Ihre bevorzugte Sprache zu übersetzen. KI-Übersetzungen können Fehler enthalten.

Probleme mit externen Application Load Balancern beheben

In dieser Anleitung wird beschrieben, wie Sie Probleme bei der Konfiguration externer Load Balancer beheben können. Machen Sie sich vor der Untersuchung von Problemen mit den folgenden Seiten vertraut:

Back-Ends haben nicht kompatible Balancing-Modi

Beim Erstellen eines Load-Balancers kann der folgende Fehler auftreten:

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.

Dies ist der Fall, wenn Sie versuchen, dasselbe Back-End in zwei verschiedenen Load-Balancern zu verwenden, und die Back-Ends keine kompatiblen Balancing-Modi haben.

Hier finden Sie weitere Informationen:

Allgemeine Verbindungsprobleme beheben

Ungeklärte „5XX“-Fehler

Ein Fehler vom Typ „HTTP 5XX“ kann von einem GFE der ersten Ebene, einem GFE der zweiten Ebene oder einem Backend zurückgegeben werden, je nachdem, wo die Fehlerbedingung auftritt.

In diesem Abschnitt wird beschrieben, wie Sie 5XX-Fehler beheben, die in verschiedenen Phasen des Prozesses zur Verteilung von Anfragen für GFE-basierte externe Application Load Balancer auftreten können.

Quelle von „5XX“-Fehlern mit Cloud Logging ermitteln

Bei Fehlerbedingungen, die durch ein Kommunikationsproblem zwischen dem Load-Balancer-Proxy und seinen Back-Ends verursacht werden, generiert der Load-Balancer einen HTTP-Fehlerantwortcode (5XX) und gibt diesen Fehlerantwortcode an den Client zurück. Nicht alle HTTP 5XX-Fehler werden vom Load-Balancer generiert. Wenn ein Backend beispielsweise eine HTTP 5XX-Antwort an den Load-Balancer sendet, leitet der Load-Balancer diese Antwort an seinen Client weiter.

Informationen dazu, ob eine HTTP 5XX-Antwort von einem Backend weitergeleitet wurde oder ob sie vom Load-Balancer-Proxy generiert wurde, finden Sie im Feld statusDetails in Cloud Logging.

Wenn statusDetails response_sent_by_backend ist, hat der Load-Balancer die 5XX-Antwort vom Backend weitergeleitet. Beheben Sie das Problem in Ihren Back-Ends.
Wenn statusDetails eine andere Fehlermeldung ist, wird die 5XX-Antwort vom Load Balancer generiert.

Konfigurationsänderungen am globalen externen Application Load Balancer, z. B. das Hinzufügen oder Entfernen eines Backend-Dienstes, können dazu führen, dass Sie für eine kurze Zeit HTTP 502-Antworten mit statusDetails als failed_to_pick_backend sehen. Das ist normal, wenn Konfigurationsänderungen global auf GFEs angewendet werden.

Backend-Integrität prüfen, bevor Sie mit der Fehlerbehebung beginnen

Bevor Sie 5XX-Fehler beheben, prüfen Sie, ob Ihre Back-Ends fehlerfrei sind und die Systemdiagnosen erfolgreich ausgeführt werden. Wenn Backends fehlerhaft sind, kann das GFE der zweiten Ebene Anfragen nicht an sie weiterleiten. Das kann 5XX-Fehler verursachen, auch wenn alles andere richtig konfiguriert ist.

Prüfen Sie, ob eine Firewallregel konfiguriert ist, die Systemdiagnosen zulässt. Ist dies nicht der Fall, schlagen Systemdiagnosen fehl und in den Load Balancer-Logs wird möglicherweise ein statusDetails-Wert von failed_to_pick_backend angezeigt.
Prüfen Sie, ob der Systemdiagnose-Traffic Ihre Backend-VMs erreicht. Aktivieren Sie dazu das Logging der Systemdiagnose und suchen Sie nach erfolgreichen Logeinträgen. Bei neuen Load-Balancern werden erfolgreiche Logeinträge für Systemdiagnosen möglicherweise nicht sofort angezeigt. Dies kann daran liegen, dass der anfängliche Systemstatus des Back-Ends noch nicht von UNHEALTHY in einen anderen Status geändert wurde. Erfolgreiche Systemdiagnose-Logeinträge werden erst angezeigt, wenn der Systemdiagnose-Prober eine HTTP-Antwort 200 OK vom Backend erhalten hat.

Wenn Systemdiagnosen fehlschlagen, müssen Sie die Fehlerbehebung für Ihre Backend-Anwendung und Firewallregeln durchführen. Wenn Systemdiagnosen erfolgreich sind, aber weiterhin 5XX-Fehler angezeigt werden, prüfen Sie das Feld statusDetails in Cloud Logging, um die Fehlerquelle zu ermitteln.

Fehlerbehebung basierend auf `statusDetails`

Wenn HTTP 5XX-Fehler weiterhin auftreten, verwenden Sie das Feld statusDetails in Cloud Logging, um die Ursache zu ermitteln und das Problem entsprechend zu beheben.

Der globale externe Application Load Balancer und der regionale externe Application Load Balancer generieren aussagekräftige HTTP-Statuscodes wie HTTP 503 „Service Unavailable“ (Dienst nicht verfügbar) und HTTP 504 „Gateway Timeout“ (Gateway-Zeitüberschreitung).
Der klassische Application Load Balancer verwendet immer den HTTP-Statuscode 502 „Bad Gateway“ für alle vom Load Balancer generierten Fehler.

statusDetails	Mögliche Ursache und Lösung
`failed_to_pick_backend` `failed_to_pick_backend_by_hash`	Ursache:Das GFE der zweiten Ebene konnte kein fehlerfreies Backend auswählen, an das die Anfrage weitergeleitet werden kann. Dieser Fehler kann aus einem der folgenden Gründe auftreten: Alle Regionen haben die Kapazitätsgrenze erreicht oder überschritten. Der Load-Balancer kann anhand des berechneten Hashs kein verfügbares Backend finden. Der Load-Balancer kann keine Backends finden, die der Dienstkonfiguration entsprechen. Lösung: Prüfen Sie, ob Ihre Back-Ends fehlerfrei sind. Folgen Sie dazu der Anleitung unter Back-End-Zustand prüfen. Prüfen Sie, ob die Systemdiagnosen mit dem richtigen Port, Pfad und Protokoll konfiguriert sind. Achten Sie darauf, dass die Firewallregeln für das Backend Systemdiagnose-Traffic von den Systemdiagnose-Probern `35.191.0.0/16`zulassen. Wenn Sie einige fehlerhafte Backend-Instanzgruppen haben, beachten Sie, dass Failover oder Überlauf auf eine begrenzte Anzahl alternativer Instanzgruppen beschränkt ist. Wenn Sie `failed_to_pick_backend` oder `failed_to_pick_backend_by_hash` beobachten, obwohl die Instanzgruppen fehlerfrei sind, leeren Sie die fehlerhaften Instanzgruppen, indem Sie ihre Kapazität auf null setzen. Dadurch wird der Load-Balancer gezwungen, Traffic an die fehlerfreien Instanzgruppen weiterzuleiten.
`failed_to_connect_to_backend`	Ursache:Das GFE der zweiten Ebene konnte keine Verbindung mit einer Backend-Instanz herstellen (es konnte kein SYN-ACK empfangen werden). Dieser Fehler kann auch durch einen internen GFE-Fehler verursacht werden, der verhindert, dass eine Verbindung zum Backend hergestellt wird. Oder durch einen regionalen Ausfall oder eine Netzwerkunterbrechung (z. B. einen Glasfaserschnitt), die verhindert, dass GFEs der ersten Ebene mit GFEs der zweiten Ebene kommunizieren. Lösung: Prüfen Sie, ob die Firewallregeln auf Ihren Back-End-VMs oder in Ihrem VPC-Netzwerk Traffic zu Ihren Back-Ends aus den GFE-Bereichen der zweiten Ebene zulassen: `35.191.0.0/16`. Prüfen Sie, ob die Anwendung auf Ihren Backend-Instanzen ausgeführt wird und den im Backend-Dienst konfigurierten Port überwacht. Prüfen Sie die Messwerte der Backend-Instanz (CPU, Arbeitsspeicher, Verbindungen) auf Anzeichen von Ressourcenmangel.
`backend_connection_closed_before_data_sent_to_client`	Ursache:Die Verbindung zwischen dem GFE der zweiten Ebene und dem Back-End wurde unerwartet geschlossen, bevor die Antwort an den Client gesendet werden konnte. Dieses Problem kann durch den Backend-Webserver oder ein Zwischengerät verursacht werden. Das kann auch bei der Verwendung von GKE auftreten, wenn die Pods skaliert oder beendet werden und die Load-Balancer-Back-Ends vom Typ NEGs sind. Lösung: Legen Sie das HTTP-Keepalive-Zeitlimit auf dem Backend-Webserver (z. B. Apache oder Nginx) auf einen Wert fest, der größer ist als das 600-Sekunden-Zeitlimit des Load Balancers. Der empfohlene Wert beträgt 620 Sekunden. Wenn Sie GKE verwenden, tritt dies auf, wenn die Pods skaliert oder beendet werden und die Load-Balancer-Back-Ends NEGs sind. Um dieses Problem zu beheben, sollten Sie `terminationGracePeriodSeconds` in Ihrer Pod- oder Bereitstellungskonfiguration erhöhen, damit bestehende Verbindungen ordnungsgemäß geschlossen werden können. Der ideale Wert ist: `T_grace > T_preStop + T_drain + T_buffer` Wobei: `T_preStop` ist die Dauer des `preStop`-Hook-Ruhezustands des Containers, die in der Regel 120 Sekunden beträgt, damit der Endpunkt aus der NEG entfernt werden kann. `T_drain` ist das Zeitlimit für den Verbindungsausgleich des Backend-Dienstes, das in der Regel 60 Sekunden beträgt. `T_buffer` ist ein zusätzlicher Puffer von 30 bis 45 Sekunden, damit das Pod sicher heruntergefahren werden kann. Bei Standardkonfigurationen wird ein Wert von mindestens 210 Sekunden (3, 5 Minuten) empfohlen. Prüfen Sie die Logs der Backend-Anwendung auf Fehler, die dazu führen könnten, dass die Verbindung geschlossen wird. Prüfen Sie die Messwerte der Backend-Instanz (CPU, Arbeitsspeicher, Verbindungen) auf Anzeichen für Ressourcenmangel.
`backend_timeout`	Ursache:Das GFE der zweiten Ebene hat eine Verbindung zum Backend hergestellt, aber das Backend hat nicht innerhalb des konfigurierten Zeitlimits für den Backend-Dienst geantwortet. Lösung: Wenn Ihre Anwendung mehr Zeit zum Verarbeiten von Anfragen benötigt, erhöhen Sie das Zeitlimit für den Backend-Dienst. Prüfen Sie, ob auf Ihren Backend-Instanzen Leistungsprobleme (CPU, E/A, Anwendungsverzögerungen) auftreten, die eine rechtzeitige Antwort verhindern könnten. Wenn Back-Ends überlastet sind, sollten Sie die Back-End-Ressourcen skalieren oder die Anwendung optimieren.
`retriable_error`	Ursache:Dieser 503-Fehler kann auftreten, wenn Infrastruktur-als-Code-Tools (z. B. Terraform) Load-Balancer-Regeln so aktualisieren, dass URL-Zuordnungsregeln vorübergehend entfernt und dann wieder hinzugefügt werden. Er kann auch durch vorübergehende interne Google-Netzwerk- oder Konfigurationsprobleme während Rollouts oder Konfigurations-Pushes verursacht werden. Lösung: Wenn Sie Automatisierung verwenden, prüfen Sie, ob In-Place-Updates und nicht Delete-then-Create-Updates für URL-Map-Regeln ausgeführt werden. Wenn dieser Fehler während oder nach einer Konfigurationsänderung angezeigt wird, kann er vorübergehend sein. Warten Sie einige Minuten, bis die Konfiguration global übernommen wird.

HTTP-Fehler `408` beheben

Bei HTTP-Traffic entspricht die maximale Zeit, die der Client zum Senden seiner Anfrage benötigt, dem Zeitlimit des Backend-Diensts. Wenn Sie die HTTP-Antworten 408 mit dem jsonPayload.statusDetail client_timed_out sehen, bedeutet dies, dass beim Weiterleiten der Anfrage vom Client oder der Antwort vom Back-End kein ausreichender Fortschritt erzielt wurde. Wenn das Problem auf Clients zurückzuführen ist, die Leistungsprobleme haben, können Sie dieses Problem beheben, indem Sie das Zeitlimit für den Backend-Dienst erhöhen.

Load-Balancing-Traffic hat nicht die Quelladresse des ursprünglichen Clients

Die Quell-IP-Adresse für Pakete, die von den Back-Ends erkannt wird, ist nicht die externe IP-Adresse des Load Balancers. Proxybasierte Load Balancer wie die externen Anwendungs-Load-Balancer verwenden zwei TCP-Verbindungen, um Traffic vom Client an die Back-Ends zu übertragen:

Verbindung 1, vom ursprünglichen Client zum Load Balancer (GFE- oder Nur-Proxy-Subnetz)
Verbindung 2, vom Load Balancer (GFE- oder Nur-Proxy-Subnetz) zur Backend-VM oder zum Backend-Endpunkt

Die Quell- und Ziel-IP-Adressen für jede Verbindung unterscheiden sich je nach Typ des verwendeten externen Anwendungs-Load-Balancers. Weitere Informationen finden Sie unter Quell-IP-Adressen für Clientpakete .

Berechtigungsfehler beim Versuch, ein Objekt im Cloud Storage-Bucket anzuzeigen

Um Objekte über das Load-Balancing bereitzustellen, müssen die Cloud Storage-Objekte öffentlich zugänglich sein. Aktualisieren Sie die Berechtigungen der bereitgestellten Objekte, damit sie öffentlich lesbar sind.

URL stellt nicht das erwartete Cloud Storage-Objekt bereit

Das bereitzustellende Cloud Storage-Objekt wird anhand der URL-Zuordnung und der angeforderten URL bestimmt. Wenn der Anfragepfad in der URL-Zuordnung einem Back-End-Bucket zugeordnet ist, wird das Cloud Storage-Objekt bestimmt, indem der vollständige Anfragepfad an den Cloud Storage-Bucket, der in der URL-Zuordnung angegeben ist, angehängt wird.

Beispiel: Wenn Sie /static/* zu gs://[EXAMPLE_BUCKET] zuordnen, versucht die Anfrage an https://<GCLB IP or Host>/static/path/to/content.jpg gs://[EXAMPLE_BUCKET]/static/path/to/content.jpg bereitzustellen. Wenn das Objekt nicht vorhanden ist, erhalten Sie anstelle des Objekts die folgende Fehlermeldung:


NoSuchKey
The specified key does not exist.

Komprimierung funktioniert nicht

Ein externer Application Load Balancer komprimiert oder dekomprimiert die Antworten nicht selbst, kann jedoch von Ihrem Backend-Dienst generierte Antworten ausliefern, die mit Tools wie gzip oder DEFLATE komprimiert wurden.

Wenn die vom Load-Balancer bereitgestellten Antworten nicht komprimiert sind, obwohl sie dies sein sollten, prüfen Sie, ob die Webserver-Software für Ihre Instanzen so konfiguriert ist, dass Antworten komprimiert werden. Manche Webserver-Software deaktiviert standardmäßig die Komprimierung für Anfragen, die einen Via-Header enthalten, der angibt, dass die Anfrage von einem Proxy weitergeleitet wurde. Da der externe Application Load Balancer ein Proxy ist, wird jeder Anfrage gemäß HTTP-Spezifikation ein Via-Header hinzugefügt. Um die Komprimierung zu aktivieren, müssen Sie womöglich die Standardkonfiguration des Webservers überschreiben, um diesen anzuweisen, Antworten auch dann zu komprimieren, wenn die Anfrage einen Via-Header beinhaltet.

So konfigurieren Sie nginx-Back-Ends für die Bereitstellung komprimierter Antworten, die über einen externen Application Load Balancer weitergeleitet werden:

Legen Sie die Anweisung gzip_proxied entsprechend fest (z. B. auf any).
Legen Sie die Anweisung gzip_vary auf on fest.

So konfigurieren Sie Apache-Back-Ends für die Bereitstellung komprimierter Antworten, die über einen externen Application Load Balancer weitergeleitet werden:

Verwenden Sie den Filter DEFLATE.
Fügen Sie dem Antwortheader über das Modul mod_headers Vary Accept-Encoding hinzu.

Fehlerbehebung bei fehlerhaften Back-Ends

Probleme von HTTP/2 mit den Back-Ends beheben

Prüfen Sie, ob Ihre Backend-Instanz fehlerfrei ist und das HTTP/2-Protokoll unterstützt. Testen Sie dazu die Verbindung zur Back-End-Instanz über HTTP/2. Sorgen Sie dafür, dass die VM HTTP/2-spezifikationskonforme Chiffresammlungen verwendet. Beispielsweise werden bestimmte TLS 1.2-Chiffresammlungen von HTTP/2 nicht zugelassen. Weitere Informationen können Sie der TLS 1.2 Cipher Suite Black List entnehmen.

Nachdem Sie festgestellt haben, dass die VM das HTTP/2-Protokoll verwendet, sollten Sie sich vergewissern, dass die Einstellung Ihrer Firewall den Traffic von Systemdiagnose und Load-Balancer durchlässt.

Wenn keine Probleme mit der Einstellung der Firewall vorliegen, prüfen Sie, ob der Load-Balancer entsprechend der Konfiguration mit dem richtigen Port auf der VM kommuniziert.

Probleme mit externem Backend und Internet-NEG beheben

Machen Sie sich vor der Untersuchung von Problemen mit den folgenden Seiten vertraut:

Traffic erreicht die Endpunkte nicht

Nachdem Sie einen Dienst konfiguriert haben, wird der neue Endpunkt in folgenden Fällen über den externen Application Load Balancer erreichbar:

Der Endpunkt ist mit der Internet-NEG verknüpft.
Der verknüpfte FQDN kann erfolgreich DNS-aufgelöst werden, wenn Sie den FQDN-Endpunkttyp verwenden.
Der Endpunkt ist über das Internet zugänglich.

Wenn der Traffic den Endpunkt nicht erreicht, führt dies zu einem 502-Fehlercode. Fragen Sie dann den DNS-TXT-Eintrag _cloud-eoips.googleusercontent.com mit einem Tool wie Dig oder nslookup ab. Notieren Sie sich die CIDRs (nach ip4:). Ihre Firewall oder Cloud Access Control List (ACL) muss diese Bereiche zulassen.

Nachdem Sie ein externes Backend konfiguriert haben, sind Anfragen an das externe Backend mit einem 5xx-Fehler fehlgeschlagen

Prüfen Sie Logging.
Sorgen Sie dafür, dass die Netzwerk-Endpunktgruppe mit dem richtigen IP:Port oder FQDN:Port für Ihr externes Back-End konfiguriert wurde.
Achten Sie bei Verwendung von FQDN darauf, dass er über Google Public DNS aufgelöst werden kann. Mithilfe dieser Schritte oder direkt auf der Weboberfläche können Sie dafür sorgen, dass der FQDN über Google Public DNS aufgelöst werden kann.
Wenn Sie nur über die externe IP-Adresse auf den Load Balancer zugreifen und Ihr Quell-Webserver einen Hostnamen erwartet, müssen Sie einen gültigen HTTP-Host-Header an Ihr Backend senden. Dazu konfigurieren Sie einen benutzerdefinierten Anfrageheader.
Sorgen Sie bei der Kommunikation mit einem Backend über HTTPS oder HTTP2 (wie im Feld protocol des Backend-Dienstes festgelegt), das als externer INTERNET_FQDN_PORT-Backend-Endpunkt konfiguriert ist, dafür, dass Ihre Quelle ein gültiges TLS (SSL)-Zertifikat vorlegt und der konfigurierte FQDN mit einem SAN (Subject Alternative Name) in der Zertifikatsliste der SANs übereinstimmt. Ein Zertifikat gilt als gültig, wenn es von einer öffentlichen Zertifizierungsstelle signiert wurde und es nicht abgelaufen ist.
Bei der Verwendung externer INTERNET_FQDN_PORT-Backend-Endpunkte werden selbst signierte Zertifikate vom Load Balancer nicht akzeptiert und werden abgelehnt.
Bei der Verwendung von HTTPS oder HTTP/2 mit Endpunkten des Typs INTERNET_IP_PORT wird keine SSL-Zertifikats-/SAN-Prüfung durchgeführt. Sie können daher selbstsignierte Zertifikate verwenden. Bei der Verwendung von SSL empfehlen wir die Nutzung von INTERNET_FQDN_PORT-Endpunkten, um dafür zu sorgen, dass Serverzertifikate und SANs validiert werden können.

Probleme beim Einfügen des Google-Tag-Gateways beheben

Das Google-Tag-Gateway fügt Tags nicht richtig ein oder verursacht Fehler.

Um dieses Problem zu beheben, verwenden Sie den Log-Explorer in der Google Cloud Console, um die von Ihrem Load Balancer generierten Logs zu analysieren. Probleme mit dem Google-Tag-Gateway haben keine Auswirkungen auf den allgemeinen HTTP-Antwortcode oder die statusDetails der Webseitenanfrage. Die HTTP-Antwort wird unverändert gesendet, auch wenn das Einfügen des Google-Tags fehlschlägt. Um Gateway-Fehler zu identifizieren, prüfen Sie die grpcStatus der Plug-in-Ausführung in der JSON-Nutzlast Ihres Load-Balancers.

Achten Sie darauf, dass Cloud Logging für die Back-End-Dienste aktiviert ist, die die Websiteinhalte für die Domains bereitstellen, in denen das Google-Tag-Gateway aktiv ist. Konfigurieren Sie dies in der Google Cloud Console, indem Sie zu Load Balancing > Bearbeiten > Back-End-Konfiguration wechseln. Weitere Informationen finden Sie unter Logging für einen vorhandenen Backend-Dienst aktivieren. Für diesen Backend-Dienst muss eine Logging-Stichprobenrate von mehr als 0.0 festgelegt werden.

Rufen Sie in der Google Cloud Console die Seite Log-Explorer auf und wählen Sie das richtige Projekt aus.

Zum Log-Explorer
Passen Sie den Zeitraum an den Zeitraum an, in dem Sie vermuten, dass Probleme aufgetreten sind. Weitere Informationen finden Sie unter Zeitbereichsauswahl verwenden.
Wenn Sie Logs für Anfragen sehen möchten, die vom Google Tag Gateway-Injection-Plug-in verarbeitet werden, verwenden Sie diese Abfrage:
```
resource.type="http_load_balancer" logName="projects/PROJECT_ID/logs/requests"  \
jsonPayload.serviceExtensionInfo.extension="0-google-tag-gateway"
```
Ersetzen Sie PROJECT_ID durch Ihre Projekt-ID.
Potenzielle Fehler lassen sich anhand des Felds jsonPayload.serviceExtensionInfo.perProcessingRequestInfo.grpcStatus erkennen. Hier wird der Status der Google-Tag-Gateway-Erweiterung selbst angezeigt.
- OK: Die Erweiterung hat die Verarbeitung ohne gRPC-Fehler abgeschlossen.
- Ein anderer Wert als OK (z. B. INTERNAL, UNAVAILABLE, DEADLINE_EXCEEDED): Dies weist auf einen Fehler bei der Ausführung der Google-Tag-Gateway-Erweiterung hin.

Verwenden Sie die folgende Abfrage, um Logs zu finden, in denen die Google Tag Gateway-Erweiterung einen Fehler gemeldet hat:

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

Wenn die vorherige Abfrage Ergebnisse zurückgibt, untersuchen Sie den gesamten Logeintrag, um den Erweiterungsstatus mit dem Ergebnis der Anfrage in Beziehung zu setzen:
- Fehler bei der Google-Tag-Gateway-Erweiterung: Ein grpcStatus, das nicht OK ist (insbesondere beim RESPONSE_BODY-Ereignis), bedeutet, dass beim Einfügen des Tags ein Fehler aufgetreten ist. Der spezifische gRPC-Code gibt Hinweise (z. B. DEADLINE_EXCEEDED für ein Zeitlimit).
- Auswirkungen auf Nutzeranfrage: Wenn die grpcStatus für die Google-Tag-Gateway-Erweiterung nicht OK ist, prüfen Sie die httpRequest.status und jsonPayload.statusDetails im selben Logeintrag. Ein nicht OK-Wert für grpcStatus in Kombination mit httpRequest.status: 500 und jsonPayload.statusDetails: service_extensions_error deutet darauf hin, dass der Nutzer aufgrund eines Fehlers bei der Google-Tag-Gateway-Erweiterung einen Serverfehler erhalten hat.
- Häufigkeit von Problemen: Durch die Analyse der Zeitstempel und Häufigkeit dieser Fehlerprotokolle lässt sich feststellen, ob Probleme mit dem Einfügen des Google Tag Gateways fortlaufend, zeitweise oder an bestimmte Ereignisse gebunden auftreten.

Wenn bei der Einrichtung Probleme auftreten, die in der Dokumentation nicht behandelt werden, wenden Sie sich an den Google Ads-Support.

Probleme mit externen Application Load Balancern beheben Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.