Logging und Monitoring für das HTTP(S)-Load-Balancing

Dieses Dokument bietet grundlegende Informationen zu Cloud Logging und Cloud Monitoring für HTTP(S)-Load-Balancing.

Logging

Sie können Logs für den Back-End-Dienst des HTTP(S)-Load-Balancings aktivieren, deaktivieren und anzeigen.

Hinweis: Logging ist für Back-End-Dienste deaktiviert, die von einem externen HTTP(S)-Load-Balancer verwendet werden, wenn der Back-End-Dienst nach dem Release mit allgemeiner Verfügbarkeit von Cloud Logging für HTTP(S)-Load-Balancing erstellt wurde. Logging wurde für einen Back-End-Dienst aktiviert, der von einem externen HTTP(S)-Load-Balancer verwendet wird, der im Alpha- oder Betarelase von Cloud Logging für HTTP(S)-Load-Balancing erstellt wurde. Die Aktivierung bleibt solange bestehen, bis Sie sie deaktivieren.

Logging wird pro Back-End-Dienst aktiviert oder deaktiviert. Wenn Sie das Logging aktiviert haben, können Sie konfigurieren, ob alle Anfragen oder nur ein zufällig ausgewählter Teil protokolliert werden sollen.

Außerdem darf es keinen Logausschluss geben, der für den externen HTTP(S)-Load-Balancer gilt. Wie Sie prüfen können, ob Cloud HTTP load balancer-Logs zugelassen sind, erfahren Sie unter Ausgeschlossene Ressourcentypen ansehen.

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

Console

1. Öffnen Sie in der Google Cloud Console die Seite "Load-Balancing".
   Zur Seite "Load-Balancing"
2. Klicken Sie auf den Namen des Load-Balancers.
3. Klicken Sie auf Bearbeiten .
4. Klicken Sie auf Back-End-Konfiguration.
5. Klicken Sie neben Ihrem Back-End-Dienst auf Bearbeiten .
6. Entfernen Sie das Häkchen für Logging aktivieren, um das Logging komplett zu deaktivieren.
7. Wenn das Logging aktiviert bleibt, können Sie einen anderen Anteilswert als Abtastrate festlegen. Sie haben dabei die Möglichkeit, einen Wert zwischen 0.0 und 1.0 (Standard) anzugeben. Zur Reduzierung der Anzahl der gespeicherten Logs auf 20 % legen Sie den Wert auf 0.2 fest.
8. Klicken Sie auf Aktualisieren.

gcloud

gcloud compute backend-services create BACKEND_SERVICE \
 --global \
 --enable-logging \
 --logging-sample-rate=VALUE \
 ... other values

Dabei gilt:

• --global gibt an, dass es sich um einen globalen Back-End-Dienst handelt.
• --enable-logging aktiviert das Logging für diesen Back-End-Dienst.
• Mit --logging-sample-rate=<var>VALUE</var> können Sie einen Wert zwischen 0.0 und 1.0 angeben, wobei 0.0 dazu führt, dass keine Pakete protokolliert, und 1.0, dass 100 % der Pakete 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.

Logging für vorhandenen Back-End-Dienst aktivieren

Console

1. Öffnen Sie in der Google Cloud Console die Seite "Load-Balancing".
   Zur Seite "Load-Balancing"
2. Klicken Sie auf den Namen des Load-Balancers.
3. Klicken Sie auf Bearbeiten .
4. Klicken Sie auf Back-End-Konfiguration.
5. Klicken Sie neben Ihrem Back-End-Dienst auf Bearbeiten .
6. Klicken Sie auf Logging aktivieren.
7. Legen Sie einen Anteilswert für die Abtastrate fest. Sie können eine Rate von 0.0 bis 1.0 (Standardwert) festlegen.
8. Klicken Sie auf Aktualisieren.

gcloud

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

Dabei gilt:

• --global gibt an, dass es sich um einen globalen Back-End-Dienst handelt.
• --enable-logging aktiviert das Logging für diesen Back-End-Dienst.
• Mit --logging-sample-rate=<var>VALUE</var> können Sie einen Wert zwischen 0.0 und 1.0 angeben, wobei 0.0 dazu führt, dass keine Pakete protokolliert, und 1.0, dass 100 % der Pakete 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.

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

Console

1. Öffnen Sie in der Google Cloud Console die Seite "Load-Balancing".
   Zur Seite "Load-Balancing"
2. Klicken Sie auf den Namen des Load-Balancers.
3. Klicken Sie auf Bearbeiten .
4. Klicken Sie auf Back-End-Konfiguration.
5. Klicken Sie neben Ihrem Back-End-Dienst auf .
6. Entfernen Sie das Häkchen für Logging aktivieren, um das Logging komplett zu deaktivieren.
7. Wenn das Logging aktiviert bleibt, können Sie einen anderen Anteilswert als Abtastrate festlegen. Sie können eine Rate von 0.0 bis 1.0 (Standardwert) festlegen. Zur Reduzierung der Anzahl der gespeicherten Logs auf 20 % legen Sie den Wert auf 0.2 fest.
8. Klicken Sie auf Aktualisieren.

gcloud

Logging vollständig deaktivieren

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

Dabei gilt:

• --global gibt an, dass es sich um einen globalen Back-End-Dienst handelt.
• --no-enable-logging deaktiviert das Logging für diesen Back-End-Dienst.

Abtastrate für das Logging ändern

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

Dabei gilt:

• --global gibt an, dass es sich um einen globalen Back-End-Dienst handelt.
• Mit --logging-sample-rate=<var>VALUE</var> können Sie einen Wert zwischen 0.0 und 1.0 angeben, wobei 0.0 dazu führt, dass keine Pakete protokolliert, und 1.0, dass 100 % der Pakete 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.

Logs ansehen

Um Logs anzuzeigen, öffnen Sie die Log-Anzeige.

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

• Für die Anzeige aller Logs wählen Sie im ersten Drop-down-Menü Cloud-HTTP-Load-Balancer > Alle Weiterleitungsregeln aus.
• Für die Anzeige der Logs für eine Weiterleitungsregel wählen Sie aus der Liste die jeweilige Weiterleitungsregel aus.
• Zur Anzeige der Logs für eine von einer Weiterleitungsregel verwendete URL-Zuordnung markieren Sie die betreffende Weiterleitungsregel und wählen die entsprechende URL-Zuordnung aus.

Boolesche Logfelder erscheinen normalerweise nur, 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 von HTTP(S)-Load-Balancern (resource.type=http_load_balancer) konfigurieren. Die erstellten Messwerte basieren dabei auf der Ressource "Google Cloud HTTP-Load-Balancing-Regel (logbasierte Messwerte)" (l7_lb_rule). Diese finden Sie in den Cloud Monitoring-Dashboards statt der https_lb_rule-Ressource:

Zu Monitoring

Inhalt der Logs

Die Logeinträge für das HTTP(S)-Load-Balancing bieten Informationen, die Sie für das Monitoring und die Fehlerbehebung bei Ihrem HTTP(S)-Traffic verwenden können. Folgende Informationen sind in Ihnen enthalten:

• Allgemeine Informationen, die in den meisten Logs angezeigt werden, wie z. B. Wichtigkeit, Projekt-ID, Projektnummer und Zeitstempel
• HttpRequest-Logfelder. HttpRequest.protocol und HttpRequest.latency enthalten jedoch in Cloud Logging-Logs für das HTTP(S)-Load-Balancing keine Daten.
• Ein statusDetails-Feld in structPayload. Dieses Feld enthält einen String, der angibt, warum der Load-Balancer den entsprechenden HTTP-Status zurückgegeben hat. In den folgenden Tabellen finden Sie weitere Erläuterungen dieser Logstrings.
• Vom Load-Balancer ausgegebene Weiterleitungen (HTTP-Antwort-Statuscode 302 Found) werden nicht protokolliert. Weiterleitungen, die von den Back-End-Instanzen ausgegeben werden, werden protokolliert.

HTTP-Erfolgsmeldungen für statusDetail

statusDetails (erfolgreich)	Bedeutung	Häufige zugehörige Antwortcodes
byte_range_caching	Die HTTP-Anfrage wurde mit Bytebereich-Caching von Cloud CDN gestellt.	Jeder cachefähige Antwortcode ist möglich.
response_from_cache	Die HTTP-Anfrage kam vom Cloud CDN-Cache.	Jeder im Cache speicherbare Antwortcode ist möglich.
response_from_cache_validated	Der Rückgabecode wurde von einem im Cloud CDN-Cache gespeicherten Eintrag festgelegt, der von einem Back-End bestätigt wurde.	Jeder im Cache speicherbare Antwortcode ist möglich.
response_sent_by_backend	Die HTTP-Anfrage wurde erfolgreich an das Back-End weitergeleitet.	Wird vom Back-End zurückgegeben; der HTTP-Antwortcode wird durch die auf dem Back-End ausgeführte Software festgelegt.

Fehlermeldungen für statusDetail HTTP

Diese Tabelle filtern:

statusDetails (Fehler)	Bedeutung	Häufige zugehörige Antwortcodes
aborted_request_due_to_backend_early_response	Eine Anfrage mit Textkörper wurde abgebrochen, weil das Back-End eine frühe Antwort mit Fehlercode geschickt hat. Die Antwort wurde an den Client weitergeleitet. Die Anfrage wurde beendet.	4XX oder 5XX
backend_connection_closed_after_partial_response_sent	Die Back-End-Verbindung wurde unerwartet geschlossen, nachdem eine Teilantwort an den Client geschickt wurde.	Der HTTP-Antwortcode wird von der auf dem Back-End ausgeführten Software festgelegt. Der HTTP-Antwortcode 0 (null) bedeutet, dass das Back-End unvollständige HTTP-Header gesendet hat.
backend_connection_closed_before_data_sent_to_client	Das Back-End hat die Verbindung mit dem Load-Balancer unerwartet geschlossen, bevor die Antwort an den Client weitergeleitet wurde. Dies kann vorkommen, wenn vom Load-Balancer Traffic an eine andere Entität gesendet wird, deren TCP-Zeitlimit unter dem Zeitlimit des externen HTTP(S)-Load-Balancers von 10 Minuten (600 Sekunden) liegt. Das kann ein auf einer VM-Instanz ausgeführter Load-Balancer eines Drittanbieters sein. Das Problem wird möglicherweise dadurch behoben, dass für den Zieldienst ein TCP-Zeitlimit (Keepalive-Wert) von mehr als 600 Sekunden festgelegt wird.	502
backend_early_response_with_non_error_status	Das Back-End hat eine fehlerfreie Antwort (1XX oder 2XX) auf eine Anfrage gesendet, bevor der gesamte Anfragetextkörper empfangen wurde.	502
backend_interim_response_not_supported	Das Back-End hat eine vorläufige 1XX-Antwort auf die Anfrage in einem Kontext gesendet, in dem vorläufige Antworten nicht unterstützt werden.	502
backend_response_corrupted	Der HTTP-Antworttextkörper vom Back-End hatte eine ungültige, aufgeteilte Transferverschlüsselung oder war anderweitig fehlerhaft.	Abhängig von der Fehlerart ist jeder Antwortcode möglich. Oft 502.
backend_response_headers_too_long	Die vom Back-End gesendeten HTTP-Antwortheader überschritten das zulässige Limit. Weitere Informationen zu Limits finden Sie unter Header-Größe für HTTP(S)-Load-Balancing.	502
backend_timeout	Es gab eine Zeitüberschreitung beim Back-End, während eine Antwort erstellt wurde.	502
body_not_allowed	Der Client schickt eine HTTP-Anfrage mit einem Textkörper, aber die HTTP-Methode lässt dies nicht zu.	400
byte_range_caching_aborted	Der Load-Balancer hat zuvor eine Antwort erhalten, die angab, dass die Ressource im Cache speicherbar war und Bytebereiche unterstützte, Cloud CDN jedoch eine inkonsistente Antwort erhalten hat (z. B. mit einem anderen Antwortcode als dem erwarteten "206 Partial Content"), als versucht wurde, eine Cache-Füllung mit einer Bytebereichsanfrage durchzuführen. Der Load-Balancer hat daraufhin die Antwort an den Client abgebrochen.	2XX
byte_range_caching_forwarded_backend_response	Der Load-Balancer hat zuvor eine Antwort erhalten, die angab, dass die Ressource im Cache speicherbar war und Bytebereiche unterstützte, Cloud CDN jedoch eine inkonsistente Antwort erhalten hat (z. B. mit einem anderen Antwortcode als dem erwarteten "206 Partial Content"), als versucht wurde, eine Cache-Füllung mit einer Bytebereichsanfrage durchzuführen. Der Load-Balancer hat dann die inkonsistente Antwort an den Client weitergeleitet.	Wird vom Back-End zurückgegeben, Es ist ein beliebiger Antwortcode möglich.
byte_range_caching_retrieval_abandoned	Der Nutzer hat eine von Cloud CDN initiierte Bytebereichs- oder Validierungsanfrage abgebrochen.	Wird vom Back-End zurückgegeben, Es ist ein beliebiger Antwortcode möglich.
byte_range_caching_retrieval_from_backend_failed_after_partial_response	Bei einer von Cloud CDN initiierten Bytebereichs- oder Validierungsanfrage wurde ein Fehler festgestellt. Ausführliche Informationen zum Back-End-Status finden Sie im entsprechenden Cloud Logging-Logeintrag für die von Cloud CDN initiierte Anfrage.	2XX
cache_lookup_failed_after_partial_response	Der Load-Balancer hat aufgrund eines internen Fehlers keine vollständige Antwort aus dem Cloud CDN-Cache zurückgegeben.	2XX
cache_lookup_timeout_after_partial_response	Es ist eine Zeitüberschreitung für den Cloud CDN-Cache aufgetreten, da der Client den Inhalt nicht rechtzeitig abgerufen hat.	2XX
client_disconnected_after_partial_response	Die Verbindung mit dem Client wurde unterbrochen, nachdem der Load-Balancer eine Teilantwort gesendet hat.	Wird vom Back-End zurückgegeben; jeder Antwortcode ist möglich.
client_disconnected_before_any_response	Die Verbindung mit dem Client wurde unterbrochen, bevor der Load-Balancer eine Antwort gesendet hat.	0
client_timed_out	Das Google Front End (GFE) hat die Clientverbindung aufgrund fehlenden Fortschritts während der Weiterleitung der Anfrage oder Antwort unterbrochen.	0 oder 408
denied_by_security_policy	Der Load-Balancer hat diese Anfrage aufgrund einer Cloud Armor-Sicherheitsrichtlinie abgelehnt.	In der Sicherheitsrichtlinie konfiguriert
error_uncompressing_gzipped_body	Es gab beim Dekomprimieren einer mit gzip komprimierten HTTP-Antwort ein Problem.	503
failed_to_connect_to_backend	Der Load-Balancer konnte keine Verbindung mit dem Back-End herstellen. Dies gilt auch für Zeitüberschreitungen während der Verbindungsphase.	502
failed_to_pick_backend	Der Load-Balancer konnte kein fehlerfreies Back-End für die Verarbeitung der Anfrage finden.	502
failed_to_negotiate_alpn	Der Load-Balancer und das Back-End konnten kein Protokoll auf Anwendungsebene (z. B. HTTP/2) aushandeln, um über TLS miteinander zu kommunizieren.	502
headers_too_long	Die Anfrage-Header waren größer als zugelassen.	413
http_version_not_supported	HTTP-Version wird nicht unterstützt. Aktuell werden nur HTTP 0.9, 1.0, 1.1 und 2.0 unterstützt.	400
internal_error	Interner Fehler beim Load-Balancer. Normalerweise stellt dies einen vorübergehenden Fehler in der Load-Balancer-Infrastruktur dar. Wiederholen Sie Ihre Abfrage.	4XX
invalid_external_origin_endpoint	Die Konfiguration für den benutzerdefinierten Ursprung ist ungültig. Prüfen Sie die Internet-NEG-Konfiguration und achten Sie darauf, dass sie eine gültige FQDN/IP-Adresse und einen gültigen Port angibt.	4XX
invalid_http2_client_header_format	Die HTTP/2-Header des Clients sind ungültig.	400
multiple_iap_policies	Mehrere Identity-Aware Proxy (IAP)-Richtlinien können nicht kombiniert werden. Wenn Sie eine IAP-Richtlinie an einen Back-End-Dienst und eine weitere Richtlinie an ein serverloses Objekt (App Engine, Cloud Run (vollständig verwaltet) oder Cloud Functions) angehängt haben, entfernen Sie eine der Richtlinien und versuchen Sie es noch einmal.	500
malformed_chunked_body	Das Chunked Encoding des Anfragetextkörpers wurde nicht richtig durchgeführt.	411
request_loop_detected	Der Load-Balancer hat eine Anfrageschleife erkannt. Dies kann durch eine fehlerhafte Konfiguration verursacht worden sein, bei der das Back-End die Anfrage an den Load-Balancer zurückgesendet hat.	502
required_body_but_no_content_length	Die HTTP-Anfrage benötigt einen Textkörper, aber die Anfrage-Header hatten keine Inhaltslänge oder einen transferverschlüsselten, aufgeteilten Header.	400 oder 403
secure_url_rejected	Eine Anfrage mit einer https:// URL wurde über eine reine Textverbindung mit HTTP/1.1 empfangen.	400
ssl_san_verification_failed	Der Load-Balancer konnte keinen alternativen Antragstellernamen (SAN) im SSL-Zertifikat finden, das vom Back-End bereitgestellt wird und mit dem konfigurierten Hostnamen übereinstimmt.	502
ssl_certificate_chain_verification_failed	Die Überprüfung des vom Back-End bereitgestellten SSL-Zertifikats ist fehlgeschlagen.	502
unsupported_method	Der Client hat eine nicht unterstützte HTTP-Anfragemethode geschickt.	400
upgrade_header_rejected	Die Client-HTTP-Anfrage enthielt den Upgrade-Header und wurde abgelehnt.	400
uri_too_long	Die HTTP-Anfrage-URI war länger als zugelassen.	414
websocket_closed	Die WebSocket-Verbindung wurde geschlossen.	101
websocket_handshake_failed	Der WebSocket-Handshake ist fehlgeschlagen.	Abhängig vom Handshake-Fehler ist jeder Antwortcode möglich.
request_body_too_large	Der HTTP-Anfragetext hat den vom Back-End unterstützten Maximalwert überschritten. Gilt nicht für VM-Back-Ends.	413
handled_by_identity_aware_proxy	Diese Antwort wurde von Identity-Aware Proxy während der Identitätsüberprüfung des Clients generiert, bevor der Zugriff zugelassen wurde.	200, 302, 400, 401, 403, 500, 502
serverless_neg_routing_failed	Die serverlose NEG-Anfrage kann nicht weitergeleitet werden. Dies kann passieren, wenn die in der NEG angegebene Region nicht erreicht werden kann oder wenn der Ressourcenname (z. B. der Cloud Functions-Name) nicht gefunden werden kann.	404, 502

Logging für IP-Sperrliste/Zulassungsliste

Die im Folgenden aufgeführten Logeinträge in der Loganzeige beziehen sich auf das HTTP(S)-Logging für die IP-Sperrliste/Zulassungsliste und weisen die angegebene Struktur im Format jsonPayload auf. HTTP-Anfragedetails sind in der httpRequest-Meldung enthalten.

• status_details (String): eine Beschreibung des Antwortcodes
• enforced_security_policy: die Sicherheitsrichtlinienregel, die tatsächlich erzwungen wurde
  • outcome (String): ACCEPT, DENY oder UNKNOWN_OUTCOME
  • configured_action (String): identisch mit "outcome"
  • name (String): Name der Sicherheitsrichtlinie
  • priority (Zahl): Priorität der übereinstimmenden Regel
• preview_security_policy: enthält nur Daten, wenn bei einer Anfrage eine für die Vorschau konfigurierte Regel gilt (nur vorhanden, wenn eine Vorschauregel Vorrang vor der erzwungenen Regel gehabt hat)
  • outcome (String): ACCEPT, DENY oder UNKNOWN_OUTCOME
  • configured_action (String): identisch mit "outcome"
  • name (String): Name der Sicherheitsrichtlinie
  • priority (Zahl): Priorität der übereinstimmenden Regel

Sie können mithilfe der Cloud Logging API die externen HTTP(S)-Load-Balancer-Logs interaktiv nutzen. Die Logging API ermöglicht das interaktive Filtern von Logs mit bestimmten festgelegten Feldern und das Exportieren übereinstimmender Logs für Cloud Logging, Cloud Storage, BigQuery oder Pub/Sub. Weitere Informationen zur Cloud Logging API finden Sie unter Logs ansehen.

Monitoring

Hinweis: Stackdriver Monitoring ist jetzt in der Cloud Console allgemein verfügbar und als Standardoption festgelegt. Für kurze Zeit können Sie auch die klassische Stackdriver Monitoring-Konsole verwenden. Weitere Informationen finden Sie unter Stackdriver Monitoring in der Cloud Console.

Von HTTP(S)-Load-Balancing werden Monitoring-Daten in Cloud Monitoring exportiert.

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 Cloud Monitoring können Sie über die Cloud Monitoring API benutzerdefinierte Dashboards erstellen, Warnungen einrichten und Messwerte abrufen.

Cloud Monitoring-Dashboards aufrufen

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

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

   Zu Monitoring

2. Wenn der Monitoring-Navigationsbereich Dienste anzeigt, wählen Sie Dienste > Cloud-Load-Balancer aus. Um das Dashboard für einen bestimmten Load-Balancer anzuzeigen, suchen Sie in der Liste nach dem Load-Balancer und klicken Sie dann auf seinen Namen.

3. Wählen Sie andernfalls Dashboards aus:

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

   • Zur Anzeige einer Liste der Dashboards für Ihre AWS-Load-Balancer wählen Sie das Dashboard mit dem Namen Amazon Web Services aus. Wenn Sie das Dashboard eines bestimmten Load-Balancers anzeigen möchten, suchen Sie den Load-Balancer in der Liste und klicken Sie auf den Namen.

Im linken Bereich werden verschiedene Details für diesen externen HTTP(S)-Load-Balancer angezeigt. Im rechten Bereich sehen Sie die Zeitachsengrafiken. Klicken Sie auf den Link Aufschlüsselung, um bestimmte Daten aufgeschlüsselt anzuzeigen.

Benachrichtigungsrichtlinien definieren

Sie können Benachrichtigungsrichtlinien erstellen, um Messwerte zu beobachten und sich informieren zu lassen, wenn diese gegen eine Bedingung verstoßen. Die allgemeinen Schritte zum Erstellen einer Benachrichtigungsrichtlinie, die eine oder mehrere Google Cloud HTTP/S Load Balancing Rule-Ressourcen überwacht, sind folgende:

1. Wechseln Sie in der Google Cloud Console zu Monitoring:

   Zu Monitoring

2. Wählen Sie im Navigationsbereich für das Monitoring Benachrichtigungen und dann Richtlinie erstellen aus.
3. Klicken Sie auf Add Condition:
   
   1. Die Einstellungen im Bereich Ziel geben die Ressource und den Messwert an, die überwacht werden sollen. Klicken Sie auf das Textfeld, um ein Menü zu aktivieren, und wählen Sie dann die Ressource Google Cloud HTTP/S Load Balancing Rule aus. Wählen Sie als Nächstes einen Messwert aus der Messwertliste aus.
   2. Die Einstellungen im Bereich Konfiguration der Benachrichtigungsrichtlinie geben an, wann die Benachrichtigung ausgelöst wird. Die meisten Felder in diesem Bereich sind bereits mit Standardwerten gefüllt. Weitere Informationen zu den Feldern in diesem Bereich finden Sie unter Konfiguration in der Dokumentation zu Benachrichtigungsrichtlinien.
   3. Klicken Sie auf Add.
4. Klicken Sie auf Weiter, um zum Abschnitt "Benachrichtigungen" zu gelangen.
5. Optional: Klicken Sie auf Benachrichtigungskanäle, um Benachrichtigungen zu Ihrer Benachrichtigungsrichtlinie hinzuzufügen. Wählen Sie im Dialogfeld mindestens einen Benachrichtigungskanal aus dem Menü aus und klicken Sie auf OK.

   Wenn ein hinzuzufügender Benachrichtigungskanal nicht aufgeführt ist, klicken Sie auf Benachrichtigungskanäle verwalten. Die Seite Benachrichtigungskanäle wird in einem neuen Browsertab angezeigt. Auf dieser Seite können Sie die konfigurierten Benachrichtigungskanäle aktualisieren. Nachdem Sie die Aktualisierungen abgeschlossen haben, kehren Sie zum ursprünglichen Tab zurück, klicken auf Aktualisieren  und wählen dann die Benachrichtigungskanäle aus, die zur Benachrichtigungsrichtlinie hinzugefügt werden sollen.

6. Klicken Sie auf Weiter, um zum Abschnitt "Dokumentation" zu gelangen.
7. Klicken Sie auf Name und geben Sie einen Namen für die Benachrichtigungsrichtlinie ein.
8. Optional: Klicken Sie auf Dokumentation und tragen Sie alle Informationen ein, die in den Benachrichtigungen angezeigt werden sollen.
9. Klicken Sie auf Speichern.

Weitere Informationen finden Sie unter Einführung in Benachrichtigungen.

Benutzerdefinierte Cloud Monitoring-Dashboards definieren

Über HTTP(S)-Load-Balancing-Messwerte können Sie benutzerdefinierte Cloud Monitoring-Dashboards erstellen:

1. Rufen Sie Monitoring in der Google Cloud Console auf.
   Zu "Monitoring"
2. Wählen Sie Dashboards > Dashboard erstellen aus.
3. Klicken Sie auf Add Chart (Diagramm hinzufügen).
4. Geben Sie dem Diagramm einen Namen.
5. Wählen Sie Messwerte und Filter aus. Bei Messwerten lautet der Ressourcentyp Cloud HTTP Load-Balancer.
6. Klicken Sie auf Speichern.

Häufigkeit und Speicherung von Messwertberichten

Messwerte für die externen HTTP(S)-Load-Balancer werden in einminütigen Abständen zu Cloud Monitoring exportiert. Monitoring-Daten werden sechs (6) Wochen beibehalten. 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.

Monitoring-Messwerte für externe HTTP(S)-Load-Balancer

Die folgenden Messwerte für externe HTTP(S)-Load-Balancer werden in Cloud Monitoring ermittelt:

Diese Tabelle filtern:

Messwert	Name	Beschreibung
Anzahl der Anfragen	https/request_count	Die Anzahl der Anfragen, die vom externen HTTP(S)-Load-Balancer bereitgestellt wurden
Anzahl der Anfragebytes	https/request_bytes_count	Die Anzahl der Byte, die als Anfragen von Nutzern an den externen HTTP(S)-Load-Balancer gesendet wurden
Anzahl der Antwortbytes	https/response_bytes_count	Die Anzahl der Byte, die als Antworten vom externen HTTP(S)-Load-Balancer an Nutzer gesendet wurden
Gesamtlatenzen	https/total_latencies	Eine Verteilung der Latenz ab dem Zeitpunkt, an dem das erste Byte der Anfrage vom GFE empfangen wurde, bis das GFE eine Bestätigung vom anfordernden Client im letzten Antwortbyte erhält. Die Gesamtlatenzen werden nach Anfrage/Antwort gemessen. Pausen zwischen Anfragen an dieselbe Verbindung mit Connection: keep-alive wirken sich daher nicht auf die Messung aus. In Cloud Monitoring-Ansichten ist die Messung normalerweise auf das 95. Perzentil reduziert. Beispiel: Ein Load-Balancer erhält aus dem Vereinigten Königreich eine Anfrage pro Sekunde mit jeweils 100 ms Latenz und aus den USA 9 Anfragen pro Sekunde mit jeweils 50 ms Latenz. In einer bestimmten Minute gingen 60 Anfragen aus dem Vereinigten Königreich und 540 Anfragen aus den USA ein. In den Monitoring-Messwerten wird die Verteilung über alle Dimensionen beibehalten. Sie können Folgendes anfordern: Medianwert der Gesamtlatenz (300/600) – 50 ms Medianwert der Latenz Vereinigtes Königreich (30/60) – 100 ms 95. Perzentil der Gesamtlatenz (570/600) – 100 ms und so weiter...
Front-End-RTT(*)	https/frontend_tcp_rtt	Eine Verteilung der ausgeglichenen RTT-Werte, die für jede Verbindung zwischen dem Client und dem GFE gemessen wurde (wird vom TCP-Stapel des GFE gemessen).
Back-End-Latenzen(*)	https/backend_latencies	Eine Verteilung der Latenz, gemessen ab dem Zeitpunkt, an dem das erste Byte der Anfrage vom GFE an das Back-End gesendet wurde, bis das GFE das letzte Byte der Antwort vom Back-End erhalten hat.
Anteil der Antwortcodeklasse		Anteil der gesamten Antworten des externen HTTP(S)-Load-Balancers in jeder Antwortcodeklasse (2XX, 4XX, …). In Cloud Monitoring ist dieser Wert nur auf Standard-Dashboards verfügbar. Er ist nicht für benutzerdefinierte Dashboards verfügbar. Sie haben die Möglichkeit, Benachrichtigungen zu diesem Wert über die API festzulegen.
Anzahl der Back-End-Anfragen	https/backend_request_count	Die Anzahl der Anfragen, die vom externen HTTP(S)-Load-Balancer an die Back-Ends gesendet wurden.
Anzahl der Back-End-Anfragebyte	https/backend_request_bytes_count	Die Anzahl der Byte, die als Anfragen vom externen HTTP(S)-Load-Balancer an die Back-Ends gesendet wurden.
Anzahl der Back-End-Antwortbyte	https/backend_response_bytes_count	Die Anzahl der Byte, die als Antworten von den Back-Ends an den HTTP(S)-Load-Balancer gesendet wurden.

(*) Die Summe der Front-End-RTT und Back-End-Latenzen ist möglicherweise höher als die Gesamtlatenzen. Dies liegt daran, dass die RTT über den Socket vom GFE zum Client bei der Bestätigung der HTTP-Antwort abgefragt wird, für einige Messwerte jedoch Kernel-Berichte herangezogen werden. Es ist nicht sicher, dass der Kernel über einen RTT-Messwert für die jeweilige HTTP-Antwort verfügt. Das Endergebnis ist ein geglätteter RTT-Wert, der auch von vorherigen HTTP-Antworten, SYN/ACKs (Abgleichen bestätigt) und SSL-Handshakes, die sich nicht auf die tatsächlichen Zeiten von aktuellen HTTP-Anfragen auswirken, beeinflusst wird.

Dimensionen für externe HTTP(S)-Load-Balancer-Messwerte filtern

Die Messwerte werden für jeden externen HTTP(S)-Load-Balancer aggregiert. Sie können zusammengefasste Messwerte nach den folgenden Dimensionen filtern(*).

Diese Tabelle filtern:

Attribut	Beschreibung
BACKEND SCOPE	Der GCP-Bereich (Region oder Zone) der Back-End-Dienst-Instanzgruppe, die die Verbindung bereitgestellt hat. Wenn keine Instanzgruppe verfügbar war oder die Anfrage von einer anderen Entität verarbeitet wurde, wird anstelle der Region oder Zone der Back-End-Dienst-Instanzgruppe einer der folgenden Werte angezeigt: FRONTEND_5XX: Es ist ein interner Fehler aufgetreten, bevor ein Back-End vom GFE ausgewählt werden konnte. Das GFE hat 5XX an den Client zurückgegeben. INVALID_BACKEND: Das GFE konnte kein fehlerfreies Back-End finden, um diesem die Anfrage zuzuweisen, und hat deshalb eine 5XX-Antwort an den Sender der Anfrage zurückgegeben. NO_BACKEND_SELECTED: Ein Fehler oder eine andere Unterbrechung ist aufgetreten, bevor ein Back-End ausgewählt werden konnte. SERVED_FROM_BACKEND_BUCKET: Die Anfrage wurde von einem Back-End-Bucket und nicht von einer Back-End-Dienst-Instanzgruppe verarbeitet. SERVED_FROM_CACHE: Die Anfrage wurde von einem GFE-Cache verarbeitet, also wurde kein Back-End zugewiesen. MULTIPLE_BACKENDS: Die Anfrage wurde von möglicherweise mehreren Back-Ends bereitgestellt. Der Cache hat mindestens eine Bytebereichsanfrage an ein anderes Back-End gesendet. Mit der Aufschlüsselung von BACKEND_SCOPE können Sie jede Anfrage vom Load-Balancer zum Back-End visualisieren. Mit dieser Aufschlüsselung werden in den Diagrammen Back-End-Messwerte (Load-Balancer in Richtung der Back-Ends) und nicht Front-End-Messwerte (Client in Richtung des Load-Balancers) angezeigt.
BACKEND ZONE	Wenn die Instanzgruppe eine zonale Instanzgruppe war, ist dies die GCP-Zone der Instanzgruppe, die den Nutzer-Request verarbeitet hat. (Beispiele: us-central1-a, europe-west1-b, asia-east1-c) Mit dieser Aufschlüsselung werden in den Diagrammen Back-End-Messwerte (Load-Balancer in Richtung der Back-Ends) und nicht Front-End-Messwerte (Client in Richtung des Load-Balancers) angezeigt.
BACKEND REGION	Wenn die Instanzgruppe eine regionale Instanzgruppe war, ist dies die GCP-Region der Instanzgruppe, die den Nutzer-Request verarbeitet hat. (Beispiele: us-central1, europe-west1, asia-east1) Mit dieser Aufschlüsselung werden in den Diagrammen Back-End-Messwerte (Load-Balancer in Richtung der Back-Ends) und nicht Front-End-Messwerte (Client in Richtung des Load-Balancers) angezeigt.
PROXY CONTINENT	Kontinent des HTTP(S)-GFE, das die HTTP(S)-Nutzeranfrage beendet hat. (Beispiele: America, Europe, Asia)
INSTANCE GROUP	Der Name der Instanzgruppe, die die Nutzeranfrage verarbeitet hat. Wenn keine Instanzgruppe verfügbar war oder die Anfrage von einer anderen Entität verarbeitet wurde, wird anstelle einer Instanzgruppe einer der folgenden Werte angezeigt. FRONTEND_5XX: Es ist ein interner Fehler aufgetreten, bevor ein Back-End vom GFE ausgewählt werden konnte. Das GFE hat 5XX an den Client zurückgegeben. INVALID_BACKEND: Das GFE konnte kein fehlerfreies Back-End finden, um diesem die Anfrage zuzuweisen, und hat deshalb eine 5XX-Antwort an den Sender der Anfrage zurückgegeben. NO_BACKEND_SELECTED: Ein Fehler oder eine andere Unterbrechung ist aufgetreten, bevor ein Back-End ausgewählt werden konnte. INVALID_BACKEND: Das GFE konnte kein gültiges fehlerfreies Back-End finden und gab 5XX an den Sender der Anfrage zurück. SERVED_FROM_BACKEND_BUCKET: Die Anfrage wurde von einem Back-End-Bucket und nicht von einer Back-End-Dienst-Instanzgruppe verarbeitet. SERVED_FROM_CACHE: Die Anfrage wurde von Cloud CDN verarbeitet, also wurde kein Back-End zugewiesen. MULTIPLE_BACKENDS: Die Anfrage wurde von mehreren Back-Ends bereitgestellt. Mit dieser Aufschlüsselung werden in den Diagrammen Back-End-Messwerte (Load-Balancer in Richtung der Back-Ends) und nicht Front-End-Messwerte (Client in Richtung des Load-Balancers) angezeigt.
BACKEND SERVICE	Der Name des Back-End-Dienstes, von dem die Nutzeranfrage verarbeitet wurde.
MATCHED URL RULE	Die Pfadregel der URL-Zuordnung, die mit dem Präfix der HTTP(S)-Nutzeranfrage übereinstimmte (bis zu 50 Zeichen).
FORWARDING RULE	Der Name der Weiterleitungsregel, die vom Client zum Senden des Requests verwendet wird.

(*) Momentan ist der Messwert "Anteil der Antwortcodeklasse" nur für komplette Load-Balancer ohne weitere Aufschlüsselungsmöglichkeiten verfügbar.

Weitere Informationen

• Konzeptionelle Informationen zum HTTP(S)-Load-Balancing lesen
• Einen inhaltsbasierten und regionenübergreifenden externen HTTP(S)-Load-Balancer erstellen.
• Back-End-Bucket zu einem inhaltsbasierten Load-Balancer hinzufügen.
• Mehr über Weiterleitungsregeln lesen
• Lesen Sie mehr zum Einrichten von URL-Zuordnungen oder zu konzeptionellen Informationen zu URL-Zuordnungen.
• SSL-Zertifikate konfigurieren.
• SSL-Richtlinien erstellen