Logging und Monitoring für internen Application Load Balancer

Dieses Dokument bietet grundlegende Informationen zu Logging- und Monitoring-Messwerten für Interne Application Load Balancer. Die Logging- und Monitoring-Messwerte sind sowohl für regionale interne als auch für regionenübergreifende interne Application Load Balancer identisch.

Logging

Sie können Logging für jeden Backend-Dienst aktivieren. Die URL-Zuordnung eines einzelnen internen Application Load Balancers kann auf mehr als einen Backend-Dienst verweisen. Je nach Konfiguration müssen Sie möglicherweise das Logging für mehrere Backend-Dienste aktivieren.

Stichprobenentnahme und Erfassung von Logs

Google Cloud nimmt Stichproben der ausgehenden und eingehenden Pakete des Load-Balancer-Back-Ends der VM-Instanzen (virtuelle Maschine). Diese Stichprobenpakete werden verarbeitet, um Logs zu generieren.

Nicht jedes Paket wird als Stichprobe verwendet. Google Cloud nimmt je nach Umfang des Traffics auf dem physischen Host eine variable Teilmenge von Paketen. Die niedrigste Abtastrate beträgt 1 von 1.024 Paketen. Die Abtastrate wird dynamisch von Google Cloud gesteuert. Sie können die Abtastrate nicht anpassen.

Der Entnahmeprozess von Stichproben interagiert auf folgende Weise mit Firewallregeln:

  • Pakete werden vor dem Anwenden von Firewallregeln für ausgehenden Traffic als Stichprobe erfasst.
  • Pakete werden nach dem Anwenden von Firewallregeln für eingehenden Traffic als Stichprobe erfasst.

Nach dem Entnahmeprozess von Stichproben verarbeitet Google Cloud die Stichprobenpakete gemäß dem folgenden Verfahren:

  1. Aggregation: Die Stichprobenpakete werden über ein Intervall von fünf Sekunden aggregiert, um einen einzelnen Ablaufeintrag zu erzeugen.

  2. Konfigurierbare (sekundäre) Stichproben von Logs: Dies ist ein zweiter Entnahmeprozess von Stichproben, der die Abläufe erfasst. Sie steuern den Anteil der Ablaufeinträge, die als Logeinträge gemäß dem Parameter logConfig.sampleRate ausgegeben werden. Wenn logConfig.sampleRate den Wert 1.0 (100 %) hat, werden alle Stichprobenpakete verarbeitet.

  3. In Logging schreiben: Die endgültigen Logeinträge werden 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 Flusslogs enthalten. Wenn dem Eintragsformat neue optionale Felder hinzugefügt werden, enthalten die Flusslogs 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.

Eine Anleitung zum Anpassen optionaler Felder finden Sie unter Logging auf einem vorhandenen Backend-Dienst aktivieren.

Logging für vorhandenen Backend-Dienst aktivieren

Führen Sie für regionale interne Application Load Balancer die folgenden Schritte aus:

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. Klicken Sie auf Erweiterte Konfigurationen (Sitzungsaffinität, Zeitlimit für Verbindungsausgleich).

  7. Klicken Sie auf Logging aktivieren.

  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

Verwenden Sie den Befehl gcloud compute backend-services update, um den Backend-Dienst zur Aktivierung des Loggings zu aktualisieren.

gcloud compute backend-services update BACKEND_SERVICE \
    --enable-logging \
    --logging-sample-rate=RATE \
    --region=REGION \
    --logging-optional=LOGGING_OPTIONAL_MODE \
    --logging-optional-fields=OPTIONAL_FIELDS

Dabei gilt:

  • --enable-logging aktiviert das Logging für diesen Back-End-Dienst.
  • Mit --logging-sample-rate können Sie einen Wert von 0.0 bis 1.0 angeben, wobei 0.0 bedeutet, dass keine Anfragen protokolliert werden, und 1.0 bedeutet, dass 100 % der Anfragen protokolliert 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.

Führen Sie für regionenübergreifende interne Application Load Balancer die folgenden Schritte aus:

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. Klicken Sie auf Erweiterte Konfigurationen (Sitzungsaffinität, Zeitlimit für Verbindungsausgleich).

  7. Klicken Sie auf Logging aktivieren.

  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

Verwenden Sie den Befehl gcloud compute backend-services update, um den Backend-Dienst zur Aktivierung des Loggings zu aktualisieren.

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

Dabei gilt:

  • --enable-logging aktiviert das Logging für diesen Back-End-Dienst.
  • Mit --logging-sample-rate können Sie einen Wert von 0.0 bis 1.0 angeben, wobei 0.0 bedeutet, dass keine Anfragen protokolliert werden, und 1.0 bedeutet, dass 100 % der Anfragen protokolliert 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.

Nachdem Sie das Logging für den Backend-Dienst aktiviert haben, wird jede HTTP(S)-Anfrage mit Cloud Logging protokolliert.

Logs aufrufen

Rufen Sie in der Google Cloud Console die Seite Log-Explorer auf, um sich Logs anzusehen.

Interne Logs des Application Load Balancers werden zuerst nach Netzwerk und dann nach Region indexiert.

  • Wählen Sie zum Anzeigen von Logs für alle internen Application Load Balancer im ersten Drop-down-Menü die Option Regel für internen Application Load Balancer aus.
  • Wählen Sie zum Aufrufen von Logs für nur ein Netzwerk Regel für internen Application Load Balancer und anschließend den Namen eines Netzwerks aus.
  • Wählen Sie zum Anzeigen von Logs für nur eine Region des Netzwerks Regel für internen Application Load Balancer > NETWORK > REGION 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.

Sie können den Export von logbasierten Messwerten für Ressourcenlogs (resource.type="internal_http_lb_rule") konfigurieren. Die erstellten Messwerte basieren auf der Ressource „Regel für internen Application Load Balancer“, die in Cloud Monitoring-Dashboards verfügbar ist:

Zu Monitoring

Was wird protokolliert?

Die Logeinträge für den internen Application 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, die die Standardfelder jedes Logeintrags sind, und optionale Felder, die zusätzliche Informationen zu Ihrem HTTP(S)-Traffic hinzufügen. Sie können weggelassen werden, um Speicherkosten zu sparen. Folgende Informationen sind in Ihnen enthalten:

  • Allgemeine Informationen, die in Google Cloud-Logs angezeigt werden, wie Schweregrad, Projekt-ID, Projektnummer und Zeitstempel, wie in LogEntry beschrieben.
  • HttpRequest-Logfelder.

Einige Logfelder haben ein Mehrfeldformat mit mehr als einem Datenelement in einem bestimmten Feld. Das Feld tls hat beispielsweise das Format TlsDetails. Dieses Format enthält das TLS-Protokoll und die TLS-Chiffre in einem einzelnen Feld. Diese Felder mit Mehrfeldformat werden in der Datensatzformattabelle beschrieben.

Feld Typ Feldtyp: Erforderlich oder optional Beschreibung
logName String Erforderlich Ressourcenname des Logs, dessen Bestandteil der Logeintrag ist.
Im Format "projects/PROJECT_ID/logs/requests".
timestamp String Erforderlich Der Zeitpunkt, an dem die Anfrage gestellt wurde.
severity LogSeverity-Format Erforderlich Der Schweregrad des Logeintrags. Die Standardeinstellung ist LogSeverity.DEFAULT.
httpRequest HttpRequest-Objekt Erforderlich Ein HttpRequest-Proto, das die protokollierte HTTP(S)-Anfrage beschreibt.
trace String Erforderlich Der Ressourcenname des Trace, das, falls vorhanden, mit dem Logeintrag verknüpft ist. Wenn ein relativer Ressourcennamen enthalten ist, wird angenommen, dass der Name relativ zu https://tracing.googleapis.com ist. Beispiel: projects/PROJECT_ID/traces/06796866738c859f2f19b7cfb3214824

Interne Application Load Balancer unterstützen dieses Feld nicht.

spanId String Erforderlich Die Span-ID innerhalb des Trace, das mit dem Logeintrag verknüpft ist. Für Trace-Spans ist dies das Format, das die Trace API v2 verwendet, d. h. eine aus 16 Zeichen bestehende hexadezimale Codierung eines 8-Byte-Arrays, z. B. 000000000000004a.

Interne Application Load Balancer unterstützen dieses Feld nicht.

resource MonitoredResource-Objekt Erforderlich

Der überwachten Ressource, von der der Logeintrag erzeugt wurde.

Das Objekt MonitoredResourceDescriptor beschreibt das Schema eines MonitoredResource-Objekts mithilfe eines Typnamens und eines Satzes von Labels.

Beispiel: Überwachte Ressourcendeskriptoren für interne Application Load Balancer haben den Ressourcentyp internal_http_lb_rule und verwenden Ressourcenlabels, um die tatsächliche Ressource und ihre Attribute zu identifizieren. Eine Liste der Ressourcenlabels finden Sie unter Ressourcenlabels für resource.type="internal_http_lb_rule".
jsonPayload object (Struct format) Erforderlich Nutzlast des Logeintrags, die als JSON-Objekt ausgedrückt wird. Das JSON-Objekt enthält die folgenden Felder:
  • tls
  • proxyStatus
  • backendTargetProjectNumber
  • serviceDirectoryService
  • cloudFitExperiment
  • cloudFitFault
  • serviceExtensionInfo
  • mtls
String Erforderlich

Das Feld proxyStatus enthält einen String, der angibt, warum der interne Application Load Balancer HttpRequest.status zurückgegeben hat. Dieses Feld wird nur ausgefüllt, wenn der Proxy einen Fehlercode zurückgibt.

Das Feld wird nicht protokolliert, wenn der Wert ein leerer String ist. Das kann passieren, wenn der Proxy oder das Backend keinen Fehler zurückgibt oder der Fehlercode nicht 0, 4XX oder 5XX ist.

Das Feld proxyStatus besteht aus zwei Teilen:
String Erforderlich Das Feld backendTargetProjectNumber enthält die Projektnummer, die den Inhaber des Backend-Dienstes oder Backend-Buckets identifiziert.
String Erforderlich Das Feld serviceDirectoryService enthält den Namen des Service Directory-Dienstes, bei dem der Cloud FIT-Fehler konfiguriert wurde.
String Erforderlich Das Feld cloudFitExperiment enthält den Namen des Cloud FIT-Tests.
String Erforderlich Das Feld cloudFitFault enthält den Namen des Fehlers, der von einem Cloud FIT-Fehlertest in diesem Anfragepfad eingefügt wurde.
ServiceExtensionInfo Erforderlich Im Feld serviceExtensionInfo werden Informationen zu den gRPC-Streams vom Load Balancer zu Diensterweiterungen gespeichert. Weitere Informationen finden Sie unter Was für Erweiterungen mit Zusatzinformationen protokolliert wird.
TlsDetails Optional Das Feld tls enthält die TlsDetails, die die TLS-Metadaten für die Verbindung zwischen dem Client und dem internen Application Load Balancer angeben. Dieses Feld ist nur verfügbar, wenn der Client die TLS/SSL-Verschlüsselung verwendet.
MtlsDetails Optional Das Feld mtls enthält den Wert MtlsDetails, der die mTLS-Metadaten für die Verbindung zwischen dem Client und dem internen Application Load Balancer angibt. Dieses Feld ist nur verfügbar, wenn der Load-Balancer das gegenseitige TLS (mTLS) des Front-Ends verwendet.

Feldformat von TlsDetails

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 TLS 1.0, 1.1, 1.2, 1.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.

Feldformat von MtlsDetails

Feld Feldformat Feldtyp: Erforderlich oder optional Beschreibung
clientCertPresent bool Optional

true, wenn der Client während des TLS-Handshakes ein Zertifikat bereitgestellt hat; andernfalls false.
clientCertChainVerified bool Optional

true, wenn die Clientzertifikatskette mit einem konfigurierten TrustStore verglichen wird. Andernfalls false.
clientCertError String Optional

Vordefinierte Strings, die die Fehlerbedingungen darstellen. Weitere Informationen zu den Fehlerstrings finden Sie unter mTLS-Clientvalidierungsmodi.
clientCertSha256Fingerprint String Optional

Base64-codierter SHA-256-Fingerabdruck des Clientzertifikats.
clientCertSerialNumber String Optional

Die Seriennummer des Clientzertifikats. Wenn die Seriennummer länger als 50 Bytes ist, wird der String client_cert_serial_number_exceeded_size_limit zu client_cert_error hinzugefügt und die Seriennummer auf einen leeren String gesetzt.
clientCertValidStartTime String Optional

Zeitstempel (Datumsstringformat gemäß RFC 3339), vor dem das Clientzertifikat ungültig ist. Beispiel: 2022-07-01T18:05:09+00:00.
clientCertValidEndTime String Optional

Zeitstempel (Datumsstringformat gemäß RFC 3339), nach dem das Clientzertifikat ungültig ist. Beispiel: 2022-07-01T18:05:09+00:00.
clientCertSpiffeId String Optional

Die SPIFFE-ID aus dem Feld „Alternativer Antragstellername“ (SAN) Wenn der Wert ungültig ist oder 2.048 Byte überschreitet, wird die SPIFFE-ID auf einen leeren String gesetzt.

Wenn die SPIFFE-ID länger als 2.048 Bytes ist, wird der String client_cert_spiffe_id_exceeded_size_limit zu client_cert_error hinzugefügt.
clientCertUriSans String Optional

Durch Kommas getrennte Liste mit Base64-codierten SAN-Erweiterungen vom Typ URI. Die SAN-Erweiterungen werden aus dem Clientzertifikat extrahiert. Die SPIFFE-ID ist nicht im Feld client_cert_uri_sans enthalten.

Wenn das Feld client_cert_uri_sans länger als 512 Bytes ist, wird der String client_cert_uri_sans_exceeded_size_limit zu client_cert_error hinzugefügt und die durch Kommas getrennte Liste auf einen leeren String gesetzt.
clientCertDnsnameSans String Optional

Durch Kommas getrennte Liste mit Base64-codierten SAN-Erweiterungen vom Typ DNSName. Die SAN-Erweiterungen werden aus dem Clientzertifikat extrahiert.

Wenn das Feld client_cert_dnsname_sans länger als 512 Bytes ist, wird der String client_cert_dnsname_sans_exceeded_size_limit zu client_cert_error hinzugefügt und die durch Kommas getrennte Liste auf einen leeren String gesetzt.
clientCertIssuerDn String Optional

Base64-codiertes vollständiges Ausstellerfeld aus dem Zertifikat.

Wenn das Feld client_cert_issuer_dn länger als 512 Byte ist, wird der String client_cert_issuer_dn_exceeded_size_limit zu client_cert_error hinzugefügt und client_cert_issuer_dn auf einen leeren String gesetzt.
clientCertSubjectDn String Optional

Base64-codiertes vollständiges Subject-Feld aus dem Zertifikat.

Wenn das Feld client_cert_subject_dn länger als 512 Bytes ist, wird der String client_cert_subject_dn_exceeded_size_limit zu client_cert_error hinzugefügt und client_cert_subject_dn auf einen leeren String gesetzt.
clientCertLeaf String Optional

Das untergeordnete Clientzertifikat für eine hergestellte mTLS-Verbindung, bei der das Zertifikat die Validierung bestanden hat. Die Zertifikatscodierung ist RFC 9440-konform: Das binäre DER-Zertifikat wird mit Base64 codiert (ohne Zeilenumbrüche, Leerzeichen oder andere Zeichen außerhalb des Base64-Alphabets) und durch Doppelpunkte auf beiden Seiten getrennt.

Wenn client_cert_leaf 16 KB uncodiert überschreitet, wird der String client_cert_validated_leaf_exceeded_size_limit zu client_cert_error hinzugefügt und client_cert_leaf auf einen leeren String gesetzt.
clientCertChain String Optional

Die durch Kommas getrennte Liste der Zertifikate in Standard-TLS-Reihenfolge der Clientzertifikatskette für eine hergestellte mTLS-Verbindung, bei der das Clientzertifikat die Validierung bestanden hat, ohne das untergeordnete Zertifikat. Die Zertifikatscodierung ist konform mit RFC 9440.

Wenn die Gesamtgröße von client_cert_leaf und client_cert_chain vor der Base64-Codierung 16 KB überschreitet, wird der String client_cert_validated_chain_exceeded_size_limit zu client_cert_error hinzugefügt und client_cert_chain auf einen leeren String festgelegt.

proxyStatus-Fehlerfeld

Das Feld proxyStatus enthält einen String, der angibt, warum der Load-Balancer einen Fehler zurückgegeben hat. Das Feld proxyStatus besteht aus zwei Teilen: proxyStatus error und proxyStatus details. In diesem Abschnitt werden die Strings beschrieben, die im Feld proxyStatus error unterstützt werden.

Das Feld proxyStatus error gilt für die folgenden Load-Balancer:

  • Regionaler externer Application Load Balancer
  • Regionsübergreifender interner Application Load Balancer
  • Regionaler interner Application Load Balancer
proxyStatus-Fehler Beschreibung Häufige zugehörige Antwortcodes
destination_unavailable Der Load Balancer betrachtet das Backend als nicht verfügbar. Beispiel: Die letzten Kommunikationsversuche mit dem Backend sind fehlgeschlagen oder eine Systemdiagnose hat möglicherweise zu einem Fehler geführt. 500, 503
connection_timeout Beim Versuch, eine Verbindung zum Backend zu öffnen, ist eine Zeitüberschreitung aufgetreten. 504
connection_terminated

Die Verbindung des Load Balancers mit dem Backend wurde beendet, bevor eine vollständige Antwort empfangen wurde.

proxyStatus error wird in jedem der folgenden Szenarien zurückgegeben:

  • Die Verbindung des Load Balancers mit dem Backend wurde beendet, bevor eine vollständige Antwort empfangen wurde.
  • Die TLS-Verbindung ist beim SSL-Handshake fehlgeschlagen und der Client hat keine Verbindung mit dem Load-Balancer hergestellt.

 0, 502, 503
connection_refused Die Verbindung des Load-Balancers zum Backend wurde abgelehnt. 502, 503
connection_limit_reached

Der Load-Balancer ist so konfiguriert, dass er die Anzahl seiner Verbindungen zum Backend begrenzt und dieses Limit wurde überschritten.

proxyStatus error wird in jedem der folgenden Szenarien zurückgegeben:

  • Wenn sich ein Backend im Wartungsmodus befindet, kann der Traffic nicht an das Backend weitergeleitet werden.
  • Wenn die Anfrage eine lokale Ratenbegrenzung hat.
  • Envoy verarbeitet Fehlerbedingungen, z. B. wenn nicht genügend Arbeitsspeicher vorhanden ist.
 502, 503
destination_not_found Der Load-Balancer kann nicht feststellen, welches Back-End für diese Anfrage zu verwenden ist. Beispielsweise ist das Backend möglicherweise nicht konfiguriert. 500, 404
dns_error Der Load Balancer hat bei der Suche nach einer IP-Adresse für den Backend-Hostnamen einen DNS-Fehler festgestellt. 502, 503
proxy_configuration_error Der Load Balancer ist auf einen internen Konfigurationsfehler gestoßen. 500
proxy_internal_error Der Load Balancer hat einen internen Fehler festgestellt. 0, 500, 502
proxy_internal_response Der Load Balancer hat die Antwort generiert, ohne zu versuchen, eine Verbindung zum Backend herzustellen. Je nach Art des Problems ist jeder Antwortcode möglich. Der Antwortcode 410 bedeutet beispielsweise, dass das Backend aufgrund von Zahlungsrückstand nicht verfügbar ist.
http_response_timeout Der Load Balancer hat beim Warten auf die vollständige Antwort vom Backend ein konfiguriertes Zeitlimit für den Backend-Dienst erreicht. 504, 408
http_request_error Der Load Balancer hat einen HTTP-4xx-Fehler festgestellt, der auf Probleme mit der Clientanfrage hinweist. 400, 403, 405, 406, 408, 411, 413, 414, 415, 416, 417, oder 429
http_protocol_error Der Load-Balancer hat bei der Kommunikation mit dem Backend einen HTTP-Protokollfehler festgestellt. 502
tls_protocol_error Der Load Balancer hat während des TLS-Handshakes einen TLS-Fehler festgestellt. 0
tls_certificate_error Der Load Balancer hat bei der Überprüfung des vom Server oder vom Client bereitgestellten Zertifikats einen Fehler festgestellt, wenn mTLS aktiviert ist. 0
tls_alert_received Der Load-Balancer hat während des TLS-Handshakes eine schwerwiegende TLS-Benachrichtigung festgestellt. 0

proxyStatus-Detailfeld

Das Feld proxyStatus enthält einen String, der angibt, warum der Load-Balancer einen Fehler zurückgegeben hat. Das Feld proxyStatus besteht aus zwei Teilen: proxyStatus error und proxyStatus details. Das Feld proxyStatus details ist optional und wird nur angezeigt, wenn zusätzliche Informationen verfügbar sind. In diesem Abschnitt werden die Strings beschrieben, die im Feld proxyStatus details unterstützt werden.

Das Feld proxyStatus details (ProxyStatus-Details) gilt für die folgenden Load-Balancer:

  • Regionaler externer Application Load Balancer
  • Regionaler interner Application Load Balancer
  • Regionsübergreifender interner Application Load Balancer
proxyStatus-Details Beschreibung Häufige zugehörige Antwortcodes
client_disconnected_before_any_response Die Verbindung mit dem Client wurde unterbrochen, bevor der Load-Balancer eine Antwort gesendet hat. 0
backend_connection_closed Das Back-End hat die Verbindung mit dem Load Balancer unerwartet geschlossen. Dies kann vorkommen, wenn vom Load-Balancer Traffic an eine andere Entität gesendet wird, z. B. an eine Drittanbieteranwendung, deren TCP-Zeitlimit kürzer als das 10-minütige Zeitlimit des Load-Balancers (600 Sekunden) ist. 502
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. 503
failed_to_pick_backend Der Load-Balancer konnte kein fehlerfreies Back-End für die Verarbeitung der Anfrage finden. 502
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 Back-End ausgeführten Software festgelegt.
client_timed_out

Die Verbindung zwischen dem Load-Balancer und dem Client hat das Zeitlimit bei Inaktivität überschritten.

Weitere Informationen zum regionalen externen Application Load Balancer finden Sie unter Client-HTTP-Keepalive-Zeitlimit. Weitere Informationen zum internen Application Load Balancer finden Sie unter Client-HTTP-Keepalive-Zeitlimit. 		0, 408
backend_timeout

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

 502
http_protocol_error_from_backend_response Die Backend-Antwort enthält einen HTTP-Protokollfehler. 501, 502
http_protocol_error_from_request Die Clientanfrage enthält einen HTTP-Protokollfehler. 400, 503
http_version_not_supported Die HTTP-Protokollversion wird nicht unterstützt. Es werden nur HTTP 0.9, 1.0, 1.1 und 2.0 unterstützt. 400
handled_by_identity_aware_proxy Diese Antwort wurde von Identity-Aware Proxy (IAP) während der Überprüfung der Identität des Clients generiert, bevor der Zugriff zugelassen wurde. 200, 302, 400, 401, 403, 500, 502
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, 404
ip_detection_failed Die ursprüngliche IP-Adresse konnte nicht ermittelt werden. Abhängig von der Fehlerart ist jeder Antwortcode möglich. Der Wert muss zwischen 400 und 599 liegen.
request_body_too_large Der HTTP-Anfragetext hat die vom Load Balancer unterstützte maximale Länge überschritten. 413, 507
request_header_timeout Es ist eine Zeitüberschreitung für den Anfrageheader aufgetreten, da der Load-Balancer die vollständige Anfrage nicht innerhalb von fünf Sekunden erhalten hat. 408, 504
denied_by_security_policy Der Load-Balancer hat diese Anfrage aufgrund einer Google Cloud Armor-Sicherheitsrichtlinie abgelehnt. 403
throttled_by_security_policy Die Anfrage wurde durch eine Drosselungsregel von Google Cloud Armor blockiert. 429
client_cert_chain_invalid_eku Entweder hat das Clientzertifikat oder sein Aussteller keine erweiterte Schlüsselnutzung, die clientAuth enthält. 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 10 Namenseinschränkungen.. Weitere Informationen finden Sie unter Protokollierte Fehler für geschlossene Verbindungen. 0
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_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_pki_too_large Die für die Validierung zu verwendende PKI hat mehr als drei Zwischenzertifikate, die dieselben Subject und Subject Public Key Info haben. 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_validation_failed Die Validierung des Clientzertifikats mit dem TrustConfig schlägt fehl. Weitere Informationen finden Sie unter Protokollierte Fehler für geschlossene Verbindungen. 0
client_cert_validation_not_performed Sie haben die gegenseitige TLS-Authentifizierung konfiguriert, ohne eine TrustConfig einzurichten. 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_timed_out Das Zeitlimit (200 ms) wurde beim Validieren der Zertifikatskette überschritten. Weitere Informationen finden Sie unter Protokollierte Fehler für geschlossene Verbindungen. 0
tls_version_not_supported Die TLS-Protokollversion wird erkannt, aber nicht unterstützt. Der Fehler führt zu einer geschlossenen TLS-Verbindung. 0
unknown_psk_identity Server senden diesen Fehler, wenn die PSK-Schlüsseleinrichtung erforderlich ist, der Client jedoch keine zulässige PSK-Identität angibt. Der Fehler führt zu einer geschlossenen TLS-Verbindung. 0
no_application_protocol Wird von Servern gesendet, wenn ein Client mit der Erweiterung „application_layer_protocol_negotiation“ nur Protokolle bewirbt, die der Server nicht unterstützt. Weitere Informationen finden Sie unter Erweiterung der TLS-Protokollverhandlung auf Anwendungsebene. Der Fehler führt zu einer geschlossenen TLS-Verbindung. 0
no_certificate Es wurde kein Zertifikat gefunden. Der Fehler führt zu einer geschlossenen TLS-Verbindung. 0
bad_certificate Ein Zertifikat ist ungültig oder enthält Signaturen, die nicht überprüft werden konnten. Der Fehler führt zu einer geschlossenen TLS-Verbindung. 0
unsupported_certificate Ein Zertifikat hat einen nicht unterstützten Typ. Der Fehler führt zu einer geschlossenen TLS-Verbindung. 0
certificate_revoked Ein Zertifikat wurde von seinem Unterzeichner widerrufen. Der Fehler führt zu einer geschlossenen TLS-Verbindung. 0
certificate_expired Ein Zertifikat ist abgelaufen oder ungültig. Der Fehler führt zu einer geschlossenen TLS-Verbindung. 0
certificate_unknown Bei der Verarbeitung des Zertifikats sind einige nicht spezifizierte Probleme aufgetreten, die es inakzeptabel machten. Der Fehler führt zu einer geschlossenen TLS-Verbindung. 0
unknown_ca Es wurde eine gültige Zertifikatskette oder eine Teilkette empfangen, aber das Zertifikat wurde nicht akzeptiert, weil das CA-Zertifikat nicht gefunden oder mit einem bekannten Vertrauensanker abgeglichen werden konnte. Der Fehler führt zu einer geschlossenen TLS-Verbindung. 0
unexpected_message Eine ungeeignete Nachricht, wie z. B. eine falsche Handshake-Nachricht oder vorzeitige Anwendungsdaten, wurde empfangen. Der Fehler führt zu einer geschlossenen TLS-Verbindung. 0
bad_record_mac Ein Eintrag wurde empfangen, dessen Schutz nicht aufgehoben werden kann. Der Fehler führt zu einer geschlossenen TLS-Verbindung. 0
record_overflow Es wurde ein TLSCiphertext-Datensatz mit einer Länge von mehr als 214+256 Byte empfangen, oder ein Datensatz wurde in einen TLSPlaintext-Datensatz mit mehr als 214 Byte (oder einem anderen vereinbarten Limit) entschlüsselt. Der Fehler führt zu einer geschlossenen TLS-Verbindung. 0
handshake_failure Es konnte keine akzeptable Sicherheitsparameterliste ausgehandelt werden, da die verfügbaren Optionen nicht ausreichen. Der Fehler führt zu einer geschlossenen TLS-Verbindung. 0
illegal_parameter Ein Feld im Handshake war falsch oder stimmt nicht mit anderen Feldern überein. Der Fehler führt zu einer geschlossenen TLS-Verbindung. 0
access_denied Es wurde ein gültiges Zertifikat oder PSK empfangen, aber als die Zugriffssteuerung angewendet wurde, hat der Client die Verhandlung nicht fortgesetzt. Der Fehler führt zu einer geschlossenen TLS-Verbindung. 0
decode_error Eine Nachricht konnte nicht decodiert werden, da einige Felder außerhalb des angegebenen Bereichs lagen oder die Nachricht falsch war. Der Fehler führt zu einer geschlossenen TLS-Verbindung. 0
decrypt_error Eine kryptografische Operation des Handshakes (nicht des Datensatzes) ist fehlgeschlagen, z. B. konnte eine Signatur nicht korrekt verifiziert oder eine fertige Nachricht oder ein PSK-Binder nicht validiert werden. Der Fehler führt zu einer geschlossenen TLS-Verbindung. 0
insufficient_security Eine Verhandlung ist insbesondere fehlgeschlagen, weil der Server sicherere Parameter erfordert als die vom Client unterstützten. Der Fehler führt zu einer geschlossenen TLS-Verbindung. 0
inappropriate_fallback Wird von einem Server als Antwort auf einen ungültigen Verbindungswiederherstellungsversuch von einem Client gesendet. Der Fehler führt zu einer geschlossenen TLS-Verbindung. 0
user_cancelled Der Nutzer bricht den Handshake aus irgendeinem Grund ab, der nicht mit einem Protokollfehler zusammenhängt. Der Fehler führt zu einer geschlossenen TLS-Verbindung. 0
missing_extension Wird von Endpunkten gesendet, die eine Handshake-Nachricht empfangen, die keine Erweiterung enthält, die für die angebotene TLS-Version oder andere ausgehandelte Parameter obligatorisch ist. Der Fehler führt zu einer geschlossenen TLS-Verbindung. 0
unsupported_extension Wird von Endpunkten gesendet, die eine Handshake-Nachricht empfangen, die eine Erweiterung enthält, von der bekannt ist, dass sie nicht in die betreffende Handshake-Nachricht aufgenommen werden darf, oder die eine Erweiterung in ServerHello oder Certificate enthält, die nicht zuerst in den entsprechenden ClientHello oder CertificateRequest angeboten wurde. Der Fehler führt zu einer geschlossenen TLS-Verbindung. 0
unrecognized_name Wird von Servern gesendet, wenn es keinen Server gibt, der anhand des vom Client über die Erweiterung „server_name“ angegebenen Namens identifiziert werden kann. Siehe Definitionen von TLS-Erweiterungen. 0
bad_certificate_status_response Von Clients gesendet, wenn der Server eine ungültige oder inakzeptable OCSP-Antwort über die Erweiterung "status_request" bereitstellt. Weitere Informationen finden Sie unter Definitionen von TLS-Erweiterungen. Der Fehler führt zu einer geschlossenen TLS-Verbindung. 0
load_balancer_configured_resource_limits_reached Der Load Balancer hat die konfigurierten Ressourcenlimits erreicht, z. B. die maximale Anzahl von Verbindungen. 400, 500, 503

Logeinträge für fehlgeschlagene TLS-Verbindungen

Wenn die TLS-Verbindung zwischen dem Client und dem Load-Balancer fehlschlägt, bevor ein Backend ausgewählt wird, werden die Fehler in Logeinträgen aufgezeichnet. Sie können die Back-End-Dienste mit unterschiedlichen Log-Stichprobenraten konfigurieren. Wenn eine TLS-Verbindung fehlschlägt, ist die Stichprobenrate der Protokolle für die fehlgeschlagene TLS-Verbindung die höchste Stichprobenrate für alle Backend-Dienste. Wenn Sie beispielsweise zwei Back-End-Dienste mit den Protokollierungsstichprobenraten 0.3 und 0.5 konfiguriert haben, ist die Stichprobenrate für Protokolle fehlgeschlagener TLS-Verbindungen 0.5.

Sie können fehlgeschlagene TLS-Verbindungen identifizieren, indem Sie auf die folgenden Logeintragsdetails prüfen:

  • Typ des proxyStatus-Fehlers ist tls_alert_received, tls_certificate_error, tls_protocol_error oder connection_terminated.
  • Es gibt keine Backend-Informationen.

Das folgende Beispiel zeigt einen fehlgeschlagenen TLS-Logeintrag mit dem Feld proxyStatus error:

   json_payload:    {
   @type: "type.googleapis.com/google.cloud.loadbalancing.type.LoadBalancerLogEntry"
   proxyStatus: "error="tls_alert_received"; details="server_to_client: handshake_failure""
   log_name: "projects/529254013417/logs/mockservice.googleapis.com%20name"
   }
   http_request {
    latency {
      nanos: 12412000
    }
    protocol: "HTTP/1.0"
    remote_ip: "127.0.0.2"
   }
  resource {
    type: "mock_internal_http_lb_rule"
    labels {
      backend_name: ""
      backend_scope: ""
      backend_scope_type: "UNKNOWN"
      backend_target_name: ""
      backend_target_type: "UNKNOWN"
      backend_type: "UNKNOWN"
      forwarding_rule_name: "l7-ilb-https-forwarding-rule-dev"
      matched_url_path_rule: "UNKNOWN"
      network_name: "lb-network"
      region: "REGION"
      target_proxy_name: "l7-ilb-https-proxy-dev"
      url_map_name: ""
    }
  }
  timestamp: "2023-08-15T16:49:30.850785Z"

Ressourcenlabels

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

Feld Typ Beschreibung
network_name String Der Name des VPC-Netzwerks des Load-Balancers.
project_id String Die Kennung des Google Cloud-Projekts, das dieser Ressource zugeordnet ist.
region String Die Region, in der der Load-Balancer definiert ist.
url_map_name String Der Name des URL-Zuordnungsobjekts, das für die Auswahl eines Backend-Dienstes konfiguriert ist.
forwarding_rule_name String Der Name des Weiterleitungsregelobjekts.
target_proxy_name String Der Name des Ziel-Proxy-Objekts, auf das die Weiterleitungsregel verweist.
matched_url_path_rule String 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 die Standardpfadregel verwendet wird.
  • UNKNOWN zeigt einen internen Fehler an.
backend_target_name String Der Name des Back-Ends, das für die Anfrage ausgewählt wurde, auf Basis der Pfadregel oder Routingregel der URL-Zuordnung, die mit der Anfrage übereinstimmt.
backend_target_type String Der Typ des Backend-Ziels (BACKEND_SERVICE/UNKNOWN).
backend_name String Der Name der Backend-Instanzgruppe oder der NEG.
backend_type String

Der Typ des Back-Ends, entweder eine Instanzgruppe oder eine NEG oder unbekannt.

Cloud Logging protokolliert Anfragen, wenn backend_type UNKNOWN ist, auch wenn das Logging deaktiviert ist. Wenn ein Client beispielsweise die Verbindung zum Load-Balancer schließt, bevor der Load-Balancer ein Backend auswählen kann, wird backend_type auf UNKNOWN gesetzt und die Anfrage wird protokolliert. Diese Logs bieten nützliche Informationen zur Fehlerbehebung bei Clientanfragen, die geschlossen wurden, da der Load-Balancer kein Backend auswählen konnte.
backend_scope String Der Bereich des Back-Ends (entweder ein Zonenname oder ein Regionsname). Kann UNKNOWN sein, wenn backend_name unbekannt ist.
backend_scope_type String Der Bereich des Back-Ends (REGION/ZONE). Kann UNKNOWN sein, wenn backend_name unbekannt ist.
backend_target_cross_project_id String Die Projekt-ID des Backend-Zieldienstes oder -Buckets. Dieses Feld ist nur verfügbar, wenn die Backend-Zielressource in einem anderen Projekt als dem Projekt erstellt wird, in dem die url_map-Ressource erstellt wird.

Protokolle 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.

Feld Typ Beschreibung
authz_info.policies[] Objekt Die Liste der Richtlinien, die mit der Anfrage übereinstimmen.
authz_info.policies[].name String Der Name der Autorisierungsrichtlinie, die der Anfrage entspricht.
Der Name ist aus den folgenden Gründen leer:
  • Es gibt keine ALLOW-Richtlinie, die der Anfrage entspricht, 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 Dazu gehören:
  • 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:

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-Clientzertifikat-Validierung aufzurufen.

Console

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

    Zum Log-Explorer

  2. Klicken Sie auf den Schalter Abfrage anzeigen, um den Abfrageeditor zu aktivieren.

  3. Fügen Sie Folgendes in das Abfragefeld ein. Ersetzen Sie FORWARDING_RULE_NAME durch den Namen der 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.

Monitoring

Interne Application Load Balancer exportieren Monitoringdaten nach Monitoring.

Monitoring-Messwerte können für Folgendes verwendet werden:

  • 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 Monitoring API benutzerdefinierte Dashboards erstellen, Benachrichtigungen einrichten und Messwerte abrufen.

Cloud Monitoring-Messwerte anzeigen

Console

So rufen Sie mit dem Metrics Explorer die Messwerte für eine überwachte Ressource auf:

  1. Rufen Sie in der Google Cloud Console die Seite  Metrics Explorer auf:

    Zum Metrics Explorer

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

  2. Maximieren Sie im Element Messwert das Menü Messwert auswählen, geben Sie Internal Application Load Balancer Rule in die Filterleiste ein und wählen Sie dann über die Untermenüs einen bestimmten Ressourcentyp und Messwert aus:
    1. Wählen Sie im Menü Aktive Ressourcen die Option Regel für internen Application Load Balancer aus.
    2. Einen Messwert wählen Sie in den Menüs Aktive Messwertkategorien und Aktive Messwerte aus.
    3. Klicken Sie auf Anwenden.

  3. Verwenden Sie das Element Filter, um Zeitreihen aus der Anzeige zu entfernen.

  4. Verwenden Sie zum Kombinieren von Zeitreihen die Menüs im Element Aggregation. Wenn Sie beispielsweise die CPU-Auslastung für Ihre VMs basierend auf ihrer Zone anzeigen möchten, legen Sie das erste Menü auf Mittelwert und das zweite Menü auf Zone fest.

    Alle Zeitreihen werden angezeigt, wenn das erste Menü des Elements Aggregation auf Nicht aggregiert gesetzt ist. Die Standardeinstellungen für das Element Aggregation werden durch den ausgewählten Messwerttyp bestimmt.

  5. Gehen Sie für Kontingente und andere Messwerte, die eine Stichprobe pro Tag melden, so vor:
    1. Legen Sie im Bereich Anzeige den Widget-Typ auf Gestapeltes Balkendiagramm fest.
    2. Legen Sie als Zeitraum mindestens eine Woche fest.

Benachrichtigungsrichtlinien definieren

Console

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 Internal 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 Regel für internen Application Load Balancer 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 Benachrichtigungsrichtlinien.

Benutzerdefinierte Monitoring-Dashboards definieren

Console

Sie können benutzerdefinierte Monitoring-Dashboards über interne Messwerte des Application 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.

  4. Geben Sie dem Diagramm einen Namen.

  5. Wählen Sie Messwerte und Filter aus. Bei Messwerten lautet der Ressourcentyp Interner HTTP(S)-Load-Balancer.

  6. Klicken Sie auf Speichern.

Häufigkeit und Speicherung von Messwertberichten

Messwerte für die Load-Balancer werden in Batches mit einminütiger Granularität in 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 für interne Application Load Balancer überwachen

Die folgenden Messwerte für interne Application Load Balancer werden an Monitoring gemeldet:

Messwert FQDN Beschreibung
Anzahl der Anfragen loadbalancing.googleapis.com/https/internal/request_count Die Anzahl der Anfragen, die vom internen Application Load Balancer verarbeitet wurden.
Anzahl der Anfragebyte loadbalancing.googleapis.com/https/internal/request_bytes Die Anzahl der Byte, die als Anfragen von Clients an den internen Application Load Balancer gesendet wurden.
Anzahl der Antwortbyte loadbalancing.googleapis.com/https/internal/response_bytes Die Anzahl der Byte, die als Antworten vom internen HTTP(S)-Load-Balancer an den Client gesendet wurden.
Gesamtlatenzen loadbalancing.googleapis.com/https/internal/total_latencies Eine Verteilung der Latenz in Millisekunden. Die Latenz wird von dem Zeitpunkt, an dem der Proxy das erste Byte der Anfrage empfängt, bis zu dem Zeitpunkt gemessen, an dem der Proxy das letzte Byte der Antwort sendet.
Back-End-Latenzen loadbalancing.googleapis.com/https/internal/backend_latencies Eine Verteilung der Latenz in Millisekunden. Die Latenz wird ab dem Zeitpunkt gemessen, an dem der Proxy das erste Byte der Anfrage an das Backend sendet, bis zu dem Zeitpunkt, an dem der Proxy das letzte Byte der Antwort vom Backend empfängt.

Dimensionen für interne Application Load Balancer-Messwerte filtern

Die Messwerte werden für jeden internen Application Load Balancer zusammengefasst. Sie können zusammengefasste Messwerte nach den folgenden Dimensionen filtern:

Attribut Beschreibung
BACKEND_SCOPE Die Google Cloud-Zone oder -Region der Back-End-Gruppe, von der die Clientanfrage verarbeitet wurde, oder ein spezieller String für Fälle, in denen die Back-End-Gruppe nicht zugewiesen wurde. Beispiele: us-central1-a, europe-west1-b, asia-east1, UNKNOWN.
PROXY_REGION Region des internen Application Load Balancers, des Clients und des Back-Ends. Beispiele: us-central1, europe-west1 oder asia-east1.
BACKEND Der Name der Back-End-Instanzgruppe oder der NEG, von denen die Clientanfrage verarbeitet wurde.
BACKEND_TARGET Der Name des Back-End-Dienstes, von dem die Clientanfrage verarbeitet wurde.
MATCHED_URL_RULE Die Pfadregel oder Routingregel der URL-Zuordnung, die mit dem Präfix der HTTP(S)-Clientanfrage übereinstimmte (bis zu 50 Zeichen).

Der Messwert Response code class fraction wird für den gesamten Load-Balancer unterstützt. Es wird keine weitere Granularität unterstützt.

Nächste Schritte