Logs und Messwerte für Back-End-Dienste

In diesem Dokument erfahren Sie, wie Sie Cloud Logging und Cloud Monitoring mit globalem externen HTTP(S)-Load Balancer (klassisch), globalem externen HTTP(S)-Load-Balancer und Cloud CDN konfigurieren und verwenden.

Logging

Sie können Logs für den Back-End-Dienst des externen HTTP(S)-Load-Balancers aktivieren, deaktivieren und anzeigen. Für externe HTTP(S)-Load-Balancer mit Back-End-Buckets wird das Logging automatisch aktiviert und kann nicht deaktiviert werden.

Sie aktivieren oder deaktivieren Logging für jeden Back-End-Dienst. Sie können konfigurieren, ob alle Anfragen oder nur ein zufällig ausgewählter Teil protokolliert werden sollen.

Achten Sie darauf, dass kein Logausschluss vorhanden ist, der für den externen HTTP(S)-Load-Balancer gilt. Wie Sie prüfen, ob Cloud HTTP Load Balancer-Logs zulässig sind, erfahren Sie unter Ausgeschlossene Ressourcentypen ansehen.

Logging für einen neuen Back-End-Dienst aktivieren

Console

  1. Rufen Sie in der Google Cloud Console die Seite Load-Balancing auf.

    Load-Balancing aufrufen

  2. Klicken Sie auf den Namen des Load-Balancers.

  3. Klicken Sie auf Bearbeiten.

  4. Klicken Sie auf Back-End-Konfiguration.

  5. Wählen Sie Back-End-Dienst erstellen aus.

  6. Füllen Sie die Pflichtfelder für den Back-End-Dienst aus.

  7. Klicken Sie auf Logging aktivieren.

  8. Legen Sie im Feld Abtastrate die Inklusionswahrscheinlichkeit fest. Sie können eine Zahl von 0.0 bis 1.0 festlegen, wobei 0.0 bedeutet, dass keine Anfragen in Logs erfasst werden, und 1.0 bedeutet, dass 100 % der Anfragen in Logs erfasst werden. Der Standardwert ist 1.0

  9. Klicken Sie auf Aktualisieren, um die Bearbeitung des Back-End-Dienstes abzuschließen.

  10. Klicken Sie auf Aktualisieren, um die Bearbeitung des Load-Balancers abzuschließen.

gcloud: Modus "Global"

Erstellen Sie einen Back-End-Dienst und aktivieren Sie das Logging mit dem Befehl gcloud compute backend-services create.

gcloud compute backend-services create BACKEND_SERVICE \
    --global \
    --enable-logging \
    --logging-sample-rate=VALUE \
    --load-balancing-scheme=EXTERNAL_MANAGED

Wobei Folgendes gilt:

  • --global gibt an, dass der Back-End-Dienst global ist. Verwenden Sie dieses Feld für Back-End-Dienste, die mit globalen externen HTTP(S)-Load-Balancern verwendet werden.
  • --enable-logging aktiviert das Logging für diesen Back-End-Dienst.
  • Mit --logging-sample-rate können Sie einen Wert zwischen 0.0 und 1.0 angeben, wobei 0.0 dazu führt, dass keine Anfragen in Logs erfasst werden, und 1.0 bedeutet, dass 100 % der Anfragen in Logs erfasst werden. Dies ist nur mit dem Parameter --enable-logging sinnvoll. Wenn Sie das Logging aktivieren und die Abtastrate auf 0.0 festlegen, entspricht dies einer Deaktivierung des Loggings. Der Standardwert ist 1.0

gcloud: Modus "Klassisch"

Erstellen Sie einen Back-End-Dienst und aktivieren Sie das Logging mit dem Befehl gcloud compute backend-services create.

gcloud compute backend-services create BACKEND_SERVICE \
 --global \
 --enable-logging \
 --logging-sample-rate=VALUE \
 --load-balancing-scheme=EXTERNAL

Wobei Folgendes gilt:

  • --global gibt an, dass der Back-End-Dienst global ist. Verwenden Sie dieses Feld für Back-End-Dienste, die mit globalen externen HTTP(S)-Load-Balancern (klassisch) verwendet werden.
  • --enable-logging aktiviert das Logging für diesen Back-End-Dienst.
  • Mit --logging-sample-rate können Sie einen Wert zwischen 0.0 und 1.0 angeben, wobei 0.0 dazu führt, dass keine Anfragen in Logs erfasst werden, und 1.0 bedeutet, dass 100 % der Anfragen in Logs erfasst werden. Dies ist nur mit dem Parameter --enable-logging sinnvoll. Wenn Sie das Logging aktivieren und die Abtastrate auf 0.0 festlegen, entspricht dies einer Deaktivierung des Loggings. Der Standardwert ist 1.0

Logging für vorhandenen Back-End-Dienst aktivieren

Console

  1. Rufen Sie in der Google Cloud Console die Seite Load-Balancing auf.

    Load-Balancing aufrufen

  2. Klicken Sie auf den Namen des Load-Balancers.

  3. Klicken Sie auf Bearbeiten.

  4. Klicken Sie auf Back-End-Konfiguration.

  5. Klicken Sie neben Ihrem Back-End-Dienst auf  Bearbeiten.

  6. Klicken Sie auf Logging aktivieren.

  7. Legen Sie im Feld Abtastrate die Inklusionswahrscheinlichkeit fest. Sie können eine Zahl von 0.0 bis 1.0 festlegen, wobei 0.0 bedeutet, dass keine Anfragen in Logs erfasst werden, und 1.0 bedeutet, dass 100 % der Anfragen in Logs erfasst werden. Der Standardwert ist 1.0

  8. Klicken Sie auf Aktualisieren, um die Bearbeitung des Back-End-Dienstes abzuschließen.

  9. Klicken Sie auf Aktualisieren, um die Bearbeitung des Load-Balancers abzuschließen.

gcloud: Modus "Global"

Aktivieren Sie das Logging für einen vorhandenen Back-End-Dienst mit dem Befehl gcloud compute backend-services update.

gcloud compute backend-services update BACKEND_SERVICE \
    --global \
    --enable-logging \
    --logging-sample-rate=VALUE

Wobei Folgendes gilt:

  • --global gibt an, dass der Back-End-Dienst global ist. Verwenden Sie dieses Feld für Back-End-Dienste, die mit globalen externen HTTP(S)-Load-Balancern verwendet werden.
  • --enable-logging aktiviert das Logging für diesen Back-End-Dienst.
  • Mit --logging-sample-rate können Sie einen Wert zwischen 0.0 und 1.0 angeben, wobei 0.0 dazu führt, dass keine Anfragen in Logs erfasst werden, und 1.0 bedeutet, dass 100 % der Anfragen in Logs erfasst werden. Dies ist nur mit dem Parameter --enable-logging sinnvoll. Wenn Sie das Logging aktivieren und die Abtastrate auf 0.0 festlegen, entspricht dies einer Deaktivierung des Loggings. Der Standardwert ist 1.0

gcloud: Modus "Klassisch"

Aktivieren Sie das Logging für einen vorhandenen Back-End-Dienst mit dem Befehl gcloud compute backend-services update.

gcloud compute backend-services update BACKEND_SERVICE \
    --global \
    --enable-logging \
    --logging-sample-rate=VALUE

Wobei Folgendes gilt:

  • --global gibt an, dass der Back-End-Dienst global ist. Verwenden Sie dieses Feld für Back-End-Dienste, die mit globalen externen HTTP(S)-Load-Balancern (klassisch) verwendet werden.
  • --enable-logging aktiviert das Logging für diesen Back-End-Dienst.
  • Mit --logging-sample-rate können Sie einen Wert zwischen 0.0 und 1.0 angeben, wobei 0.0 dazu führt, dass keine Anfragen in Logs erfasst werden, und 1.0 bedeutet, dass 100 % der Anfragen in Logs erfasst werden. Dies ist nur mit dem Parameter --enable-logging sinnvoll. Wenn Sie das Logging aktivieren und die Abtastrate auf 0.0 festlegen, entspricht dies einer Deaktivierung des Loggings. Der Standardwert ist 1.0

Logging für einen vorhandenen Back-End-Dienst deaktivieren oder ändern

Console

  1. Rufen Sie in der Google Cloud Console die Seite Load-Balancing auf.

    Load-Balancing aufrufen

  2. Klicken Sie auf den Namen des Load-Balancers.

  3. Klicken Sie auf Bearbeiten.

  4. Klicken Sie auf Back-End-Konfiguration.

  5. Klicken Sie neben Ihrem Back-End-Dienst auf  Bearbeiten.

  6. Entfernen Sie das Häkchen für Logging aktivieren, um das Logging komplett zu deaktivieren.

  7. Wenn das Logging aktiviert bleibt, können Sie im Feld Abtastrate eine andere Inklusionswahrscheinlichkeit festlegen. Sie können eine Zahl von 0.0 bis 1.0 festlegen, wobei 0.0 bedeutet, dass keine Anfragen in Logs erfasst werden, und 1.0 bedeutet, dass 100 % der Anfragen in Logs erfasst werden. Der Standardwert ist 1.0. Zur Reduzierung der Anzahl der gespeicherten Logs auf 20 % legen Sie den Wert auf 0.2 fest.

  8. Klicken Sie auf Aktualisieren, um die Bearbeitung des Back-End-Dienstes abzuschließen.

  9. Klicken Sie auf Aktualisieren, um die Bearbeitung des Load-Balancers abzuschließen.

gcloud: Modus "Global"

Deaktivieren Sie das Logging für den Back-End-Dienst mit dem Befehl gcloud compute backend-services update.

Logging vollständig deaktivieren

gcloud compute backend-services update BACKEND_SERVICE \
    --global \
    --no-enable-logging

Wobei Folgendes gilt:

  • --global gibt an, dass der Back-End-Dienst global ist. Verwenden Sie dieses Feld für Back-End-Dienste, die mit globalen externen HTTP(S)-Load-Balancern verwendet werden.
  • --region gibt an, dass der Back-End-Dienst regional ist. Verwenden Sie dieses Feld für Back-End-Dienste, die mit regionalen externen HTTP(S)-Load-Balancern verwendet werden.
  • --no-enable-logging deaktiviert das Logging für diesen Back-End-Dienst.

Abtastrate für das Logging ändern

gcloud compute backend-services update BACKEND_SERVICE \
 --global \
 --logging-sample-rate=VALUE

gcloud: Modus "Klassisch"

Deaktivieren Sie das Logging für den Back-End-Dienst mit dem Befehl gcloud compute backend-services update.

Logging vollständig deaktivieren

gcloud compute backend-services update BACKEND_SERVICE \
    --global \
    --no-enable-logging

Wobei Folgendes gilt:

  • --global gibt an, dass der Back-End-Dienst global ist. Verwenden Sie dieses Feld für Back-End-Dienste, die mit globalen externen HTTP(S)-Load-Balancern (klassisch) verwendet werden.
  • --no-enable-logging deaktiviert das Logging für diesen Back-End-Dienst.

Abtastrate für das Logging ändern

gcloud compute backend-services update BACKEND_SERVICE \
 --global \
 --logging-sample-rate=VALUE

Dabei gilt:

  • --global gibt an, dass der Back-End-Dienst global ist. Verwenden Sie dieses Feld für Back-End-Dienste, die mit globalen externen HTTP(S)-Load-Balancern (klassisch) verwendet werden.
  • Mit --logging-sample-rate können Sie einen Wert zwischen 0.0 und 1.0 angeben, wobei 0.0 dazu führt, dass keine Anfragen in Logs erfasst werden, und 1.0 bedeutet, dass 100 % der Anfragen in Logs erfasst werden. Dies ist nur mit dem Parameter --enable-logging sinnvoll. Wenn Sie das Logging aktivieren und die Abtastrate auf 0.0 festlegen, entspricht dies einer Deaktivierung des Loggings.

Logs ansehen

Klicken Sie auf Anleitung, um die Schritt-für-Schritt-Anleitung für diese Aufgabe direkt in der Google Cloud Console auszuführen:

Anleitung

HTTP(S)-Logs werden zuerst nach einer Weiterleitungsregel, dann nach einer URL-Zuordnung indexiert.

Um Logs anzuzeigen, öffnen Sie die Log-Explorer-Seite.

Zum Log-Explorer

  • Zum Ansehen aller Logs wählen Sie im Filtermenü Ressource die Option Cloud-HTTP-Load-Balancer > Alle Weiterleitungsregeln aus.

  • Wenn Sie die Logs für nur eine Weiterleitungsregel aufrufen möchten, wählen Sie den Namen einer einzelnen Weiterleitungsregel aus.

  • Um Logs für eine URL-Zuordnung aufzurufen, wählen Sie eine Weiterleitungsregel und dann eine URL-Zuordnung aus.

Boolesche Logfelder werden normalerweise nur angezeigt, wenn sie den Wert true haben. Wenn ein boolesches Feld einen Wert false hat, erscheint dieses Feld nicht im Log.

Für Logfelder wird eine UTF-8-Codierung erzwungen. Zeichen, bei denen es sich nicht um UTF-8-Zeichen handelt, werden durch Fragezeichen ersetzt. Für globale externe HTTP(S)-Load-Balancer (klassisch) und globale externe HTTP(S)-Load-Balancer können Sie logbasierte Messwerte anhand von Ressourcenlogs (resource.type="http_load_balancer") exportieren. Die erstellten Messwerte basieren auf der Ressource „Google Cloud-HTTP-Load-Balancing-Regel (logbasierte Messwerte)“ (l7_lb_rule), die in Cloud Monitoring-Dashboards verfügbar ist, und nicht auf der Ressource https_lb_rule.

Was wird protokolliert?

Die Logeinträge für den externen HTTP(S)-Load-Balancer enthalten Informationen, die Sie für das Monitoring und die Fehlerbehebung bei Ihrem HTTP(S)-Traffic verwenden können. Logeinträge enthalten Pflichtfelder. Dies sind die Standardfelder jedes Logdatensatzes.

Feld Feldformat Feldtyp: Erforderlich oder optional Beschreibung
severity
timestamp
insertID
logName		 LogEntry Erforderlich Die allgemeinen Felder, wie in einem Logeintrag beschrieben.
httpRequest HttpRequest Erforderlich Ein gängiges Protokoll für Logging von HTTP-Anfragen

HttpRequest.protocol ist nicht für resource.type="http_load_balancer" ausgefüllt

.
resource MonitoredResource Erforderlich

Die MonitoredResource ist der Ressourcentyp, der einem Logeintrag zugeordnet ist.

Der MonitoredResourceDescriptor beschreibt das Schema eines MonitoredResource-Objekts mithilfe eines Typnamens und einer Reihe von Labels. Weitere Informationen finden Sie unter Ressourcenlabels.
jsonPayload object (Struct format) Erforderlich Nutzlast des Logeintrags, die als JSON-Objekt ausgedrückt wird. Das JSON-Objekt enthält die folgenden Felder:
  • statusDetails
String Erforderlich Das Feld statusDetails enthält einen String, der erklärt, warum der Load-Balancer den entsprechenden HTTP-Status angegeben hat. Weitere Informationen zu diesen Logstrings finden Sie unter HTTP-Erfolgsmeldungen für statusDetails und HTTP-Fehlermeldungen für statusDetails.

Ressourcenlabels

In der folgenden Tabelle sind die Ressourcenlabels für resource.type="http_load_balancer" aufgeführt.

Feld Typ Beschreibung
backend_service_name String Der Name des Back-End-Dienstes.
forwarding_rule_name String Der Name des Weiterleitungsregelobjekts.
project_id String Die Kennung des Google Cloud-Projekts, das dieser Ressource zugeordnet ist.
target_proxy_name String Der Name des Ziel-Proxy-Objekts, auf das die Weiterleitungsregel verweist.
url_map_name String Der Name des URL-Zuordnungsobjekts, das für die Auswahl eines Back-End-Dienstes konfiguriert ist.
zone String Die Zone, in der der Load-Balancer ausgeführt wird. Die Zone ist global.

statusDetails-HTTP-Erfolgsmeldungen

statusDetails (erfolgreich) Bedeutung Häufige zugehörige Antwortcodes
byte_range_caching Die HTTP-Anfrage wurde mit Cloud CDN-Bytebereich-Caching bereitgestellt. Jeder cachefähige Antwortcode ist möglich.
response_from_cache Die HTTP-Anfrage wurde aus einem Cloud CDN-Cache geladen. Jeder cachefähige Antwortcode ist möglich.
response_from_cache_validated Der Rückgabecode wurde von einem im Cloud CDN-Cache gespeicherten Eintrag festgelegt, der von einem Back-End validiert wurde. Jeder cachefähige Antwortcode ist möglich.
response_sent_by_backend Die HTTP-Anfrage wurde erfolgreich an das Back-End weitergeleitet und die Antwort wurde vom Back-End zurückgegeben. Der HTTP-Antwortcode wird von der auf dem Back-End ausgeführten Software festgelegt.

statusDetails-HTTP-Fehlermeldungen

statusDetails (Fehler) Bedeutung Häufige zugehörige Antwortcodes
aborted_request_due_to_backend_early_response Eine Anfrage mit Textkörper wurde abgebrochen, weil das Back-End eine frühe Antwort mit Fehlercode geschickt hat. Die Antwort wurde an den Client weitergeleitet. Die Anfrage wurde beendet. 4XX oder 5XX
backend_connection_closed_after_partial_response_sent Die Back-End-Verbindung wurde unerwartet geschlossen, nachdem eine Teilantwort an den Client gesendet wurde. Der HTTP-Antwortcode wird von der auf dem Back-End ausgeführten Software festgelegt. Der HTTP-Antwortcode 0 (null) bedeutet, dass das Back-End unvollständige HTTP-Header gesendet hat.
backend_connection_closed_before_data_sent_to_client Das Back-End hat die Verbindung mit dem Load-Balancer unerwartet geschlossen, bevor die Antwort an den Client weitergeleitet wurde. Dies kann passieren, wenn der Load-Balancer Traffic an eine andere Entität sendet. Dabei kann es sich um einen Load-Balancer von einem Drittanbieter handeln, der ein TCP-Zeitlimit aufweist, das kürzer ist als das 10-minütige Zeitlimit des externen HTTP(S)-Load-Balancers (600 Sekunden). Der Load-Balancer des Drittanbieters wird möglicherweise auf einer VM-Instanz ausgeführt. Das Problem lässt sich unter Umständen dadurch beheben, dass für den Zieldienst ein TCP-Zeitlimit (Keepalive-Wert) von mehr als 600 Sekunden festgelegt wird. 502
backend_early_response_with_non_error_status Das Back-End hat eine fehlerfreie Antwort (1XX oder 2XX) auf eine Anfrage gesendet, bevor der gesamte Anfragetext empfangen wurde. 502
backend_interim_response_not_supported Das Back-End hat eine vorläufige 1XX-Antwort auf die Anfrage in einem Kontext gesendet, in dem vorläufige Antworten nicht unterstützt werden. 502
backend_response_corrupted Der HTTP-Antworttext, der vom Back-End gesendet wurde, hat eine ungültige, fragmentierte Übertragungscodierung oder ist anderweitig beschädigt. Abhängig von der Fehlerart ist jeder Antwortcode möglich. Oft 502.
backend_response_headers_too_long Die vom Back-End gesendeten HTTP-Antwortheader überschritten das zulässige Limit. Weitere Informationen finden Sie im Abschnitt Headergröße für externe HTTP(S)-Load-Balancer. 502
backend_timeout Es gab eine Zeitüberschreitung beim Back-End, während eine Antwort erstellt wurde. 502
banned_by_security_policy Die Anfrage wurde durch eine preisbasierte Verbotsregel in Google Cloud Armor gesperrt. 429
body_not_allowed Der Client hat eine HTTP-Anfrage mit einem Text gesendet, die HTTP-Methode ist jedoch nicht zulässig. 400
byte_range_caching_aborted Der Load-Balancer hat zuvor eine Antwort erhalten, die angab, dass die Ressource im Cache speicherbar war und Bytebereiche unterstützte. Cloud CDN hat jedoch eine inkonsistente Antwort erhalten (z. B. mit einem anderen Antwortcode als dem erwarteten „206 Partial Content“). Dies ist der Versuch, eine Cache-Füllung mit einer Bytebereichsanfrage auszuführen. Daher hat der Load-Balancer die Antwort an den Client abgebrochen. 2XX
byte_range_caching_forwarded_backend_response Der Load-Balancer hat zuvor eine Antwort erhalten, die angab, dass die Ressource im Cache speicherbar war und Bytebereiche unterstützte. Cloud CDN hat jedoch eine inkonsistente Antwort erhalten (z. B. mit einem anderen Antwortcode als dem erwarteten „206 Partial Content“). Dies ist der Versuch, eine Cache-Füllung mit einer Bytebereichsanfrage auszuführen. Der Load-Balancer hat dann die inkonsistente Antwort an den Client weitergeleitet. Wird vom Back-End zurückgegeben; jeder Antwortcode ist möglich.
byte_range_caching_retrieval_abandoned Der Client hat eine von Cloud CDN initiierte Bytebereichsanfrage oder Validierungsanfrage abgebrochen. Wird vom Back-End zurückgegeben; jeder Antwortcode ist möglich.
byte_range_caching_retrieval_from_backend_failed_after_partial_response Bei einer von Cloud CDN initiierten Bytebereichs- oder Validierungsanfrage wurde ein Fehler festgestellt. Ausführliche Informationen zum Back-End-Status finden Sie im entsprechenden Cloud Logging-Logeintrag für die von Cloud CDN initiierte Anfrage. 2XX
cache_lookup_failed_after_partial_response Aufgrund eines internen Fehlers konnte der Load-Balancer keine vollständige Antwort aus dem Cloud CDN-Cache bereitstellen. 2XX
cache_lookup_timeout_after_partial_response Es gab eine Zeitüberschreitung beim Cloud CDN-Cache, da der Client den Inhalt nicht rechtzeitig abgerufen hat. 2XX
client_disconnected_after_partial_response Die Verbindung zum Client wurde unterbrochen, nachdem der Load-Balancer eine Teilantwort gesendet hat. Wird vom Back-End zurückgegeben; jeder Antwortcode ist möglich.
client_disconnected_before_any_response Die Verbindung zum Client wurde unterbrochen, bevor der Load-Balancer eine Antwort gesendet hat. 0
client_timed_out Das Google Front End (GFE) hat die Clientverbindung aufgrund fehlender Fortschritte beim Weiterleiten der Anfrage oder Antwort deaktiviert. 0 oder 408
client_cert_invalid_rsa_key_size Ein Klientenblatt oder Zwischenzertifikat hat eine ungültige RSA-Schlüsselgröße. Weitere Informationen finden Sie unter Fehler bei geschlossenen Verbindungen protokolliert. 0
client_cert_unsupported_elliptic_curve_key Ein Client- oder ein Zwischenzertifikat verwendet eine nicht unterstützte Elliptische-Kurve. Weitere Informationen finden Sie unter Protokollierte Fehler für geschlossene Verbindungen. 0
client_cert_unsupported_key_algorithm Ein Client- oder Zwischenzertifikat verwendet einen Nicht-RSA- oder Nicht-ECDSA-Algorithmus. Weitere Informationen finden Sie unter Protokollierte Fehler für geschlossene Verbindungen. 0
client_cert_pki_too_large Die zu validierende PKI hat mehr als drei Zwischenzertifikate, die dieselben Informationen zu öffentlichen Subjekten und Antragstellern haben. Weitere Informationen findest du unter Protokollierte Fehler bei geschlossenen Verbindungen. 0
client_cert_chain_max_name_constraints_exceeded Ein Zwischenzertifikat zur Validierung hat mehr als zehn Namenseinschränkungen. Weitere Informationen finden Sie unter Protokollierte Fehler für geschlossene Verbindungen. 0
client_cert_chain_invalid_eku Entweder hat das Clientzertifikat oder sein Aussteller keine Extended Key Usage (EKU), die clientAuth enthält. Weitere Informationen finden Sie unter Protokollierte Fehler für geschlossene Verbindungen. 0
client_cert_validation_timed_out Zeitlimit während der Validierung der Zertifikatskette überschritten. Weitere Informationen finden Sie unter Protokollierte Fehler für geschlossene Verbindungen. 0
client_cert_validation_search_limit_exceeded Das Limit für Tiefe oder Iteration wird beim Versuch, die Zertifikatskette zu validieren, erreicht. Weitere Informationen finden Sie unter Protokollierte Fehler für geschlossene Verbindungen. 0
client_cert_validation_not_performed Sie haben mTLS konfiguriert, ohne TrustConfig einzurichten. Weitere Informationen finden Sie unter Protokollierte Fehler für geschlossene Verbindungen. 0
client_cert_not_provided Der Client hat das angeforderte Zertifikat nicht während des Handshakes bereitgestellt. Weitere Informationen finden Sie unter Protokollierte Fehler für geschlossene Verbindungen. 0
client_cert_validation_failed Das Clientzertifikat schlägt mit TrustConfig fehl. Weitere Informationen finden Sie unter Protokollierte Fehler für geschlossene Verbindungen. 0
config_not_found Für den Load-Balancer ist kein Back-End konfiguriert. 404 oder 503
direct_response Der Load-Balancer hat diese Anfrage überschrieben und eine feste Antwort zurückgegeben. Je nach Art des Problems wird möglicherweise ein HTTP-Antwortcode angezeigt. Der HTTP-Antwortcode 410 bedeutet beispielsweise, dass das Back-End aufgrund von Zahlungsrückstand nicht verfügbar ist.
denied_by_security_policy Der Load-Balancer hat diese Anfrage aufgrund einer Google Cloud Armor-Sicherheitsrichtlinie abgelehnt. In der Sicherheitsrichtlinie konfiguriert.
error_uncompressing_gzipped_body Es gab beim Dekomprimieren einer mit gzip komprimierten HTTP-Antwort ein Problem. 503
failed_to_connect_to_backend Der Load-Balancer konnte keine Verbindung mit dem Back-End herstellen. Dies gilt auch für Zeitüberschreitungen während der Verbindungsphase. 502
failed_to_pick_backend Der Load-Balancer konnte kein fehlerfreies Back-End für die Verarbeitung der Anfrage finden. 502
failed_to_negotiate_alpn Der Load-Balancer und das Back-End konnten kein Protokoll auf Anwendungsebene (z. B. HTTP/2) aushandeln, das für die Kommunikation über TLS verwendet wird. 502
headers_too_long Die Anfrage-Header waren größer als zugelassen. 413
http_version_not_supported HTTP-Version wird nicht unterstützt. Aktuell werden nur HTTP 0.9, 1.0, 1.1 und 2.0 unterstützt. 400
internal_error Interner Fehler beim Load-Balancer. Normalerweise stellt dies einen vorübergehenden Fehler in der Load-Balancer-Infrastruktur dar. Wiederholen Sie Ihre Abfrage. 4XX
invalid_external_origin_endpoint Die Konfiguration für das externe Back-End ist ungültig. Prüfen Sie die Internet-NEG-Konfiguration und achten Sie darauf, dass sie eine gültige FQDN/IP-Adresse und einen gültigen Port angibt. 4XX
invalid_request_headers Die HTTP-Anfrageheader eines Clients sind ungültig. 400
invalid_http2_client_header_format Die HTTP/2-Header eines Clients sind ungültig. 400
multiple_iap_policies Mehrere Richtlinien für Identity-Aware Proxy (IAP) können nicht kombiniert werden. Wenn Sie eine IAP-Richtlinie an einen Back-End-Dienst und eine weitere Richtlinie an ein serverloses Objekt angehängt haben, entfernen Sie eine der Richtlinien und versuchen Sie es noch einmal. Zu den serverlosen Objekten gehören App Engine, Cloud Run und Cloud Functions. 500
malformed_chunked_body Das Chunked Encoding des Anfragetextkörpers wurde nicht richtig durchgeführt. 411
request_loop_detected Der Load-Balancer hat eine Anfrageschleife erkannt. Diese Schleife kann durch eine fehlerhafte Konfiguration verursacht werden, bei der das Back-End die Anfrage an den Load-Balancer zurückgesendet hat. 502
required_body_but_no_content_length Die HTTP-Anfrage benötigt einen Textkörper, aber die Anfrageheader hatten keine Inhaltslänge oder einen Transfer-Chunking-Header. 400 oder 403
secure_url_rejected Eine Anfrage mit einer https://-URL wurde über eine Nur-Text-HTTP/1.1-Verbindung empfangen. 400
ssl_san_verification_failed Der Load-Balancer konnte kein SAN (Subject Alternative Name) in dem vom Back-End bereitgestellten SSL-Zertifikat finden, das mit dem konfigurierten Hostnamen übereinstimmt. 502
ssl_certificate_chain_verification_failed Das vom Back-End bereitgestellte SSL-Zertifikat ist nicht erfolgreich verifiziert. 502
throttled_by_security_policy Die Anfrage wurde durch eine Drosselungsregel von Google Cloud Armor blockiert. 429
unsupported_method Der Client hat eine nicht unterstützte HTTP-Anfragemethode geschickt. 400
unsupported_100_continue Die Clientanfrage enthielt den Header „Expected: 100-continue“ für ein Protokoll, das dies nicht unterstützt. 400
upgrade_header_rejected Die Client-HTTP-Anfrage enthielt den Upgrade-Header und wurde abgelehnt. 400
websocket_closed Die WebSocket-Verbindung wurde geschlossen. 101
websocket_handshake_failed Der WebSocket-Handshake ist fehlgeschlagen. Abhängig vom Handshake-Fehler ist jeder Antwortcode möglich.
request_body_too_large Der HTTP-Anfragetext hat den vom Back-End unterstützten Maximalwert überschritten. Gilt nicht für VM-Back-Ends. 413
handled_by_identity_aware_proxy Diese Antwort wurde von Identity-Aware Proxy während der Identitätsbestätigung des Clients generiert, bevor der Zugriff zugelassen wurde. 200, 302, 400, 401, 403, 500, 502
serverless_neg_routing_failed Die serverlose NEG-Anfrage kann nicht weitergeleitet werden. Dies kann passieren, wenn die in der NEG angegebene Region nicht erreicht oder der Ressourcenname (z. B. der Cloud Functions-Name) nicht gefunden werden kann. 404, 502
fault_filter_abort Dieser Fehler kann auftreten, wenn der Kunde einen Fehlerfilter konfiguriert hat und der Fehlerfilter für die angegebene Anfrage ausgelöst wurde. Der Wert muss zwischen 200 und 599 liegen.

Logs für die Validierung des mTLS-Clientzertifikats ansehen

Führen Sie die folgenden Schritte aus, um die protokollierten Fehler für geschlossene Verbindungen während der gegenseitigen TLS-Zertifikatvalidierung anzusehen.

Console-Abfrage

  1. Rufen Sie in der Google Cloud Console die Seite Logs-Explorer auf.

    Zum Log-Explorer

  2. Klicken Sie auf den Umschalter Abfrage anzeigen.

  3. Alternativ können Sie Folgendes in das Abfragefeld einfügen. Ersetzen Sie dabei FORWARDING_RULE_NAME durch den Namen Ihrer Weiterleitungsregel.

    jsonPayload.statusDetails=~"client_cert"
jsonPayload.@type="type.googleapis.com/google.cloud.loadbalancing.type.LoadBalancerLogEntry"
resource.labels.forwarding_rule_name=FORWARDING_RULE_NAME

  4. Klicken Sie auf Abfrage ausführen.

Logging für Back-End-Buckets

Logging wird automatisch für Load-Balancer mit Back-End-Buckets aktiviert. Sie können das Logging für Back-End-Buckets nicht ändern oder deaktivieren.

Logging für Google Cloud Armor

Die Tabelle für statusDetail-HTTP-Fehlermeldungen enthält einige Nachrichten, die für Google Cloud Armor gelten. Weitere Informationen zu den Google Cloud Armor-Logs finden Sie unter Anfrage-Logging verwenden.

Mit den Logs interagieren

Sie können mithilfe der Cloud Logging API die externen HTTP(S)-Load-Balancer-Logs interaktiv nutzen. Die Logging API bietet Möglichkeiten zum interaktiven Filtern von Logs, für die bestimmte Felder festgelegt sind. Übereinstimmende Logs werden nach Cloud Logging, Cloud Storage, BigQuery oder Pub/Sub exportiert. Weitere Informationen zur Logging API finden Sie unter Cloud Logging API.

Monitoring

Der Load-Balancer exportiert Monitoring-Daten nach Cloud Monitoring.

Sie können Monitoring-Messwerte für Folgendes verwenden:

  • Bewertung der Konfiguration, Nutzung und Leistung eines Load-Balancers
  • Fehlerbehebung
  • Verbesserung der Ressourcenauslastung und Nutzerfreundlichkeit

Zusätzlich zu den vordefinierten Dashboards in Cloud Monitoring können Sie über die Cloud Monitoring API benutzerdefinierte Dashboards erstellen, Warnungen einrichten und Messwerte abrufen.

Vordefinierte Cloud Monitoring-Dashboards aufrufen

Cloud Monitoring bietet vordefinierte Dashboards zum Monitoring Ihrer Load-Balancer. Diese Dashboards werden von Cloud Monitoring automatisch ausgefüllt.

Führen Sie die folgenden Schritte aus, um auf die vordefinierten Dashboards zuzugreifen:

  1. Rufen Sie Monitoring in der Google Cloud Console auf.

    Zu Monitoring

  2. Klicken Sie im Navigationsbereich von Monitoring auf Dashboards.

  3. Klicken Sie unter Kategorien auf GCP.

    • Wählen Sie das Dashboard mit dem Namen Google Cloud-Load-Balancer aus, um eine Liste der Dashboards für Ihre Google Cloud-Load-Balancer aufzurufen. Wenn Sie das Dashboard eines bestimmten Load-Balancers anzeigen möchten, suchen Sie den Load-Balancer in der Liste und klicken Sie auf den Namen.

    • Wählen Sie das Dashboard mit dem Namen Externe HTTP(S)-Load-Balancer aus, um nur die vordefinierten Dashboards für Ihre externen HTTP(S)-Load-Balancer aufzurufen. Auf dieser Seite wird ein Dashboard mit den 5XX-Antwortverhältnissen und der Back-End-Latenz für alle externen HTTP(S)-Load-Balancer in Ihrem Projekt angezeigt. Außerdem sehen Sie eine Liste von Dashboards für alle externen HTTP(S)-Load-Balancer in Ihrem Projekt.

      Sie können zum Dashboard des einzelnen Load-Balancers klicken. Jedes Dashboard enthält Folgendes:

      • Vorab ausgefüllte Grafiken mit Aufschlüsselungen der Antworten nach Antwortcodeklasse (5XX, 4XX, 3XX, 2XX)
      • Gesamtlatenz
      • Back-End-Latenz
      • Front-End-RTT
      • Anzahl der Anfragen
      • Link zu den Logs für den Load-Balancer

  4. Wenn Sie Dashboards für Drittanbieterdienste aufrufen möchten, kehren Sie zur Seite Dashboards zurück. Klicken Sie unter Kategorien auf Sonstige.

    • Wenn Sie ein bestimmtes Dashboard eines Drittanbieterdienstes ansehen möchten, suchen Sie es in der Liste und klicken Sie auf den Namen.

Benachrichtigungsrichtlinien definieren

Klicken Sie auf Anleitung, um die Schritt-für-Schritt-Anleitung für diese Aufgabe direkt in der Google Cloud Console auszuführen:

Anleitung

Sie können Benachrichtigungsrichtlinien erstellen, um Messwerte zu beobachten und sich informieren zu lassen, wenn diese gegen eine Bedingung verstoßen.

  1. Rufen Sie in der Google Cloud Console die Seite Monitoring auf.

    Zu Monitoring

  2. Wählen Sie im Navigationsbereich „Monitoring“ die Option Benachrichtigungen aus.
  3. Wenn Sie keine Benachrichtigungskanäle erstellt haben und Benachrichtigungen erhalten möchten, klicken Sie auf Benachrichtigungskanäle bearbeiten und fügen Sie Benachrichtigungskanäle hinzu. Kehren Sie nach dem Hinzufügen der Kanäle zur Seite Benachrichtigungen zurück.
  4. Klicken Sie auf der Seite Benachrichtigungen auf Richtlinie erstellen.
  5. Maximieren Sie zum Auswählen des Messwerts das Menü Messwert auswählen und gehen Sie dann so vor:
    1. Um das Menü auf relevante Einträge zu beschränken, geben Sie in die Filterleiste Google Cloud HTTP/S Load Balancing Rule ein. Wenn nach dem Filtern des Menüs keine Ergebnisse angezeigt werden, deaktivieren Sie die Option Nur aktive Ressourcen und Messwerte anzeigen.
    2. Wählen Sie als Ressourcentyp die Regel Google Cloud HTTP/S-Load-Balancing aus.
    3. Wählen Sie eine Messwertkategorie und einen Messwert aus und klicken Sie dann auf Übernehmen.
  6. Klicken Sie auf Next (Weiter).
  7. Die Einstellungen auf der Seite Benachrichtigungstrigger konfigurieren bestimmen, wann die Benachrichtigung ausgelöst wird. Wählen Sie einen Bedingungstyp aus und geben Sie ggf. einen Schwellenwert an. Weitere Informationen finden Sie unter Benachrichtigungsrichtlinien für Schwellenwerte erstellen.
  8. Klicken Sie auf Next (Weiter).
  9. Optional: Klicken Sie auf Benachrichtigungskanäle, um Benachrichtigungen zu Ihrer Benachrichtigungsrichtlinie hinzuzufügen. Wählen Sie im Dialogfeld einen oder mehrere Benachrichtigungskanäle aus dem Menü aus und klicken Sie dann auf OK.
  10. Optional: Aktualisieren Sie die Dauer bis zur automatischen Schließung von Vorfällen. Dieses Feld bestimmt, wann Monitoring Vorfälle ohne Messwertdaten schließt.
  11. Optional: Klicken Sie auf Dokumentation und geben Sie alle Informationen ein, die in einer Benachrichtigung angezeigt werden sollen.
  12. Klicken Sie auf Name der Benachrichtigung und geben Sie einen Namen für die Benachrichtigungsrichtlinie ein.
  13. Klicken Sie auf Richtlinie erstellen.
Weitere Informationen finden Sie unter Benachrichtigungsrichtlinien.

Benutzerdefinierte Cloud Monitoring-Dashboards definieren

Sie können benutzerdefinierte Cloud Monitoring-Dashboards für die Messwerte des Load-Balancers erstellen:

  1. Rufen Sie in der Google Cloud Console die Seite Monitoring auf.

    Zu Monitoring

  2. Wählen Sie Dashboards > Dashboard erstellen aus.

  3. Klicken Sie auf Diagramm hinzufügen und geben Sie dem Diagramm einen Namen.

  4. Wählen Sie einen Ressourcentyp und einen Messwerttyp aus, um die anzuzeigende Zeitachse zu identifizieren:

    1. Klicken Sie im Abschnitt Ressource und Messwert auf das Diagramm und wählen Sie dann im Abschnitt Messwert auswählen eine der verfügbaren Optionen aus:
      • Wählen Sie für einen globalen externen HTTP(S)-Load-Balancer den Ressourcentyp Google Cloud HTTP/S-Load-Balancing-Regel aus.
    2. Klicken Sie auf Anwenden.

  5. Klicken Sie zum Angeben von Monitoring-Filtern auf Filter > Filter hinzufügen.

  6. Klicken Sie auf Speichern.

Häufigkeit und Speicherung von Messwertberichten

Messwerte für die externen HTTP(S)-Load-Balancer werden in einminütigen Abständen zu Cloud Monitoring exportiert. Monitoring-Daten werden sechs (6) Wochen beibehalten. Messwerte basieren auf Stichproben des Traffics. Die Stichprobenrate ist dynamisch und kann nicht angepasst werden. Im Dashboard werden Datenanalysen in Standardintervallen von einer Stunde, sechs Stunden, einem Tag, einer Woche und sechs Wochen bereitgestellt. Sie können manuell Analysen in jedem beliebigen Intervall von sechs Wochen bis zu einer Minute anfordern.

Messwerte überwachen

Sie können die folgenden Messwerte für externe HTTP(S)-Load-Balancer überwachen.

Die folgenden Messwerte für globale externe HTTP(S)-Load-Balancer werden in Cloud Monitoring ermittelt: Diese Messwerte werden mit dem Präfix loadbalancing.googleapis.com/ vorangestellt:

Messwert Name Beschreibung
Anzahl der Anfragen https/request_count Die Anzahl der Anfragen, die vom externen HTTP(S)-Load-Balancer bereitgestellt wurden
Anzahl der Anfragebyte https/request_bytes_count Die Anzahl der Byte, die als Anfragen von Clients an den externen HTTP(S)-Load-Balancer gesendet wurden.
Anzahl der Antwortbyte https/response_bytes_count Die Anzahl von Byte, die als Antworten vom externen HTTP(S)-Load-Balancer an Clients gesendet wurden.
Gesamtlatenzen https/total_latencies

Eine Verteilung der Latenz. Die Latenz ist die Zeit zwischen dem ersten Byte der Anfrage und dem letzten Byte der vom GFE gesendeten Antwort.

Die Gesamtlatenzen werden nach Anfrage/Antwort gemessen. Pausen zwischen Anfragen für dieselbe Verbindung, die Connection: keep-alive verwenden, haben keine Auswirkungen auf die Messung. In Cloud Monitoring-Ansichten wird sie in der Regel auf das 95. Perzentil reduziert.

Beispiel: Ein Load-Balancer erhält aus dem Vereinigten Königreich eine Anfrage pro Sekunde mit jeweils 100 ms Latenz und aus den USA 9 Anfragen pro Sekunde mit jeweils 50 ms Latenz. In einer bestimmten Minute gingen 60 Anfragen aus dem Vereinigten Königreich und 540 Anfragen aus den USA ein. In den Monitoring-Messwerten wird die Verteilung über alle Dimensionen beibehalten. Sie können folgende Informationen anfordern:

  • Medianwert der Gesamtlatenz (300/600) – 50 ms
  • Medianwert der Latenz des Vereinigten Königreichs (30/60) – 100 ms
  • 95. Perzentil der Gesamtlatenz (570/600) – 100 ms
Front-End-RTT* https/frontend_tcp_rtt Eine Verteilung der ausgeglichenen Umlaufzeit (geglättete Umlaufzeit), die für jede Verbindung zwischen dem Client und dem GFE gemessen wurde (wird vom TCP-Stack des GFE gemessen). Die ausgeglichene RTT ist ein Algorithmus, der Varianten und Anomalien behandelt, die bei RTT-Messungen auftreten können.
Back-End-Latenzen* https/backend_latencies

Eine Verteilung der Latenz, gemessen ab dem Zeitpunkt, an dem das erste Byte der Anfrage vom GFE an das Back-End gesendet wurde, bis das GFE das letzte Byte der Antwort vom Back-End erhalten hat.

Bei WebSocket-Verbindungen gelten Back-End-Latenzen für die gesamte Dauer der WebSocket-Sitzung.
Anteil der Antwortcodeklasse Anteil der gesamten Antworten des externen HTTP(S)-Load-Balancers in jeder Antwortcodeklasse (2XX, 4XX, …). In Cloud Monitoring ist dieser Wert nur auf Standard-Dashboards verfügbar. Er ist nicht für benutzerdefinierte Dashboards verfügbar. Sie können die API verwenden, um Benachrichtigungen dafür festzulegen.
Anzahl der Back-End-Anfragen https/backend_request_count Die Anzahl der Anfragen, die vom externen HTTP(S)-Load-Balancer an die Back-Ends gesendet wurden.
Anzahl der Back-End-Anfragebyte https/backend_request_bytes_count Die Anzahl der Byte, die als Anfragen vom externen HTTP(S)-Load-Balancer an die Back-Ends gesendet wurden.
Anzahl der Back-End-Antwortbyte https/backend_response_bytes_count Die Anzahl der Byte, die als Antworten von den Back-Ends (einschließlich Cache) an den externen HTTP(S)-Load-Balancer gesendet wurden.
* Die Summe der Front-End-RTT und Back-End-Latenzen ist möglicherweise höher als die Gesamtlatenzen. Dies liegt daran, dass die RTT über den Socket vom GFE zum Client bei der Bestätigung der HTTP-Antwort abgefragt wird, für einige Messwerte jedoch Kernel-Berichte herangezogen werden. Es ist nicht sicher, dass der Kernel über einen RTT-Messwert für die jeweilige HTTP-Antwort verfügt. Das Endergebnis ist ein geglätteter RTT-Wert, der auch von vorherigen HTTP-Antworten, SYN/ACKs (Abgleichen bestätigt) und SSL-Handshakes, die sich nicht auf die tatsächlichen Zeiten von aktuellen HTTP-Anfragen auswirken, beeinflusst wird.

Dimensionen für Messwerte filtern

Sie können Filter für Messwerte für den externen HTTP(S)-Load-Balancer anwenden.

Dabei wird die GatewayClass verwendet, die einen globalen externen HTTP(S)-Load-Balancer (klassisch) bereitstellt. Sie können zusammengefasste Messwerte nach den folgenden Dimensionen für resource.type="http_load_balancer" filtern.

Attribut Beschreibung
backend_scope Der Google Cloud-Bereich (Region oder Zone) der Back-End-Dienst-Instanzgruppe, die die Verbindung bereitgestellt hat.

Wenn keine Instanzgruppe verfügbar war oder die Anfrage von einer anderen Entität verarbeitet wurde, wird anstelle der Region oder Zone der Back-End-Dienst-Instanzgruppe einer der folgenden Werte angezeigt:

  • FRONTEND_5XX: Es ist ein interner Fehler aufgetreten, bevor ein Back-End vom GFE ausgewählt werden konnte. Das GFE hat 5XX an den Client zurückgegeben.
  • INVALID_BACKEND: Das GFE konnte kein fehlerfreies Back-End finden, um diesem die Anfrage zuzuweisen, und hat deshalb eine 5XX-Antwort an den Sender der Anfrage zurückgegeben.
  • NO_BACKEND_SELECTED: Ein Fehler oder eine andere Unterbrechung ist aufgetreten, bevor ein Back-End ausgewählt werden konnte.
  • SERVED_FROM_BACKEND_BUCKET: Ein Back-End-Bucket hat die Anfrage verarbeitet.
  • SERVED_FROM_CACHE: Die Anfrage wurde von einem GFE-Cache verarbeitet, sodass kein Back-End zugewiesen wurde.
  • MULTIPLE_BACKENDS: Die Anfrage wurde von möglicherweise mehreren Back-Ends bereitgestellt. Der Cache hat mindestens eine Bytebereichsanfrage an ein anderes Back-End gesendet. Mit der Aufschlüsselung von BACKEND_SCOPE können Sie jede Anfrage vom Load-Balancer zum Back-End visualisieren.

Wenn diese Aufschlüsselung ausgewählt wird, werden in den Diagrammen Back-End-Messwerte (Load-Balancer zu Back-Ends) und nicht Front-End-Messwerte (Client-zu-Load-Balancer) angezeigt.
backend_scope = „backend_zone” Wenn die Instanzgruppe eine zonale Instanzgruppe war, ist dies die Google Cloud-Zone der Instanzgruppe, die die Anfrage des Clients verarbeitet hat. (Beispiele: us-central1-a, europe-west1-b, asia-east1-c)

Mit dieser Aufschlüsselung werden in den Diagrammen Back-End-Messwerte (Load-Balancer in Richtung der Back-Ends) und nicht Front-End-Messwerte (Client in Richtung des Load-Balancers) angezeigt.
backend_scope = „backend_region” Wenn die Instanzgruppe eine regionale Instanzgruppe war, ist dies die Google Cloud-Region der Instanzgruppe, die die Anfrage des Clients verarbeitet hat. (Beispiele: us-central1, europe-west1, asia-east1)

Mit dieser Aufschlüsselung werden in den Diagrammen Back-End-Messwerte (Load-Balancer in Richtung der Back-Ends) und nicht Front-End-Messwerte (Client in Richtung des Load-Balancers) angezeigt.
proxy_continent Kontinent des HTTP(S)-GFE, das die HTTP(S)-Verbindung beendet hat. (Beispiele: America, Europe, Asia)
backend_type = „INSTANCE GROUP” Der Name der Instanzgruppe, die die Anfrage des Clients verarbeitet hat.

Wenn keine Instanzgruppe verfügbar war oder die Anfrage von einer anderen Entität verarbeitet wurde, wird anstelle einer Instanzgruppe einer der folgenden Werte angezeigt.

  • FRONTEND_5XX: Es ist ein interner Fehler aufgetreten, bevor ein Back-End vom GFE ausgewählt werden konnte. Das GFE hat 5XX an den Client zurückgegeben.
  • INVALID_BACKEND: Das GFE konnte kein fehlerfreies Back-End finden, um diesem die Anfrage zuzuweisen, und hat deshalb eine 5XX-Antwort an den Sender der Anfrage zurückgegeben.
  • NO_BACKEND_SELECTED: Ein Fehler oder eine andere Unterbrechung ist aufgetreten, bevor ein Back-End ausgewählt werden konnte.
  • SERVED_FROM_BACKEND_BUCKET: Ein Back-End-Bucket hat die Anfrage verarbeitet.
  • SERVED_FROM_CACHE: Die Anfrage wurde von Cloud CDN verarbeitet, sodass kein Back-End zugewiesen wurde.
  • MULTIPLE_BACKENDS: Die Anfrage wurde von mehreren Back-Ends verarbeitet.

Wenn diese Aufschlüsselung ausgewählt wird, werden in den Diagrammen Back-End-Messwerte (Load-Balancer zu Back-Ends) und nicht Front-End-Messwerte (Client-zu-Load-Balancer) angezeigt.
backend_target_type = „BACKEND_SERVICE” Der Name des Back-End-Dienstes, von dem die Anfrage verarbeitet wurde.
matched_url_path_rule Die Pfadregel der URL-Zuordnung, die mit dem Präfix der HTTP(S)-Anfrage übereinstimmte (bis zu 50 Zeichen).
forwarding_rule_name Der Name der Weiterleitungsregel, die vom Client zum Senden des Requests verwendet wird.

Nächste Schritte