Logging und Monitoring für globalen externen Application Load Balancer

In diesem Dokument erfahren Sie, wie Sie Cloud Logging und Cloud Monitoring mit klassischen Application Load Balancern, globalen externen Application Load Balancern und Cloud CDN konfigurieren und verwenden.

Logging

Sie können Logs für den Backend-Dienst eines externen Application Load Balancers aktivieren, deaktivieren und aufrufen. Für externe Application Load Balancer mit Backend-Buckets wird das Logging automatisch aktiviert und kann nicht deaktiviert werden.

Sie aktivieren oder deaktivieren Logging für jeden Backend-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 Application Load Balancer gilt. Informationen dazu, wie Sie prüfen, ob Cloud HTTP Load Balancer-Logs zulässig sind, finden Sie unter Ausschlussfilter.

Stichprobenentnahme und Erfassung von Logs

Die Anfragen (und entsprechenden Antworten), die von den Instanzen der virtuellen Maschinen (VM) im Backend des Load-Balancers verarbeitet werden, werden in Stichproben erfasst. Diese Anfragen mit Stichproben werden dann verarbeitet, um Logs zu generieren. Sie steuern den Anteil der Anfragen, die als Logeinträge gemäß dem Parameter logConfig.sampleRate ausgegeben werden. Wenn logConfig.sampleRate den Wert 1.0 (100%) hat, werden Logs für alle Anfragen generiert und in Cloud Logging geschrieben.

Optionale Felder

Logdatensätze umfassen Pflichtfelder und optionale Felder. Im Abschnitt Was wird protokolliert? werden die optionalen Felder und die erforderlichen Felder aufgeführt. Alle Pflichtfelder sind immer enthalten. Sie können festlegen, welche optionalen Felder beibehalten werden.

  • Wenn Sie Alle optionalen einschließen auswählen, sind alle optionalen Felder im Logdatensatzformat in den Logs enthalten. Wenn dem Eintragsformat neue optionale Felder hinzugefügt werden, enthalten die Logs automatisch die neuen Felder.

  • Wenn Sie Alle optionalen ausschließen auswählen, werden alle optionalen Felder weggelassen.

  • Wenn Sie Benutzerdefiniert auswählen, können Sie die optionalen Felder angeben, die Sie einschließen möchten, z. B. tls.protocol,tls.cipher,orca_load_report.cpu_utilization,orca_load_report.mem_utilization.

Informationen zum Anpassen optionaler Felder finden Sie unter Logging auf einem neuen Backend-Dienst aktivieren.

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 Backend-Konfiguration.

  5. Wählen Sie Backend-Dienst erstellen aus.

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

  7. Wählen Sie im Bereich Logging die Option Logging aktivieren aus.

  8. Legen Sie einen Anteilswert für die Abtastrate 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. Optional: Wenn Sie alle optionalen Felder in die Logs aufnehmen möchten, klicken Sie im Abschnitt Optionale Felder auf Alle optionalen Felder einschließen.

  10. Klicken Sie auf Aktualisieren, um das Bearbeiten des Backend-Dienstes abzuschließen.

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

gcloud: Modus "Global"

Erstellen Sie einen Backend-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 \
    --logging-optional=LOGGING_OPTIONAL_MODE \
    --logging-optional-fields=OPTIONAL_FIELDS

Der Befehl gcloud compute backend-services create unterstützt die folgenden Felder:

  • --global gibt an, dass der Backend-Dienst global ist. Verwenden Sie dieses Feld für Backend-Dienste, die mit globalen externen Application Load Balancern verwendet werden.
  • --enable-logging aktiviert das Logging für diesen Backend-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. Dieses Feld 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

  • Mit --logging-optional können Sie die optionalen Felder angeben, die in den Logs enthalten sein sollen:

    • INCLUDE_ALL_OPTIONAL, um alle optionalen Felder einzuschließen.

    • EXCLUDE_ALL_OPTIONAL (Standard), um alle optionalen Felder auszuschließen.

    • CUSTOM zum Hinzufügen einer benutzerdefinierten Liste von optionalen Feldern, die Sie in OPTIONAL_FIELDS angeben.

  • Mit --logging-optional-fields können Sie eine durch Kommas getrennte Liste optionaler Felder angeben, die in die Logs aufgenommen werden sollen.

    Beispiel: tls.protocol,tls.cipher kann nur festgelegt werden, wenn LOGGING_OPTIONAL_MODE auf CUSTOM eingestellt ist. Wenn Sie benutzerdefinierte Messwerte verwenden und Elemente des ORCA-Ladeberichts protokollieren möchten, legen Sie LOGGING_OPTIONAL_MODE auf CUSTOM fest und geben Sie im Feld OPTIONAL_FIELDS an, welche Elemente protokolliert werden müssen. Beispiel: orca_load_report.cpu_utilization,orca_load_report.mem_utilization.

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 Backend-Konfiguration.

  5. Klicken Sie neben Ihrem Backend-Dienst auf  Bearbeiten.

  6. Wählen Sie im Bereich Logging die Option Logging aktivieren aus.

  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 Backend-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 Backend-Dienst mit dem Befehl gcloud compute backend-services update.

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

Dabei gilt:

  • --global gibt an, dass der Backend-Dienst global ist. Verwenden Sie dieses Feld für Backend-Dienste, die mit globalen externen Application Load Balancern verwendet werden.
  • --enable-logging aktiviert das Logging für diesen Backend-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 Backend-Dienst mit dem Befehl gcloud compute backend-services update.

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

Dabei gilt:

  • --global gibt an, dass der Backend-Dienst global ist. Verwenden Sie dieses Feld für Backend-Dienste, die mit einem klassischen Application Load Balancer verwendet werden.
  • --enable-logging aktiviert das Logging für diesen Backend-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 Backend-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 Backend-Konfiguration.

  5. Klicken Sie neben Ihrem Backend-Dienst auf  Bearbeiten.

  6. Wenn Sie das Logging vollständig deaktivieren möchten, entfernen Sie im Bereich Logging das Häkchen aus dem Kästchen Logging aktivieren.

  7. Wenn das Logging aktiviert bleibt, können Sie einen anderen Anteilswert als Abtastrate 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. 0.2 bedeutet beispielsweise, dass für 20% der Stichprobenanfragen Logs generiert werden.

  8. Klicken Sie auf Aktualisieren, um das Bearbeiten des Backend-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 Backend-Dienst mit dem Befehl gcloud compute backend-services update.

Logging vollständig deaktivieren

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

Dabei gilt:

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

Optionale Logging-Felder für einen vorhandenen Backend-Dienst aktivieren

gcloud compute backend-services update BACKEND_SERVICE \
    --global \
    --enable-logging \
    --logging-sample-rate=VALUE \
    --logging-optional=LOGGING_OPTIONAL_MODE \
    --logging-optional-fields=OPTIONAL_FIELDS

Dabei gilt:

  • 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

  • Mit --logging-optional können Sie die optionalen Felder angeben, die in den Logs enthalten sein sollen:

    • INCLUDE_ALL_OPTIONAL, um alle optionalen Felder einzuschließen.

    • EXCLUDE_ALL_OPTIONAL (Standard), um alle optionalen Felder auszuschließen.

    • CUSTOM zum Hinzufügen einer benutzerdefinierten Liste von optionalen Feldern, die Sie in OPTIONAL_FIELDS angeben.

  • Mit --logging-optional-fields können Sie eine durch Kommas getrennte Liste optionaler Felder angeben, die in die Logs aufgenommen werden sollen.

    Beispiel: tls.protocol,tls.cipher kann nur festgelegt werden, wenn LOGGING_OPTIONAL_MODE auf CUSTOM eingestellt ist. Wenn Sie benutzerdefinierte Messwerte verwenden und Elemente des ORCA-Ladeberichts protokollieren möchten, legen Sie LOGGING_OPTIONAL_MODE auf CUSTOM fest und geben Sie im Feld OPTIONAL_FIELDS an, welche Elemente protokolliert werden müssen. Beispiel: orca_load_report.cpu_utilization,orca_load_report.mem_utilization.

Aktualisieren des optionalen Logging-Modus von CUSTOM auf andere

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

Dabei gilt:

  • Mit --logging-optional können Sie die optionalen Felder angeben, die in den Logs enthalten sein sollen:

    • INCLUDE_ALL_OPTIONAL, um alle optionalen Felder einzuschließen.

    • EXCLUDE_ALL_OPTIONAL (Standard), um alle optionalen Felder auszuschließen.

  • --logging-optional-fields muss explizit konfiguriert werden, wie gezeigt, um alle vorhandenen CUSTOM-Felder zu löschen. Über die API können Sie keinen Modus, der nicht CUSTOM ist, mit CUSTOM-Feldern kombinieren.

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 Backend-Dienst mit dem Befehl gcloud compute backend-services update.

Logging vollständig deaktivieren

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

Dabei gilt:

  • --global gibt an, dass der Backend-Dienst global ist. Verwenden Sie dieses Feld für Backend-Dienste, die mit einem klassischen Application Load Balancer verwendet werden.
  • --no-enable-logging deaktiviert das Logging für diesen Backend-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 Backend-Dienst global ist. Verwenden Sie dieses Feld für Backend-Dienste, die mit einem klassischen Application Load Balancer 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

Eine detaillierte Anleitung dazu finden Sie direkt in der Google Cloud Console. Klicken Sie dazu einfach auf Anleitung:

Anleitung

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

Um Logs anzusehen, ö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 den Wert false hat, wird es nicht im Log ausgegeben.

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 klassische Application Load Balancer und globale externe Application Load Balancer können Sie logbasierte Messwerte mithilfe von Ressourcenlogs (resource.type="http_load_balancer") exportieren. Die erstellten Messwerte basieren auf der Ressource Application Load Balancer Rule (Logs-based Metrics) (l7_lb_rule), die in Cloud Monitoring-Dashboards und nicht unter der Ressource https_lb_rule verfügbar ist.

Was wird protokolliert?

Die Logeinträge des externen Application Load Balancers enthalten Informationen, die für das Monitoring und die Fehlerbehebung bei Ihrem HTTP(S)-Traffic nützlich sind. Logeinträge enthalten Pflichtfelder. Dies sind die Standardfelder jedes Logdatensatzes.

Logeinträge umfassen optionale Felder mit zusätzlichen Informationen zum HTTP(S)-Traffic. Sie können weggelassen werden, um Speicherkosten zu sparen.

Einige Logfelder haben ein Mehrfeldformat mit mehr als einem Datenelement in einem bestimmten Feld. Das Feld tls hat beispielsweise das Format TlsInfo. Dieses Format enthält das Feld earlyDataRequest. Diese Felder mit Mehrfeldformat werden in der Datensatzformattabelle beschrieben.

Feld Feldformat Feldtyp: Erforderlich oder optional Beschreibung
Schweregrad
insertID
logName		 LogEntry Erforderlich Die allgemeinen Felder, wie in einem Logeintrag beschrieben.
timestamp string (Timestamp format) Optional Die Uhrzeit, zu der die Anfrage vom ersten Layer-GFE empfangen wird.
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
  • backendTargetProjectNumber
  • overrideResponseCode
  • errorService
  • errorBackendStatusDetails
  • authzPolicyInfo
  • loadBalancingScheme
  • tls
  • orca_load_report
String Erforderlich Das Feld statusDetails enthält einen String, der erklärt, warum der Load-Balancer den entsprechenden HTTP-Statuscode angegeben hat. Weitere Informationen zu diesen Logstrings finden Sie unter HTTP-Erfolgsmeldungen für statusDetails und HTTP-Fehlermeldungen für statusDetails.
String Erforderlich Das Feld backendTargetProjectNumber enthält die Projektnummer, in der das Backend-Ziel – Backend-Dienst oder Backend-Bucket – erstellt wurde. Dieses Feld hat das folgende Format: "projects/PROJECT_NUMBER". Diese Informationen sind nur für globale externe Application Load Balancer verfügbar, die benutzerdefinierte Fehlermeldungen verwenden.
Ganzzahl Erforderlich Der overrideResponseCode enthält den überschriebenen Antwortcode, der auf die an den Client gesendete Antwort angewendet wird. Diese Informationen sind nur für globale externe Application Load Balancer verfügbar, die benutzerdefinierte Fehlerantworten verwenden.
String Erforderlich Das Feld errorService enthält den Backend-Dienst, der die benutzerdefinierte Fehlerantwort bereitgestellt hat. Diese Informationen sind nur für globale externe Application Load Balancer verfügbar, die benutzerdefinierte Fehlermeldungen verwenden.
String Erforderlich Das Feld errorBackendStatusDetails enthält die statusDetails der endgültigen Antwort, die dem Client bereitgestellt wird. Diese Informationen sind nur für globale externe Application Load Balancer verfügbar, die benutzerdefinierte Fehlermeldungen verwenden.
AuthzPolicyInfo Erforderlich Im Feld authzPolicyInfo werden Informationen zum Ergebnis der Autorisierungsrichtlinie gespeichert. Diese Informationen sind nur für globale externe Application Load Balancer verfügbar, für die Autorisierungsrichtlinien aktiviert sind. Weitere Informationen finden Sie unter Was wird für Autorisierungsrichtlinien protokolliert?.
String Optional Das Feld loadBalancingScheme wird nur ausgefüllt, wenn Sie die Migrationsfunktion für den klassischen Application Load Balancer verwenden. Dieses Feld enthält einen String, der das Load-Balancing-Schema beschreibt, das zum Weiterleiten der Anfrage verwendet wurde. Die möglichen Werte sind EXTERNAL oder EXTERNAL_MANAGED.
TlsInfo Erforderlich

Das Feld tls enthält das Feld TlsInfo, das die TLS-Metadaten für die Verbindung zwischen dem Client und dem Load Balancer angibt. Dieses Feld ist nur verfügbar, wenn der Client die TLS/SSL-Verschlüsselung verwendet.

Mit dem Parameter --logging-optional-fields können Sie angeben, welche Elemente protokolliert werden müssen:

  • Optional: tls.protocol
  • Optional: tls.cipher
  • Erforderlich: tls.earlyDataRequest

Sie können --logging-optional-fields nicht auf tls festlegen, um alle Elemente anzugeben.
OrcaLoadReport Optional

Das Feld orca_load_report enthält einige oder alle Elemente des ORCA-Ladeberichts, der vom Backend zurückgegeben wird. Dieses Feld ist nur vorhanden, wenn das Backend einen ORCA-Lastbericht zurückgibt und Sie den Load Balancer so konfiguriert haben, dass der ORCA-Lastbericht protokolliert wird.

Mit dem Parameter --logging-optional-fields können Sie angeben, welche der folgenden Elemente des ORCA-Ladeberichts protokolliert werden müssen:

  • orca_load_report.cpu_utilization
  • orca_load_report.mem_utilization
  • orca_load_report.request_cost
  • orca_load_report.utilization
  • orca_load_report.rps_fractional
  • orca_load_report.eps
  • orca_load_report.named_metrics
  • orca_load_report.application_utilization

Sie können --logging-optional-fields auch auf orca_load_report festlegen, um anzugeben, dass alle Elemente protokolliert werden müssen.

Feldformat von TlsInfo

Feld Feldformat Feldtyp: Erforderlich oder optional Beschreibung
protocol String Optional TLS-Protokoll, mit dem Clients eine Verbindung mit dem Load Balancer herstellen können. Mögliche Werte sind TLSv1, TLSv1.1, TLSv1.2, TLSv1.3 oder QUIC. Dieser Wert wird auf NULL gesetzt, wenn der Client keine TLS/SSL-Verschlüsselung verwendet.
cipher String Optional TLS-Chiffre, mit der Clients eine Verbindung mit dem Load Balancer herstellen können. Dieser Wert wird auf NULL gesetzt, wenn der Client kein HTTP(S) verwendet oder der Client keine TLS/SSL-Verschlüsselung verwendet.
earlyDataRequest boolean Erforderlich Die Anfrage enthält Early Data im TLS-Handshake.

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 Backend-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 Backend-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 Bytebereich-Caching von Cloud CDN gestellt. Jeder cachefähige Antwortcode ist möglich.
response_from_cache Die HTTP-Anfrage kam vom Cloud CDN-Cache. 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 bestätigt wurde. Jeder cachefähige Antwortcode ist möglich.
response_sent_by_backend Die HTTP-Anfrage wurde erfolgreich an das Backend weitergeleitet und die Antwort wurde vom Backend zurückgegeben. Der HTTP-Antwortcode wird von der auf dem Backend ausgeführten Software festgelegt.

statusDetails-HTTP-Fehlermeldungen

statusDetails (Fehler) Bedeutung Häufige zugehörige Statuscodes
aborted_request_due_to_backend_early_response Eine Anfrage mit Textkörper wurde abgebrochen, weil das Back-End eine frühe Antwort mit Statuscode gesendet 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 geschickt wurde.

Der HTTP-Statuscode wird von der auf dem Back-End ausgeführten Software festgelegt. Der HTTP-Statuscode 0 (null) bedeutet, dass das Backend unvollständige HTTP-Header gesendet hat.

Der HTTP-Statuscode ist 101, wenn die HTTP(S)-Verbindung auf eine WebSocket-Verbindung aktualisiert wurde.
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.

502, 503

Der HTTP-Statuscode ist 101, wenn die HTTP(S)-Verbindung auf eine WebSocket-Verbindung aktualisiert wurde.
backend_early_response_with_non_error_status Das Back-End hat einen fehlerfreien Statuscode (1XX oder 2XX) auf eine Anfrage gesendet, bevor der gesamte Anfragetextkörper empfangen wurde. 502, 503
backend_interim_response_not_supported Das Back-End hat einen vorläufigen Statuscode 1XX für die Anfrage in einem Kontext gesendet, in dem vorläufige Antworten nicht unterstützt werden.

502, 503
backend_response_corrupted Der HTTP-Antworttextkörper vom Back-End hatte eine ungültige, aufgeteilte Transferverschlüsselung oder war anderweitig fehlerhaft. Abhängig von der Fehlerart ist jeder Statuscode möglich. Oft 502, 503.
backend_response_headers_too_long Die vom Back-End gesendeten HTTP-Antwortheader überschritten das zulässige Limit. Weitere Informationen finden Sie im Abschnitt Header-Größe für externe Application Load Balancer. 502, 503
backend_timeout

Es gab eine Zeitüberschreitung beim Back-End, während eine Antwort erstellt wurde.

Bei einer WebSocket-Verbindung:

  • Beim globalen externen Application Load Balancer wird ein Statuscode generiert, wenn das GFE die WebSocket-Verbindung im inaktiven Zustand schließt, nachdem das Zeitüberschreitung des Backend-Diensts abgelaufen ist.
  • Beim klassischen Application Load Balancer wird ein Statuscode generiert, wenn das GFE die WebSocket-Verbindung entweder im inaktiven oder aktiven Zustand schließt, nachdem das Zeitüberschreitung des Backend-Dienstes abgelaufen ist.

502, 503

Der HTTP-Statuscode ist 101, wenn die HTTP(S)-Verbindung auf eine WebSocket-Verbindung aktualisiert wurde.
banned_by_security_policy Die Anfrage wurde durch eine preisbasierte Verbotsregel in Cloud Armor gesperrt. 429
body_not_allowed Der Client hat eine HTTP-Anfrage mit einem Textkörper gesendet, aber die verwendete HTTP-Methode lässt keinen Textkörper zu. 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 eine inkonsistente Antwort erhalten (z. B. mit einem anderen Statuscode 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 eine inkonsistente Antwort erhalten (z. B. mit einem anderen Statuscode 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 Backend zurückgegeben. Jeder Statuscode ist möglich.
byte_range_caching_retrieval_abandoned Der Client hat eine von Cloud CDN initiierte Bytebereichs- oder Validierungsanfrage abgebrochen.

Wird vom Backend zurückgegeben. Jeder Statuscode 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 Der Load-Balancer hat aufgrund eines internen Fehlers keine vollständige Antwort aus dem Cloud CDN-Cache zurückgegeben. 2XX
cache_lookup_timeout_after_partial_response Es ist eine Zeitüberschreitung für den Cloud CDN-Cache aufgetreten, da der Client den Inhalt nicht rechtzeitig abgerufen hat. 2XX
client_disconnected_after_partial_response Die Verbindung mit dem Client wurde unterbrochen, nachdem der Load-Balancer eine Teilantwort gesendet hat.

Wird vom Backend zurückgegeben. Jeder Statuscode ist möglich.

Der HTTP-Statuscode ist 101, wenn die HTTP(S)-Verbindung auf eine WebSocket-Verbindung aktualisiert wurde.
client_disconnected_before_any_response Die Verbindung mit dem Client wurde unterbrochen, bevor der Load-Balancer eine Antwort gesendet hat.

0

Der HTTP-Statuscode ist 101, wenn die HTTP(S)-Verbindung auf eine WebSocket-Verbindung aktualisiert wurde.
client_timed_out Das Google Front End (GFE) hat die Clientverbindung aufgrund fehlenden Fortschritts während der Weiterleitung der Anfrage oder Antwort unterbrochen. 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 Protokollierte Fehler für geschlossene Verbindungen. 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 für die Validierung zu verwendende PKI hat mehr als zehn Zwischenzertifikate, die dieselben Subject- und Subject Public-Key-Informationen haben. Weitere Informationen finden Sie unter Protokollierte Fehler für geschlossene Verbindungen. 0
client_cert_chain_max_name_constraints_exceeded Ein Zwischenzertifikat zur Validierung hatte 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 Erweiterte Schlüsselverwendung (EKU), die clientAuth enthält. Weitere Informationen finden Sie unter Protokollierte Fehler für geschlossene Verbindungen. 0
client_cert_validation_timed_out Das Zeitlimit wurde beim Prüfen 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 die Tiefe oder Iteration wurde beim Prüfen der Zertifikatskette erreicht. Weitere Informationen finden Sie unter Protokollierte Fehler für geschlossene Verbindungen. 0
client_cert_validation_not_performed Sie haben mTLS konfiguriert, ohne eine TrustConfig einzurichten. Weitere Informationen finden Sie unter Protokollierte Fehler für geschlossene Verbindungen. 0
client_cert_not_provided Der Client hat das angeforderte Zertifikat während des Handshakes nicht bereitgestellt. Weitere Informationen finden Sie unter Protokollierte Fehler für geschlossene Verbindungen. 0
client_cert_validation_failed Das Clientzertifikat schlägt bei der Validierung mit TrustConfig fehl, wenn Hash-Algorithmen wie MD4, MD5 und SHA-1 verwendet werden. Weitere Informationen finden Sie unter Protokollierte Fehler für geschlossene Verbindungen. 0
config_not_found

Beim Load Balancer fehlt die Projektkonfiguration. Dies kann gelegentlich vorkommen, insbesondere nachdem Sie Konfigurationsänderungen vorgenommen haben, durch die eine neue Ressource hinzugefügt wird.

Eine weitere mögliche Ursache für den Fehler ist, dass das GFE der ersten Ebene das GFE der zweiten Ebene nicht erreichen kann. Dies kann auf einen internen Fehler zurückzuführen sein, z. B. auf einen laufenden Rollout, eine Überlastung des Load Balancers oder zeitweilige Konfigurationsprobleme.

Diese Fehler sind vorübergehend und fallen unter das SLA. Wenn die Fehlerrate jedoch 0, 01 % übersteigt, wenden Sie sich bitte an denGoogle Cloud -Support.

 404, 502, 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-Statuscode angezeigt. Der HTTP-Statuscode 410 bedeutet beispielsweise, dass das Backend 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. 502, 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, 503
failed_to_pick_backend Der Load-Balancer konnte kein fehlerfreies Back-End für die Verarbeitung der Anfrage finden. 502, 503
failed_to_negotiate_alpn Der Load-Balancer und das Back-End konnten kein Protokoll auf Anwendungsebene (z. B. HTTP/2) aushandeln, um über TLS miteinander zu kommunizieren. 502, 503
headers_too_long Die Anfrage-Header waren größer als zugelassen. 413
http_version_not_supported HTTP-Version wird nicht unterstützt. Es 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 oder 5XX
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 von einem Client empfangenen HTTP-Anfrageheader enthalten mindestens ein Zeichen, das gemäß einer anwendbaren HTTP-Spezifikation nicht zulässig ist.

Beispielsweise sind Header-Feldnamen mit einem doppelten Anführungszeichen (") oder Zeichen außerhalb des standardmäßigen ASCII-Bereichs (d. h. alle Byte >= 0x80) ungültig.

Weitere Informationen finden Sie unter:

 400
invalid_http2_client_header_format Die HTTP/2-Header eines Clients sind ungültig. Weitere Informationen finden Sie unter invalid_request_headers. 400
invalid_http2_client_request_path

Der HTTP/2-Anfragepfad von einem Client enthält mindestens ein Zeichen, das gemäß der URI-Spezifikation nicht zulässig ist.

Weitere Informationen finden Sie unter 3.3. Abschnitt „Path“ in RFC 3986.

 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 Run 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, 503
required_body_but_no_content_length Die HTTP-Anfrage benötigt einen Textkörper, aber die Anfrage-Header hatten keine Inhaltslänge oder einen transferverschlüsselten, aufgeteilten Header. 400, 403, 411
secure_url_rejected Eine Anfrage mit einer https://-URL wurde über eine reine Textverbindung mit HTTP/1.1 empfangen. 400
server_cert_chain_exceeded_limit Die Serverzertifikatskette ist zu lang (mehr als 10 Zwischenzertifikate, die im Serverzertifikat enthalten sind). 502, 503

server_cert_chain_invalid_eku

 Das Serverzertifikat hat ein Erweiterungsfeld Extended Key Usage (EKU), das jedoch nicht serverAuth enthält.

server_cert_chain_max_name_constraints_exceeded

 Ein Zwischenzertifikat zur Validierung hatte mehr als 10 Namenseinschränkungen. 502, 503
server_cert_exceeded_size_limit Die Nutzlast des Serverzertifikats (einschließlich Zwischenzertifikaten) ist zu groß (über 16 KB). 503
server_cert_invalid_rsa_key_size

Ein Server- oder Zwischenzertifikat hat eine ungültige RSA-Schlüsselgröße.

Es wird keine Validierung durchgeführt.

RSA-Schlüssel können zwischen 2.048 und 4.096 Bit lang sein.

 503
server_cert_not_provided Der Server hat das angeforderte Zertifikat während des Handshakes nicht bereitgestellt. 503
server_cert_pki_too_large

Die für die Validierung zu verwendende PKI hat mehr als zehn Zwischenzertifikate, die dieselben Subject- und Subject Public-Key-Informationen haben.

Es wird keine Validierung durchgeführt.

 503
server_cert_trust_config_not_found Keine passenden TrustConfig gefunden. 503
server_cert_unsupported_elliptic_curve_key

Ein Server- oder Zwischenzertifikat verwendet eine nicht unterstützte elliptische Kurve.

Es wird keine Validierung durchgeführt.

Gültige Kurven sind P-256 und P-384.

 503
server_cert_unsupported_key_algorithm

Ein Server- oder Zwischenzertifikat verwendet einen Nicht-RSA- oder Nicht-ECDSA-Algorithmus.

Es wird keine Validierung durchgeführt.

 503
server_cert_validation_internal_error Interner Fehler beim Validieren der Zertifikatskette. 503
server_cert_validation_not_performed

Sie haben mTLS konfiguriert, ohne eine TrustConfig-Ressource einzurichten.

 503
server_cert_validation_search_limit_exceeded

Das Limit für die Tiefe oder Iteration wurde beim Prüfen der Zertifikatskette erreicht.

Die maximale Tiefe für eine Zertifikatskette beträgt zehn, einschließlich der Root- und Serverzertifikate. Die maximale Anzahl der Iterationen beträgt 100 (Zertifikate, die zur Validierung der Serverzertifikatskette geprüft werden).

 503
server_cert_validation_timed_out Das Zeitlimit wurde beim Prüfen der Zertifikatskette überschritten. 503
server_cert_validation_unavailable Der Dienst kann die Zertifikatskette nicht validieren. 503
ssl_certificate_san_verification_failed Der Load-Balancer kann keinen alternativen Antragstellernamen (SAN) im SSL-Zertifikat finden, das vom Back-End bereitgestellt wird und mit dem konfigurierten Hostnamen übereinstimmt. 502, 503
ssl_certificate_chain_verification_failed Die Überprüfung des vom Back-End bereitgestellten SSL-Zertifikats ist fehlgeschlagen. 502, 503
throttled_by_security_policy Die Anfrage wurde durch eine Drosselungsregel von 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 „Expect: 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 Statuscode 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ätsüberprüfung des Clients generiert, bevor der Zugriff zugelassen wurde.

200, 302, 400, 401, 403, 500, 502, 503

429 (durch IAP gedrosselt)
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 Run Functions-Name) nicht gefunden werden kann. 404, 502, 503
fault_filter_abort Dieser Fehler kann auftreten, wenn der Kunde einen Fehlerfilter konfiguriert hat und dieser für die jeweilige Anfrage ausgelöst wurde. Der Wert muss zwischen 200 und 599 liegen.
early_data_rejected

Die in TLS Early Data gesendete Anfrage war ungültig.

Dies kann unter anderem in den folgenden Fällen passieren:

  • Für TargetHttpsProxy ist „TLS Early Data“ auf STRICT festgelegt, die Anfrage enthielt jedoch Abfrageparameter.
  • Für TargetHttpsProxy ist „TLS Early Data“ auf STRICT oder PERMISSIVE festgelegt, aber für die Anfrage wurde eine nicht idempotente HTTP-Methode (z. B. POST oder PUT) verwendet.
 425

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-Clientzertifikatsvalidierung aufzurufen.

Console-Abfrage

  1. Rufen Sie in der Google Cloud Console die Seite „Log-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 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.

Logs für Autorisierungsanfragen

Das authz_info-Objekt in der JSON-Nutzlast des Load-Balancer-Logeintrags enthält Informationen zu Autorisierungsrichtlinien. Sie können logbasierte Messwerte für Traffic konfigurieren, der durch diese Richtlinien zugelassen oder abgelehnt wird. Weitere Informationen zu Autorisierungsrichtlinien

Feld Typ Beschreibung
authz_info.policies[] Objekt Die Liste der Richtlinien, die der Anfrage entsprechen.
authz_info.policies[].name String Der Name der Autorisierungsrichtlinie, die der Anfrage entspricht.

Der Name ist aus folgenden Gründen leer:

  • Keine ALLOW-Richtlinie entspricht der Anfrage und die Anfrage wird abgelehnt.
  • Keine DENY-Richtlinie entspricht der Anfrage und die Anfrage ist zulässig.
authz_info.policies[].result enum Das Ergebnis kann ALLOWED oder DENIED sein:
authz_info.policies[].details String Die Details umfassen Folgendes:
  • allowed_as_no_deny_policies_matched_request
  • denied_as_no_allow_policies_matched_request
  • denied_by_authz_extension
  • denied_by_cloud_iap
authz_info.overall_result enum Das Ergebnis kann ALLOWED oder DENIED sein:

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 Cloud Armor

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

Logging für Bereitstellungen freigegebener VPCs

Logs und Messwerte des Anwendungs-Load-Balancers werden normalerweise in das Projekt exportiert, das die Weiterleitungsregel hat. Daher haben Dienstadministratoren – Inhaber oder Nutzer von Projekten, in denen der Backend-Dienst erstellt wird – standardmäßig keinen Zugriff auf die Logs und Messwerte des Load Balancers. Sie können IAM-Rollen verwenden, um Dienstadministratoren diese Berechtigungen zu erteilen. Weitere Informationen zu den verfügbaren IAM-Rollen und den Schritten zum Bereitstellen eines Zugriffs finden Sie unter Zugriff auf Monitoring gewähren.

Mit den Logs interagieren

Sie können mithilfe der Cloud Logging API die externen Logs für Application Load Balancer 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 Monitoringdaten nach 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 Monitoring können Sie über die Cloud Monitoring API benutzerdefinierte Dashboards erstellen, Warnungen einrichten und Messwerte abfragen.

Vordefinierte Cloud Monitoring-Dashboards aufrufen

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

Load-Balancer werden nicht als überwachbare Ressource angezeigt, sofern im aktuellen Projekt kein Load-Balancer vorhanden ist.

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

  1. Rufen Sie in der Google Cloud Console die Seite Monitoring 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 alle 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 Externer Application Load Balancer aus, um nur die vordefinierten Dashboards für Ihre externen Application Load Balancer aufzurufen. Auf dieser Seite wird ein Dashboard mit den 5XX-Antwortverhältnissen und der Backend-Latenz für alle externen Application Load Balancer in Ihrem Projekt angezeigt. Außerdem sehen Sie eine Liste von Dashboards für alle externen Application 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 Statuscodeklassen (5XX, 4XX, 3XX, 2XX)
      • Gesamtlatenz
      • Backend-Latenz
      • Frontend-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

Eine detaillierte Anleitung dazu finden Sie direkt in der Google Cloud Console. Klicken Sie dazu einfach auf Anleitung:

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 Benachrichtigungen auf:

    Zu Benachrichtigungen

    Wenn Sie diese Seite über die Suchleiste suchen, wählen Sie das Ergebnis aus, dessen Zwischenüberschrift Monitoring ist.

  2. 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.
  3. Klicken Sie auf der Seite Benachrichtigungen auf Richtlinie erstellen.
  4. 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 Global External Application Load Balancer 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 Option Globale externe Application Load Balancer-Regel aus.
    3. Wählen Sie eine Messwertkategorie und einen Messwert aus und klicken Sie dann auf Übernehmen.
  5. Klicken Sie auf Weiter.
  6. 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 mit Messwertschwellen erstellen.
  7. Klicken Sie auf Weiter.
  8. 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.
  9. Optional: Aktualisieren Sie die Dauer bis zur automatischen Schließung von Vorfällen. Dieses Feld bestimmt, wann Monitoring Vorfälle ohne Messwertdaten schließt.
  10. Optional: Klicken Sie auf Dokumentation und geben Sie alle Informationen ein, die in einer Benachrichtigung angezeigt werden sollen.
  11. Klicken Sie auf Name der Benachrichtigung und geben Sie einen Namen für die Benachrichtigungsrichtlinie ein.
  12. Klicken Sie auf Richtlinie erstellen.
Weitere Informationen finden Sie unter Benachrichtigungen.

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 Application Load Balancer den Ressourcentyp Globale externe Application Load Balancer-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 Application Load Balancer werden in einminütigen Abständen zu Cloud Monitoring exportiert. Monitoring-Daten werden sechs (6) Wochen beibehalten.

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 Application Load Balancer überwachen.

Die folgenden Messwerte für globale externe Application Load Balancer werden an Cloud Monitoring gemeldet. 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 Application Load Balancer verarbeitet wurden
Anzahl der Anfragebyte https/request_bytes_count Die Anzahl der Byte, die als Anfragen von Clients an den externen Application Load Balancer gesendet wurden
Anzahl der Antwortbyte https/response_bytes_count Die Anzahl der Byte, die als Antworten vom externen Application Load Balancer an Clients gesendet wurden
Gesamtlatenzen https/total_latencies

Eine Verteilung der Gesamtlatenz. Die Gesamtlatenz ist die Zeit in Millisekunden zwischen dem ersten Byte der Anfrage, das vom Proxy empfangen wird, und dem letzten Byte der Antwort, das vom Proxy gesendet wird. Sie umfasst die Zeit, die der Proxy zum Verarbeiten der Anfrage benötigt, die Zeit, die zum Senden der Anfrage vom Proxy an das Backend benötigt wird, die Zeit, die das Backend zum Verarbeiten der Anfrage benötigt, die Zeit, die zum Senden der Antwort zurück an den Proxy benötigt wird, und die Zeit, die der Proxy zum Verarbeiten der Antwort und zum Senden der Antwort an den Client benötigt.

Sie enthält nicht die RTT zwischen dem Client und dem Proxy. Außerdem wirken sich Pausen zwischen Anfragen an dieselbe Verbindung mit Connection: keep-alive nicht auf die Messung aus. In Cloud Monitoring-Ansichten ist die Messung normalerweise auf das 95. Perzentil reduziert.

Bei WebSocket-Verbindungen bezieht sich dieses Feld auf die gesamte Dauer der Verbindung.*

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 beispielsweise folgende Informationen anfordern:

  • Medianwert der Gesamtlatenz (300/600) – 50 ms
  • Medianwert der Latenz Vereinigtes Königreich (30/60) – 100 ms
  • 95. Perzentil der Gesamtlatenz (570/600) – 100 ms
Frontend-RTT† https/frontend_tcp_rtt

Eine Verteilung der Frontend-RTT. Die Frontend-RTT ist die Zeit in Millisekunden, die Daten benötigen, um vom Client zum Proxy und zurück zu gelangen. Sie umfasst die Zeit, die eine Anfrage benötigt, um vom Client zum Proxy und vom Proxy zurück zum Client zu gelangen. Dieser Wert wird während der Lebensdauer der Verbindung nicht aktualisiert. Das Einrichten einer (TCP-)Verbindung mit einem 3-Way-Handshake würde beispielsweise 1, 5 RTTs dauern.

Bei der Verarbeitung von Anfragen wird die Zeit, die Daten für die Hin- und Rückreise zwischen dem Client und dem Proxy benötigen, vom Load-Balancer gemessen und gemittelt. Anschließend wird ein geglätteter RTT-Wert protokolliert. Die geglättete RTT ist ein Algorithmus, der Varianten und Anomalien behandelt, die bei RTT-Messungen auftreten können.
Backend-Latenzen† https/backend_latencies

Eine Verteilung der Backend-Latenz. Die Back-End-Latenz ist die Zeit in Millisekunden zwischen dem letzten Byte der Anfrage, das an das Back-End gesendet wird, und dem letzten Byte der Antwort, das vom Proxy empfangen wird. Sie umfasst die Zeit, die das Backend zum Verarbeiten der Anfrage benötigt, und die Zeit, die zum Senden der Antwort zurück an den Proxy benötigt wird.
Anteil der Antwortcodeklasse Anteil der gesamten Antworten des externen Application Load Balancers in jeder Antwortcodeklasse (2XX, 4XX, …). In Monitoring ist dieser Wert nur auf Standard-Dashboards verfügbar. Er ist nicht für benutzerdefinierte Dashboards verfügbar. Sie können die Monitoring API verwenden, um Benachrichtigungen dafür festzulegen.
Anzahl der Back-End-Anfragen https/backend_request_count Die Anzahl der Anfragen, die vom externen Application Load Balancer an die Back-Ends gesendet wurden.
Anzahl der Backend-Anfragebyte https/backend_request_bytes_count Die Anzahl der Byte, die als Anfragen vom externen Application Load Balancer an die Back-Ends gesendet wurden.
Anzahl der Backend-Antwortbyte https/backend_response_bytes_count Die Anzahl der Byte, die als Antworten von den Back-Ends (einschließlich Cache) an den externen Application Load Balancer gesendet wurden.

* Wenn Sie Websocket-Verbindungen überwachen möchten, erstellen Sie einen Backend-Dienst speziell für Websockets.

† Die Summe der Frontend-RTT und Backend-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 externe Application Load Balancer anwenden.

Die Messwerte werden für jeden klassischen Application Load Balancer und globalen externen Application Load Balancer aggregiert. Sie können zusammengefasste Messwerte nach den folgenden Dimensionen für resource.type="http_load_balancer" oder resource.type="https_lb_rule" filtern. Hinweis: Nicht alle Dimensionen sind für alle Messwerte verfügbar.

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 oder eine URL-Weiterleitung erfolgt ist.
  • MULTIPLE_BACKENDS: Die Anfrage wurde von möglicherweise mehreren Back-Ends bereitgestellt. Dies kann passieren, wenn Cloud CDN die Anfrage teilweise aus dem Cache bereitgestellt und auch mindestens eine Bytebereichsanfrage an das Back-End gesendet hat. Mit der Aufschlüsselung von backend_scope können Sie jede Anfrage vom Load-Balancer zum Back-End visualisieren.

Mit dieser Aufschlüsselung werden in den Diagrammen Backend-Messwerte (Load-Balancer in Richtung der Backends) und nicht Frontend-Messwerte (Client in Richtung des Load-Balancers) angezeigt.
backend_type

Der Name der Backend-Gruppe, die die Anfrage des Clients verarbeitet hat. Kann INSTANCE GROUP oder NETWORK_ENDPOINT_GROUP sein, oder UNKNOWN, wenn das Backend nicht zugewiesen wurde. Wenn keine Backend-Gruppe verfügbar war oder die Anfrage von einer anderen Entität verarbeitet wurde, wird anstelle einer Backend-Gruppe 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 oder eine URL-Weiterleitung erfolgt ist.
  • MULTIPLE_BACKENDS: Die Anfrage wurde von möglicherweise mehreren Back-Ends bereitgestellt. Dies kann passieren, wenn Cloud CDN die Anfrage teilweise aus dem Cache bereitgestellt und auch mindestens eine Bytebereichsanfrage an das Back-End gesendet hat. Mit der Aufschlüsselung von backend_scope können Sie jede Anfrage vom Load-Balancer zum Back-End visualisieren.
backend_target_type Der Name des Back-End-Dienstes, von dem die Anfrage verarbeitet wurde. Kann BACKEND_SERVICE, BACKEND_BUCKET, UNKNOWN sein, wenn das Backend nicht zugewiesen wurde, oder NO_BACKEND_SELECTED, wenn vor der Auswahl eines Backends ein Fehler oder eine andere Unterbrechung aufgetreten ist oder eine URL-Weiterleitung stattgefunden hat.
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.
url_map_name

Die Pfadregel oder Routingregel der URL-Zuordnung, die als Teil des URL-Zuordnungsschlüssels konfiguriert ist. Kann UNMATCHED oder UNKNOWN als Fallback sein.

  • UNMATCHED verweist auf eine Anfrage, die mit keiner URL-Pfadregel übereinstimmt, sodass url_map_name die Standardpfadregel verwendet.
  • UNKNOWN zeigt einen internen Fehler an.
target_proxy_name Der Name des HTTP(S)-Ziel-Proxy-Objekts, auf das die Weiterleitungsregel verweist.
backend_target_name Der Name des Backend-Ziels. Das Ziel kann entweder ein Backend-Dienst oder ein Backend-Bucket sein. UNKNOWN wird zurückgegeben, wenn kein Backend zugewiesen wurde.
backend_name Der Name der Back-End-Instanzgruppe, des Buckets oder der NEG. UNKNOWN wird zurückgegeben, wenn das Backend nicht zugewiesen wurde, oder NO_BACKEND_SELECTED, wenn vor der Auswahl eines Backends ein Fehler oder eine andere Unterbrechung aufgetreten ist oder eine URL-Weiterleitung stattgefunden hat.
backend_scope_type

Der Typ des Bereichs der Backend-Gruppe. Kann GLOBAL, REGION, ZONE, MULTIPLE_BACKENDS oder NO_BACKEND_SELECTED sein, wenn ein Fehler oder eine andere Unterbrechung aufgetreten ist, bevor ein Backend ausgewählt wurde, oder eine URL-Weiterleitung stattgefunden hat, oder andere mögliche Ausgaben vom Typ „backend_type“.

MULTIPLE_BACKENDS wird verwendet, wenn Chunk-Caching verwendet wird. Mehrere Abfragen werden für verschiedene Datenblöcke an dasselbe Back-End gesendet, um eine einzelne Clientanfrage zu unterstützen.
proxy_continent Kontinent des HTTP(S)-GFE, das die HTTP(S)-Verbindung beendet hat, z. B. America, Europe, Asia.
protocol Vom Client verwendetes Protokoll, eines der folgenden: HTTP/1.0, HTTP/1.1, HTTP/2.0, QUIC/HTTP/2.0, UNKNOWN.
response_code Der HTTP-Statuscode der Anfrage.
response_code_class Die HTTP-Statuscodeklasse der Anfrage: 200, 300, 400, 500 oder 0 für keine Angabe.
cache_result Cache-Ergebnis für die HTTP-Anfrage per Proxy: HIT, MISS, DISABLED, PARTIAL_HIT (für eine Anfrage, die teilweise aus dem Cache und teilweise vom Backend bedient wird) oder UNKNOWN.
client_country Land des Clients, der die HTTP-Anfrage gesendet hat, z. B. United States oder Germany.
load_balancing_scheme Das verwendete Load-Balancing-Schema. Wenn der klassische Application Load Balancer verwendet wird, ist der Wert EXTERNAL. Wenn ein globaler externer Application Load Balancer verwendet wird, ist der Wert EXTERNAL_MANAGED.

Nächste Schritte