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 Protokolle 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 dabei 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 dabei 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 dabei 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 -Anfrage an die Methode regionBackendServices/:

       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 -Anfrage an die Methode backendServices/:

       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 -Anfrage an die Methode backendServices/:

       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 -Anfrage an die Methode backendServices/:

       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 dabei 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 dabei 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 -Anfrage an die Methode regionBackendServices/:

  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 -Anfrage an die Methode backendServices/:

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

Ersetzen Sie dabei 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 Protokolle aufzurufen.

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 dabei Folgendes:

  • LOG_RESOURCE_TYPE: Der Typ der überwachten Ressource für das Logging ist entweder l4_proxy_rule oder tcp_ssl_proxy_rule.
  • PROJECT_ID: Name Ihres Projekts

Logs für einen bestimmten Backend-Dienst aufrufen

So rufen Sie die Logs für einen bestimmten Backend-Dienst auf:

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 dabei Folgendes:

  • LOG_RESOURCE_TYPE: Der Typ der überwachten Ressource für das Logging ist entweder l4_proxy_rule oder tcp_ssl_proxy_rule.
  • PROJECT_ID: Name Ihres Projekts
  • BACKEND_SERVICE_NAME: Der Name des Backend-Dienstes.

Logs für eine Backend-Instanzgruppe aufrufen

So rufen Sie die Logs für eine bestimmte Backend-Instanzgruppe auf:

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 dabei Folgendes:

  • LOG_RESOURCE_TYPE: Der Typ der überwachten Ressource für das Logging ist entweder l4_proxy_rule oder tcp_ssl_proxy_rule.
  • 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.

FeldFeldformatFeldtyp: Erforderlich oder optionalBeschreibung
Schweregrad
Zeitstempel
Empfangsstempel
insertID
logName		LogEntryErforderlichDie allgemeinen Felder, wie in einem Logeintrag beschrieben.
resourceMonitoredResourceErforderlich

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.

jsonPayloadobject (Struct format)ErforderlichNutzlast 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. Das kann passieren, wenn der Proxy einen Fehlercode zurückgibt, der nicht 0, 4XX oder 5XX ist.

    Das proxyStatus-Feld besteht aus zwei Teilen:

  • backendNetworkName: gibt das VPC-Netzwerk des Backends an.

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 Protokollfelder für die Ressource l4_proxy_rule aufgeführt.

FeldFeldformatBeschreibung
connectionIpConnection5-Tupel, das diese Verbindung beschreibt
startTimeStringZeitstempel (RFC 3339-Datumsstring-Format), wenn die Verbindung vom Client vom Load Balancer akzeptiert wurde.
endTimeStringZeitstempel (RFC 3339-Datumsstring-Format), zu dem der Client oder das Backend die Verbindung beendet hat.
bytesSentint64Anzahl der Bytes, die vom Server an den Client gesendet werden.
bytesReceivedint64Anzahl der Bytes, die der Server vom Client erhalten hat.

Feldformat von IpConnection

FeldTypBeschreibung
clientIpStringIP-Adresse des Clients
clientPortint32Port des Clients. Nur für TCP- und UDP-Verbindungen festgelegt.
serverIpStringServer-IP-Adresse (IP der Weiterleitungsregel)
serverPortint32Serverport. Nur für TCP- und UDP-Verbindungen festgelegt.
protocolint32IANA-Protokollnummer

Feld „proxyStatus“

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-FehlerBeschreibungHäufige zugehörige Antwortcodes
destination_unavailableDer Load Balancer betrachtet das Backend als nicht verfügbar. Beispiel: Die letzten Kommunikationsversuche mit dem Backend sind fehlgeschlagen oder eine Systemdiagnose hat zu einem Fehler geführt.500, 503
connection_timeoutBeim 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 konnte keine Verbindung zum Load Balancer herstellen.

0, 502, 503
connection_refusedDie 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 Back-End im Wartungsmodus befindet, kann der Traffic nicht an das Back-End weitergeleitet werden.
  • Wenn die Anfrage eine lokale Ratenbegrenzung hat.
  • Envoy verarbeitet Fehlerbedingungen wie einen fehlenden Arbeitsspeicher.
502, 503
destination_not_foundDer Load Balancer kann nicht feststellen, welches Backend für diese Anfrage zu verwenden ist. Möglicherweise ist das Backend nicht konfiguriert.500, 404
dns_errorDer Load Balancer hat bei der Suche nach einer IP-Adresse für den Backend-Hostnamen einen DNS-Fehler festgestellt.502, 503
proxy_configuration_errorDer Load Balancer ist auf einen internen Konfigurationsfehler gestoßen.500
proxy_internal_errorDer Load Balancer hat einen internen Fehler festgestellt. Der Fehler kann auf einen geplanten Neustart des Proxys zurückzuführen sein, der die Verbindungen verwaltet.0, 500, 502
proxy_internal_responseDer Load Balancer hat die Antwort generiert, ohne zu versuchen, eine Verbindung zum Backend herzustellen.Je nach Art des Problems ist jeder Statuscode möglich. Der Statuscode 410 bedeutet beispielsweise, dass das Backend aufgrund von Zahlungsrückstand nicht verfügbar ist.
tls_protocol_errorDer Load Balancer hat während des TLS-Handshakes einen TLS-Fehler festgestellt.0
tls_certificate_errorDer Load Balancer hat bei der Überprüfung des vom Server bereitgestellten Zertifikats einen Fehler festgestellt.0
tls_alert_receivedDer Load Balancer hat während des TLS-Handshakes eine fatale TLS-Warnung 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-DetailsBeschreibungHäufige zugehörige Antwortstatuscodes
client_disconnected_before_any_responseDie Verbindung mit dem Client wurde unterbrochen, bevor der Load-Balancer eine Antwort gesendet hat.0
backend_connection_closedDas 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. an eine Drittanbieteranwendung, deren TCP-Zeitlimit kürzer ist als das 10-minütige Zeitlimit (600 Sekunden) des Load Balancers.502
failed_to_connect_to_backendDer 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_backendDer Load-Balancer konnte kein fehlerfreies Back-End für die Verarbeitung der Anfrage finden.502
handled_by_identity_aware_proxyDiese Antwort wurde von Identity-Aware Proxy (IAP) während der Identitätsüberprüfung des Clients generiert, bevor der Zugriff zugelassen wurde.200, 302, 400, 401, 403, 500, 502
request_overall_timeoutDas Zeitlimit für die Gesamtanfrage wurde überschritten. Weitere Informationen finden Sie unter Protokollierte Fehler für geschlossene Verbindungen.408, 503, 504
tls_version_not_supportedDie TLS-Protokollversion wird erkannt, aber nicht unterstützt. Der Fehler führt zu einer geschlossenen TLS-Verbindung.0
unknown_psk_identityServer 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_protocolWird 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 TLS Application-Layer Protocol Negotiation Extension. Der Fehler führt zu einer geschlossenen TLS-Verbindung.0
no_certificateEs wurde kein Zertifikat gefunden. Der Fehler führt zu einer geschlossenen TLS-Verbindung.0
bad_certificateEin 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_certificateEin Zertifikat hat einen nicht unterstützten Typ. Der Fehler führt zu einer geschlossenen TLS-Verbindung.0
certificate_revokedEin Zertifikat wurde von seinem Unterzeichner widerrufen. Der Fehler führt zu einer geschlossenen TLS-Verbindung.0
certificate_expiredEin Zertifikat ist abgelaufen oder ungültig. Der Fehler führt zu einer geschlossenen TLS-Verbindung.0
certificate_unknownBei der Verarbeitung des Zertifikats sind einige nicht näher bezeichnete Probleme aufgetreten, weshalb es nicht akzeptiert werden kann. Der Fehler führt zu einer geschlossenen TLS-Verbindung.0
unknown_caEs wurde eine gültige Zertifikatskette oder eine Teilkette empfangen, aber das Zertifikat kann nicht akzeptiert werden, 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_messageEine 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_macEin Eintrag wurde empfangen, dessen Schutz nicht aufgehoben werden kann. Der Fehler führt zu einer geschlossenen TLS-Verbindung.0
record_overflowEs 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_failureEs konnte keine akzeptable Sicherheitsparametergruppe ausgehandelt werden, da die verfügbaren Optionen nicht ausreichen. Der Fehler führt zu einer geschlossenen TLS-Verbindung.0
illegal_parameterEin Feld im Handshake war falsch oder stimmt nicht mit anderen Feldern überein. Der Fehler führt zu einer geschlossenen TLS-Verbindung.0
access_deniedEs 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_errorEine Nachricht konnte nicht decodiert werden, da einige Felder außerhalb des angegebenen Bereichs liegen oder die Länge der Nachricht falsch ist. Der Fehler führt zu einer geschlossenen TLS-Verbindung.0
decrypt_errorEine 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_securityEine Verhandlung ist insbesondere fehlgeschlagen, weil der Server Parameter benötigt, die sicherer sind als die vom Client unterstützten. Der Fehler führt zu einer geschlossenen TLS-Verbindung.0
inappropriate_fallbackWird 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_cancelledDer Nutzer hat den Handshake aus einem Grund abgebrochen, der nicht mit einem Protokollfehler zusammenhängt. Der Fehler führt zu einer geschlossenen TLS-Verbindung.0
missing_extensionWird 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_extensionWird 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_nameWird von Servern gesendet, wenn es keinen Server gibt, der anhand des vom Client über die Erweiterung „server_name“ angegebenen Namens identifiziert werden kann. Weitere Informationen finden Sie unter Definitionen von TLS-Erweiterungen.0
bad_certificate_status_responseWird von Clients gesendet, wenn der Server über die Erweiterung „status_request“ eine ungültige oder nicht zulässige OCSP-Antwort liefert. Weitere Informationen finden Sie unter Definitionen von TLS-Erweiterungen. Der Fehler führt zu einer geschlossenen TLS-Verbindung.0
load_balancer_configured_resource_limits_reachedDer Load Balancer hat die konfigurierten Ressourcenlimits erreicht, z. B. die maximale Anzahl von Verbindungen.0

Logeinträge für fehlgeschlagene TLS-Verbindungen

Wenn die TLS-Verbindung zwischen dem Client und dem Load Balancer fehlschlägt, bevor ein Back-End ausgewählt wird, werden die Fehler in Protokolleinträ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 anhand der folgenden Protokolleintragsdetails identifizieren:

  • 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 den Ressourcentyp l4_proxy_rule aufgeführt.

FeldTypBeschreibung
network_nameStringDer Name des VPC-Netzwerks des Load-Balancers.
project_idStringDie Kennung des Google Cloud -Projekts, das dieser Ressource zugeordnet ist.
regionStringDie Region, in der der Load-Balancer definiert ist.
target_proxy_nameStringDer Name des Ziel-Proxy-Objekts, auf das die Weiterleitungsregel verweist.
forwarding_rule_nameStringDer Name des Weiterleitungsregelobjekts.
loadbalancing_scheme_nameStringEin 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_nameStringDer Name des Backends, das für die Anfrage ausgewählt wurde.
backend_target_typeStringDer Typ des Backend-Ziels (BACKEND_SERVICE / UNKNOWN).
backend_nameStringDer Name der Back-End-Instanzgruppe oder der Netzwerk-Endpunktgruppe (NEG).
backend_typeString

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_scopeStringDer Bereich des Back-Ends (entweder ein Zonenname oder ein Regionsname). Kann UNKNOWN sein, wenn backend_name unbekannt ist.
backend_scope_typeStringDer 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 Dasards in Monitoring können Sie mit der Cloud Monitoring API benutzerdefinierte Dasards erstellen, Warnungen einrichten und Messwerte abfragen.

Monitoring-Dasards 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 Dasards und dann das Dasard 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 Dasard 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.

MesswertNameBeschreibung
Eingehender Traffictcp_ssl_proxy/ingress_bytes_countDie Anzahl der Byte, die von externen Endpunkten über das Google Front End (GFE) an konfigurierte Back-Ends gesendet wurden, in Byte pro Sekunde.
Ausgehender Traffictcp_ssl_proxy/egress_bytes_countDie Anzahl der Byte, die von konfigurierten Back-Ends über das GFE an externe Endpunkte gesendet wurden (in Byte pro Sekunde).
Offene Verbindungentcp_ssl_proxy/open_connectionsDie Anzahl der Verbindungen, die zu einem bestimmten Stichprobenzeitpunkt offen sind. Stichproben werden in Abständen von einer Minute entnommen.
Neue Verbindungen pro Sekundetcp_ssl_proxy/new_connectionsDie 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 Sekundetcp_ssl_proxy/closed_connectionsDie 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-RTTtcp_ssl_proxy/frontend_tcp_rttEine 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.

MesswertNameBeschreibung
Eingehender Trafficl4_proxy/ingress_bytes_countDie 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 Trafficl4_proxy/egress_bytes_countDie 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 Sekundel4_proxy/tcp/closed_connections_countDie 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:

AttributBeschreibung
BACKEND SCOPEDer Bereich (Region oder Zone) der Instanzgruppe, die die Verbindung bereitgestellt hat.
BACKEND ZONEWenn die Instanzgruppe eine zonale Instanzgruppe war, ist dies die Zone der Instanzgruppe, die die Verbindung bereitgestellt hat.
BACKEND REGIONWenn die Instanzgruppe eine regionale Instanzgruppe war, ist dies die Region der Instanzgruppe, die die Verbindung bereitgestellt hat.
PROXY CONTINENTDer Kontinent des GFEs, der die TCP/SSL-Verbindung des Nutzers beendet hat, z. B. America, Europe, Asia.
INSTANCE GROUPDer Name der Instanzgruppe, die die Nutzerverbindung entgegengenommen hat.
FORWARDING RULEDer Name der Weiterleitungsregel, die für die Verbindung mit dem GFE verwendet wird.
CLIENT COUNTRYDer Name des Landes des Nutzers.

Nächste Schritte