Logging und Monitoring für Proxy-Network-Load-Balancer

Auf dieser Seite erfahren Sie, wie Sie Cloud Logging und Cloud Monitoring für Proxy-Network-Load-Balancer konfigurieren und verwenden.

Ressourcen beobachten

In der folgenden Tabelle sind die Ressourcennamen für die Load Balancer aufgeführt.

Regionaler externer Proxy-Network Load Balancer

Regionaler interner Proxy-Network Load Balancer

Regionsübergreifender interner Proxy-Network Load Balancer

Globaler externer Proxy-Network Load Balancer

Klassischer Proxy-Network Load Balancer
Typ der überwachten Ressource in Logging erfassen „Regel für Proxy-Network Load Balancer“
l4_proxy_rule
„Regel für globalen externen Proxy-Network Load Balancer“
tcp_ssl_proxy_rule
Überwachte Ressourcentyp beobachten „Regel für Proxy-Network Load Balancer“
l4_proxy_rule
„Regel für globalen externen Proxy-Network Load Balancer“
tcp_ssl_proxy_rule

Logging für Proxy-Network Load Balancer

Logs bieten hilfreiche Informationen zur Fehlerbehebung und zum Monitoring von Load-Balancern. Logs werden für jede Verbindung zusammengefasst und bieten Ihnen Einblicke in die Weiterleitung jeder Verbindung an die bereitstellenden Back-Ends.

Für die Verwendung von Logs fallen keine zusätzlichen Gebühren an. Je nachdem, wie Sie Logs importieren, gelten jedoch die Standardpreise für Cloud Logging, BigQuery oder Pub/Sub. Das Aktivieren von Logs wirkt sich auch nicht auf die Leistung des Load-Balancers aus.

Stichprobenentnahme und Erfassung von Logs

Die Verbindungen, die von den Instanzen der virtuellen Maschinen (VM) im Backend des Load-Balancers ausgehen bzw. in diese eingehen, werden in Stichproben erfasst. Diese Stichprobenverbindungen werden dann verarbeitet, um Logs zu generieren. Sie steuern den Anteil der Verbindungen, 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 Verbindungen generiert und in Cloud Logging geschrieben.

Logging für einen neuen Backend-Dienst aktivieren

gcloud

Führen Sie den Befehl gcloud compute backend-services create aus.

Für regionale externe Proxy-Network Load Balancer und regionale interne Proxy-Network Load Balancer:

    gcloud compute backend-services create BACKEND_SERVICE \
        --region=REGION \
        --enable-logging \
        --logging-sample-rate=SAMPLE_RATE
    

Für globale externe Proxy-Network Load Balancer, klassische Proxy-Network Load Balancer oder regionenübergreifende interne Proxy-Network Load Balancer:

    gcloud compute backend-services create BACKEND_SERVICE \
        --global \
        --enable-logging \
        --logging-sample-rate=SAMPLE_RATE
    

Ersetzen Sie Folgendes:

  • BACKEND_SERVICE: der Name des Backend-Dienstes.
  • REGION ist die Region des zu erstellenden Backend-Dienstes.
  • SAMPLE_RATE: Dieses Feld kann nur angegeben werden, wenn Logging für diesen Backend-Dienst aktiviert ist.

    Der Wert des Felds muss von 0.0 to 1.0 stammen, wobei 0.0 bedeutet, dass keine Logs gemeldet werden, und 1.0, dass alle Verbindungen geloggt werden. Wenn Sie das Logging aktivieren und die Abtastrate auf 0.0 festlegen, entspricht dies einer Deaktivierung des Loggings. Der Standardwert ist 1.0.

API

Stellen Sie eine POST-Anfrage an die Methode regionBackendServices.insert:

Für regionale interne Proxy-Network-Load-Balancer:

    {
    "name": "BACKEND_SERVICE",
    "loadBalancingScheme": "INTERNAL_MANAGED",
    "logConfig": {
       "enable": true,
       "sampleRate": SAMPLE_RATE
      }
    }
    

Für regionale externe Proxy-Network Load Balancer:

    {
    "name": "BACKEND_SERVICE",
    "loadBalancingScheme": "EXTERNAL_MANAGED",
    "logConfig": {
       "enable": true,
       "sampleRate": SAMPLE_RATE
      }
    }
    

Für globale externe Proxy-Network Load Balancer:

Stellen Sie eine POST-Anfrage an die Methode backendServices.insert:

    {
    "name": "BACKEND_SERVICE",
    "loadBalancingScheme": "EXTERNAL_MANAGED",
    "logConfig": {
       "enable": true,
       "sampleRate": SAMPLE_RATE
      }
    }
    

Für klassische Proxy-Network Load Balancer:

Stellen Sie eine POST-Anfrage an die Methode backendServices.insert:

    {
    "name": "BACKEND_SERVICE",
    "loadBalancingScheme": "EXTERNAL",
    "logConfig": {
       "enable": true,
       "sampleRate": SAMPLE_RATE
      }
    }
    

Für regionenübergreifende interne Proxy-Network Load Balancer:

Stellen Sie eine POST-Anfrage an die Methode backendServices.insert:

    {
    "name": "BACKEND_SERVICE",
    "loadBalancingScheme": "INTERNAL_MANAGED",
    "logConfig": {
       "enable": true,
       "sampleRate": SAMPLE_RATE
      }
    }
    

Ersetzen Sie Folgendes:

  • BACKEND_SERVICE: der Name des Backend-Dienstes.
  • SAMPLE_RATE: Dieses Feld kann nur angegeben werden, wenn Logging für diesen Backend-Dienst aktiviert ist.

    Der Wert des Felds muss von 0.0 to 1.0 stammen, wobei 0.0 bedeutet, dass keine Logs gemeldet werden, und 1.0, dass alle Verbindungen geloggt werden. Wenn Sie das Logging aktivieren und die Abtastrate auf 0.0 festlegen, entspricht dies einer Deaktivierung des Loggings. Der Standardwert ist 1.0.

Logging für vorhandenen Backend-Dienst aktivieren

gcloud

Führen Sie den Befehl gcloud compute backend-services update aus.

Für regionale externe Proxy-Network Load Balancer und regionale interne Proxy-Network Load Balancer:

    gcloud compute backend-services update BACKEND_SERVICE \
        --region=REGION \
        --enable-logging \
        --logging-sample-rate=SAMPLE_RATE
    

Für globale externe Proxy-Network Load Balancer, klassische Proxy-Network Load Balancer oder regionenübergreifende interne Proxy-Network Load Balancer:

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

Ersetzen Sie Folgendes:

  • BACKEND_SERVICE: der Name des Backend-Dienstes.
  • REGION ist die Region des zu erstellenden Backend-Dienstes.
  • SAMPLE_RATE: Dieses Feld kann nur angegeben werden, wenn Logging für diesen Backend-Dienst aktiviert ist.

    Der Wert des Felds muss von 0.0 to 1.0 stammen, wobei 0.0 bedeutet, dass keine Logs gemeldet werden, und 1.0, dass alle Verbindungen geloggt werden. Wenn Sie das Logging aktivieren und die Abtastrate auf 0.0 festlegen, entspricht dies einer Deaktivierung des Loggings. Der Standardwert ist 1.0.

API

Stellen Sie eine PATCH-Anfrage an die Methode regionBackendServices/patch:

      PATCH https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE
     

Für regionale interne Proxy-Network-Load-Balancer:

    {
    "name": "BACKEND_SERVICE",
    "loadBalancingScheme": "INTERNAL_MANAGED",
    "logConfig": {
       "enable": true,
       "sampleRate": SAMPLE_RATE
      }
    }
    

Für regionale externe Proxy-Network Load Balancer:

    {
    "name": "BACKEND_SERVICE",
    "loadBalancingScheme": "EXTERNAL_MANAGED",
    "logConfig": {
       "enable": true,
       "sampleRate": SAMPLE_RATE
      }
    }
    

Für globale externe Proxy-Network Load Balancer:

Stellen Sie eine PATCH-Anfrage an die Methode backendServices/patch:

      PATCH https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE
    {
    "name": "BACKEND_SERVICE",
    "loadBalancingScheme": "EXTERNAL_MANAGED",
    "logConfig": {
       "enable": true,
       "sampleRate": SAMPLE_RATE
      }
    }
    

Für klassische Proxy-Network Load Balancer:

Stellen Sie eine PATCH-Anfrage an die Methode backendServices/patch:

      PATCH https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE
    {
    "name": "BACKEND_SERVICE",
    "loadBalancingScheme": "EXTERNAL",
    "logConfig": {
       "enable": true,
       "sampleRate": SAMPLE_RATE
      }
    }
    

Für regionenübergreifende interne Proxy-Network Load Balancer:

Stellen Sie eine PATCH-Anfrage an die Methode backendServices/patch:

      PATCH https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE
    {
    "name": "BACKEND_SERVICE",
    "loadBalancingScheme": "INTERNAL_MANAGED",
    "logConfig": {
       "enable": true,
       "sampleRate": SAMPLE_RATE
      }
    }
    

Ersetzen Sie Folgendes:

  • PROJECT_ID: Name Ihres Projekts
  • BACKEND_SERVICE: der Name des Backend-Dienstes.
  • SAMPLE_RATE: Dieses Feld kann nur angegeben werden, wenn Logging für diesen Backend-Dienst aktiviert ist.

    Der Wert des Felds muss von 0.0 to 1.0 stammen, wobei 0.0 bedeutet, dass keine Logs gemeldet werden, und 1.0, dass alle Verbindungen geloggt werden. Wenn Sie das Logging aktivieren und die Abtastrate auf 0.0 festlegen, entspricht dies einer Deaktivierung des Loggings. Der Standardwert ist 1.0.

Logging für vorhandenen Backend-Dienst deaktivieren

gcloud

Führen Sie den Befehl gcloud compute backend-services update aus.

Für regionale externe Proxy-Network Load Balancer und regionale interne Proxy-Network Load Balancer:

gcloud compute backend-services update BACKEND_SERVICE \
   --region=REGION \
   --no-enable-logging

Für globale externe Proxy-Network Load Balancer, klassische Proxy-Network Load Balancer oder regionenübergreifende interne Proxy-Network Load Balancer:

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

Ersetzen Sie Folgendes:

  • BACKEND_SERVICE: Der Name des Backend-Dienstes.
  • REGION ist die Region des Backend-Dienstes.

API

Für regionale externe Proxy-Network Load Balancer und regionale interne Proxy-Network Load Balancer:

Stellen Sie eine PATCH-Anfrage an die Methode regionBackendServices/patch:

 PATCH https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE
  {
  "logConfig": {
    "enable": false
   }
  }
 

Für globale externe Proxy-Network Load Balancer, klassische Proxy-Network Load Balancer oder regionenübergreifende interne Proxy-Network Load Balancer:

Stellen Sie eine PATCH-Anfrage an die Methode backendServices/patch:

 PATCH https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE
  {
  "logConfig": {
    "enable": false
   }
  }
 

Ersetzen Sie Folgendes:

  • PROJECT_ID: Name Ihres Projekts
  • REGION ist die Region des Backend-Dienstes.
  • BACKEND_SERVICE: Der Name des Backend-Dienstes.

Logs ansehen

Wenn Logs in Cloud Logging aufgenommen und nicht über eine Logs Router-Senke ausgeschlossen werden, können Sie Logs mit der Cloud Logging API und der Google Cloud CLI lesen.

Führen Sie die folgenden Schritte aus, um alle Logs anzuzeigen.

Console

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

    Zum Log-Explorer

  2. Wählen Sie den Ressourcentyp Regel für Proxy-Network Load Balancer aus.

  3. Wählen Sie den Lognamen loadbalancing.googleapis.com/connections aus.

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.

    resource.type="LOG_RESOURCE_TYPE"
    logName="projects/PROJECT_ID/logs/loadbalancing.googleapis.com/connections"
    
  4. Klicken Sie auf Abfrage ausführen.

Ersetzen Sie Folgendes:

  • LOG_RESOURCE_TYPE ist der Typ der überwachten Logging-Ressource, der auf l4_proxy_rule oder tcp_ssl_proxy_rule festgelegt ist.
  • PROJECT_ID: Name Ihres Projekts

Logs für einen bestimmten Backend-Dienst aufrufen

Führen Sie die folgenden Schritte aus, um die Logs für einen bestimmten Backend-Dienst 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.

    resource.type="LOG_RESOURCE_TYPE"
    logName="projects/PROJECT_ID/logs/loadbalancing.googleapis.com/connections"
    resource.labels.backend_service_name="BACKEND_SERVICE_NAME"
    
  4. Klicken Sie auf Abfrage ausführen.

Ersetzen Sie Folgendes:

  • LOG_RESOURCE_TYPE ist der Typ der überwachten Logging-Ressource, der auf l4_proxy_rule oder tcp_ssl_proxy_rule festgelegt ist.
  • PROJECT_ID: Name Ihres Projekts
  • BACKEND_SERVICE_NAME: Der Name des Backend-Dienstes.

Logs für eine Backend-Instanzgruppe aufrufen

Führen Sie die folgenden Schritte aus, um die Logs für eine bestimmte Backend-Instanzgruppe anzuzeigen.

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.

    resource.type="LOG_RESOURCE_TYPE"
    logName="projects/PROJECT_ID/logs/loadbalancing.googleapis.com/connections"
    resource.labels.backend_group_name="BACKEND_GROUP_NAME"
    
  4. Klicken Sie auf Abfrage ausführen.

Ersetzen Sie Folgendes:

  • LOG_RESOURCE_TYPE ist der Typ der überwachten Logging-Ressource, der auf l4_proxy_rule oder tcp_ssl_proxy_rule festgelegt ist.
  • PROJECT_ID: Name Ihres Projekts
  • BACKEND_GROUP_NAME: Name der Instanzgruppe.

Was wird protokolliert?

Logeinträge enthalten hilfreiche Informationen für Monitoring und Fehlerbehebung Ihres Traffics. Logeinträge enthalten Pflichtfelder. Dies sind die Standardfelder jedes Logdatensatzes.

Feld Feldformat Feldtyp: Erforderlich oder optional Beschreibung
Schweregrad
Zeitstempel
Empfangsstempel
insertID
logName
LogEntry Erforderlich Die allgemeinen Felder, wie in einem Logeintrag beschrieben.
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
  • Logeinträge für Google Cloud Armor-Sicherheitsrichtlinien
  • Das Feld proxyStatus enthält einen String, der angibt, warum der globale externe Proxy-Network Load Balancer, der regionale externe Proxy-Network Load Balancer und der interne Proxy-Network Load Balancer den Fehlercode zurückgegeben haben. Dieses Feld wird für klassische Proxy-Network Load Balancer nicht unterstützt.

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

    Das Feld proxyStatus besteht aus zwei Teilen:

Logfelder

Logeinträge enthalten Pflichtfelder. Dies sind die Standardfelder jedes Logdatensatzes.

Einige Logfelder enthalten mehr als ein Datenelement in einem bestimmten Feld. Diese Logfelder haben ein Mehrfeldformat. Das Feld connection hat beispielsweise das Format IpConnection. Dieses Format enthält die Quell- und Ziel-IP-Adresse sowie Protokoll und Port in einem einzigen Feld. Diese Felder mit Mehrfeldformat werden in der Datensatzformattabelle beschrieben.

In der folgenden Tabelle sind alle erforderlichen Logfelder für die Ressource l4_proxy_rule aufgeführt.

Feld Feldformat Beschreibung
connection IpConnection 5-Tupel, das diese Verbindung beschreibt
startTime String Zeitstempel (RFC 3339-Datumsstring-Format), wenn die Verbindung vom Client vom Load Balancer akzeptiert wurde.
endTime String Zeitstempel (RFC 3339-Datumsstring-Format), zu dem der Client oder das Backend die Verbindung beendet hat.
bytesSent int64 Anzahl der Bytes, die vom Server an den Client gesendet werden.
bytesReceived int64 Anzahl der Bytes, die der Server vom Client erhalten hat.

Feldformat von IpConnection

Feld Typ Beschreibung
clientIp String IP-Adresse des Clients
clientPort int32 Port des Clients. Nur für TCP- und UDP-Verbindungen festgelegt.
serverIp String Server-IP-Adresse (IP der Weiterleitungsregel)
serverPort int32 Serverport. Nur für TCP- und UDP-Verbindungen festgelegt.
protocol int32 IANA-Protokollnummer

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:

  • Globaler externer Proxy-Network Load Balancer
  • Regionaler externer Proxy-Network Load Balancer
  • Regionsübergreifender interner Proxy-Network Load Balancer
  • Regionaler interner Proxy-Network Load Balancer
proxyStatus-Fehler Beschreibung Häufige zugehörige Antwortcodes
destination_unavailable Der Load-Balancer betrachtet das Backend als nicht verfügbar. Beispielsweise sind die letzten Kommunikationsversuche mit dem Backend 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 Back-End wurde beendet, bevor eine vollständige Antwort empfangen wurde.

Dieser proxyStatus error wird in folgenden Fällen zurückgegeben:

  • Die Verbindung des Load-Balancers mit dem Back-End wurde beendet, bevor eine vollständige Antwort empfangen wurde.
  • Die TLS-Verbindung ist beim SSL-Handshake fehlgeschlagen und der Client hat keine Verbindung zum 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.

Dieser proxyStatus error wird in folgenden Fällen 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 wie Speichermangel.
502, 503
destination_not_found Der Load-Balancer kann nicht das richtige Backend für diese Anfrage ermitteln. 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. Jeder Antwortcode, der vom Problemtyp abhängt. Der Antwortcode 410 bedeutet beispielsweise, dass das Backend aufgrund von Zahlungsrückstand nicht verfügbar ist.
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 bereitgestellten Zertifikats einen Fehler festgestellt. 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 gilt für die folgenden Load-Balancer:

  • Globaler externer Proxy-Network Load Balancer
  • Regionaler externer Proxy-Network Load Balancer
  • Regionaler interner Proxy-Network Load Balancer
  • Regionsübergreifender interner Proxy-Network 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 passieren, wenn der Load-Balancer Traffic an eine andere Entität sendet, z. B. eine Drittanbieteranwendung, deren TCP-Zeitlimit kürzer als die 10-minütige Zeitüberschreitung 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
handled_by_identity_aware_proxy Diese Antwort wurde von Identity-Aware Proxy (IAP) generiert, während die Identität des Clients überprüft wurde, bevor der Zugriff zugelassen wurde. 200, 302, 400, 401, 403, 500, 502
request_overall_timeout Das gesamte Zeitlimit für Anfragen wurde überschritten. 408, 503, 504
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 Einrichtung eines PSK-Schlüssels erforderlich ist, der Client jedoch keine akzeptable PSK-Identität bereitstellt. 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 Protokollverhandlung auf Anwendungsebene für TLS. 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 Der Typ eines Zertifikats wird nicht unterstützt. 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, sodass es inakzeptabel ist. 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 Aufgrund der verfügbaren Optionen kann kein akzeptabler Satz von Sicherheitsparametern ausgehandelt werden. 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 Ein gültiges Zertifikat oder eine gültige PSK wurde 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 Länge der 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 fehlgeschlagen, weil der Server Parameter benötigt, die sicherer sind, als vom Client unterstützt werden. Der Fehler führt zu einer geschlossenen TLS-Verbindung. 0
inappropriate_fallback Von einem Server als Antwort auf einen ungültigen Verbindungswiederholungsversuch von einem Client gesendet. Der Fehler führt zu einer geschlossenen TLS-Verbindung. 0
user_cancelled Der Nutzer bricht den Handshake aus einem 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 erhalten, die keine Erweiterung enthält, die für die angebotene TLS-Version oder andere ausgehandelte Parameter gesendet werden muss. 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 TLS-Erweiterungsdefinitionen. 0
bad_certificate_status_response Wird von Clients gesendet, wenn der Server über die Erweiterung „status_request“ eine ungültige oder inakzeptable OCSP-Antwort bereitstellt. Siehe TLS-Erweiterungsdefinitionen. 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

Fehlgeschlagene TLS-Verbindungslogeinträge

Wenn die TLS-Verbindung zwischen dem Client und dem Load-Balancer fehlschlägt, bevor ein Backend ausgewählt wird, werden die Fehler in den Logeinträgen aufgezeichnet. Sie können die Backend-Dienste mit unterschiedlichen Log-Abtastraten konfigurieren. Wenn eine TLS-Verbindung fehlschlägt, ist die Abtastrate für fehlgeschlagene TLS-Verbindungen die höchste Abtastrate für jeden Backend-Dienst. Wenn Sie beispielsweise zwei Back-End-Dienste mit einer Logging-Abtastrate als 0.3 und 0.5 konfiguriert haben, beträgt die Abtastrate für fehlgeschlagene TLS-Verbindungslogs 0.5.

Sie können fehlgeschlagene TLS-Verbindungen anhand der folgenden Logeintragsdetails identifizieren:

  • Typ des proxyStatus-Fehlers ist tls_alert_received, tls_certificate_error, tls_protocol_error oder connection_terminated.
  • Es gibt keine Back-End-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 den Ressourcentyp l4_proxy_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.
target_proxy_name String Der Name des Ziel-Proxy-Objekts, auf das die Weiterleitungsregel verweist.
forwarding_rule_name String Der Name des Weiterleitungsregelobjekts.
loadbalancing_scheme_name String Ein Attribut für die Weiterleitungsregel und den Backend-Dienst eines Load-Balancers, das angibt, ob der Load Balancer für internen oder externen Traffic verwendet werden kann.
backend_target_name String Der Name des Backends, das für die Anfrage ausgewählt wurde.
backend_target_type String Der Typ des Backend-Ziels (BACKEND_SERVICE / UNKNOWN).
backend_name String Der Name der Backend-Instanzgruppe oder Netzwerk-Endpunktgruppe (NEG).
backend_type String

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

Cloud Logging protokolliert Anfragen, wenn der 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.

Monitoring

Die Proxy-Network-Load-Balancer exportieren Monitoringdaten nach Cloud Monitoring.

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

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

Zusätzlich zu den vordefinierten Dashboards in Monitoring können Sie mit der Cloud Monitoring API benutzerdefinierte Dashboards erstellen, Warnungen einrichten und Messwerte abfragen.

Monitoring-Dashboards aufrufen

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

    Zu Monitoring

  2. Wenn im Navigationsbereich Ressourcen angezeigt wird, wählen Sie Ressourcen und dann Google Cloud Load Balancing aus. Wählen Sie andernfalls Dashboards und dann das Dashboard mit dem Namen Google Cloud Load Balancing aus.

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

Im linken Bereich werden verschiedene Informationen zu diesem Load-Balancer angezeigt. Im rechten Bereich sehen Sie die Zeitachsengrafiken. Klicken Sie auf Aufschlüsselungen, um spezifische Aufschlüsselungen einzusehen.

Häufigkeit und Speicherung von Messwertberichten

Die Messwerte für die Load-Balancer werden im Abstand von einer Minute in Batches nach Monitoring exportiert. Monitoring-Daten werden sechs (6) Wochen beibehalten. Messwerte basieren auf Stichproben des Traffics. Die Stichprobenrate ist dynamisch und kann nicht angepasst werden.

Im Dashboard werden Datenanalysen in Standardintervallen von einer Stunde, sechs Stunden, einem Tag, einer Woche und sechs Wochen bereitgestellt. Sie können Analysen in jedem beliebigen Intervall von sechs Wochen bis zu einer Minute manuell anfordern.

Messwerte für klassische Proxy-Network Load Balancer

Die folgenden Messwerte für klassische Proxy-Network Load Balancer werden in Monitoring erfasst.

Messwert Name Beschreibung
Eingehender Traffic tcp_ssl_proxy/ingress_bytes_count Die Anzahl der Byte, die von externen Endpunkten über das Google Front End (GFE) an konfigurierte Back-Ends gesendet wurden, in Byte pro Sekunde.
Ausgehender Traffic tcp_ssl_proxy/egress_bytes_count Die Anzahl der Byte, die von konfigurierten Back-Ends über das GFE an externe Endpunkte gesendet wurden (in Byte pro Sekunde).
Offene Verbindungen tcp_ssl_proxy/open_connections Die Anzahl der Verbindungen, die zu einem bestimmten Stichprobenzeitpunkt offen sind. Stichproben werden in Abständen von einer Minute entnommen.
Neue Verbindungen pro Sekunde tcp_ssl_proxy/new_connections Die Anzahl der Verbindungen, die erstellt wurden, d. h. die Fälle, in denen der Client erfolgreich eine Verbindung mit dem Backend hergestellt hat. Die Zählung erfolgt in Minutenabständen. Allerdings werden in den Grafiken die Werte pro Sekunde angezeigt. Weitere Informationen finden Sie in der Dokumentation zu Monitoring.
Geschlossene Verbindungen pro Sekunde tcp_ssl_proxy/closed_connections Die Anzahl der Verbindungen, die geschlossen wurden. Die Zählung erfolgt in Minutenabständen, allerdings werden in den Grafiken die Werte pro Sekunde angezeigt. Weitere Informationen finden Sie in der Dokumentation zu Monitoring.
Frontend-RTT tcp_ssl_proxy/frontend_tcp_rtt Eine Verteilung der geglätteten Umlaufzeit („Round-Trip-Time“, RTT), die für jede Verbindung zwischen dem Client und dem GFE gemessen wird (gemessen vom TCP-Stack des GFE, jedes Mal, wenn Byte der Anwendungsschicht vom GFE zum Client übertragen werden). Die geglättete RTT ist ein Algorithmus, der Varianten und Anomalien behandelt, die bei RTT-Messungen auftreten können.

Messwerte für andere Load Balancer

Die folgenden Messwerte für regionale interne Proxy-Network Load Balancer, regionale externe Proxy-Network Load Balancer, regionenübergreifende interne Proxy-Network Load Balancer und globale externe Proxy-Network Load Balancer werden in Monitoring gemeldet.

Messwert Name Beschreibung
Eingehender Traffic l4_proxy/ingress_bytes_count Die Anzahl der Byte, die vom Client über den Proxy an die Backend-VM gesendet werden. Alle 60 Sekunden wird eine Stichprobe erstellt. Nach der Stichprobe werden bis zu 210 Sekunden lang keine Daten angezeigt.
Ausgehender Traffic l4_proxy/egress_bytes_count Die Anzahl der Byte, die von der Backend-VM über den Proxy an den Client gesendet werden. Alle 60 Sekunden wird eine Stichprobe erstellt. Nach der Stichprobe werden bis zu 210 Sekunden lang keine Daten angezeigt.
Geschlossene Verbindungen pro Sekunde l4_proxy/tcp/closed_connections_count Die Anzahl der Verbindungen, die mit einer TCP RST- oder TCP FIN-Nachricht beendet wurden. Alle 60 Sekunden wird eine Stichprobe erstellt. Nach der Stichprobe werden bis zu 210 Sekunden lang keine Daten angezeigt.

Dimensionen für Messwerte filtern

Die Messwerte werden für jeden Load-Balancer zusammengefasst. Messwerte können nach folgenden Dimensionen weiter aufgeschlüsselt werden:

Attribut Beschreibung
BACKEND SCOPE Der Bereich (Region oder Zone) der Instanzgruppe, die die Verbindung bereitgestellt hat.
BACKEND ZONE Wenn die Instanzgruppe eine zonale Instanzgruppe war, ist dies die Zone der Instanzgruppe, die die Verbindung bereitgestellt hat.
BACKEND REGION Wenn die Instanzgruppe eine regionale Instanzgruppe war, ist dies die Region der Instanzgruppe, die die Verbindung bereitgestellt hat.
PROXY CONTINENT Der Kontinent des GFEs, der die TCP/SSL-Verbindung des Nutzers beendet hat, z. B. America, Europe, Asia.
INSTANCE GROUP Der Name der Instanzgruppe, die die Nutzerverbindung entgegengenommen hat.
FORWARDING RULE Der Name der Weiterleitungsregel, die für die Verbindung mit dem GFE verwendet wird.
CLIENT COUNTRY Der Name des Landes des Nutzers.

Nächste Schritte