Systemdiagnosen verwenden

Google Cloud bietet Mechanismen zur Systemdiagnose, die bestimmen, ob Back-End-Instanzen ordnungsgemäß auf den Traffic reagieren. In diesem Dokument wird beschrieben, wie Systemdiagnosen für Load Balancer und Cloud Service Mesh erstellt und verwendet werden.

Auf dieser Seite wird davon ausgegangen, dass Sie mit den folgenden Konzepten vertraut sind:

Systemdiagnosen erstellen

Mit Google Cloud können Sie eine Systemdiagnose erstellen oder auswählen, wenn Sie die Backend-Konfiguration des Load Balancers in der Google Cloud Console abschließen.

Sie können eine Systemdiagnose auch unabhängig von der Load-Balancer-Konfiguration in der Google Cloud Console erstellen. Dies ist nützlich, wenn Sie zuerst Ihre Systemdiagnose erstellen müssen oder wenn Sie eine Systemdiagnose für mehrere Load-Balancer verwenden möchten. Sie können eine Systemdiagnose mit der Google Cloud Console, mit der Google Cloud CLI oder den REST APIs erstellen.

Backend-Dienst-basierte externe Passthrough-Network Load Balancer verwenden die in diesem Abschnitt beschriebenen Nicht-Legacy Systemdiagnosen.

Console

  1. Rufen Sie in der Google Cloud Console die Seite "Systemdiagnosen" auf.
    Zur Seite "Systemdiagnosen"
  2. Klicken Sie auf Systemdiagnose erstellen.
  3. Geben Sie auf der Seite Systemdiagnose erstellen die folgenden Informationen an:
    • Name: Geben Sie einen Namen für die Systemdiagnose ein.
    • Beschreibung: Geben Sie optional eine Beschreibung ein.
    • Bereich: Wählen Sie einen Bereich aus, entweder Global oder Regional, je nach Art des Load-Balancers.
      • Wenn Sie Regional ausgewählt haben, wählen Sie eine Region aus dem Drop-down-Menü aus.
    • Protokoll: Wählen Sie ein Protokoll für die Systemdiagnose aus.
    • Port: Geben Sie eine Portnummer an. Wenn Sie eine Systemdiagnose in der Google Cloud Console erstellen, müssen Sie den Port mit einer Portnummer angeben.
    • Proxy-Protokoll: Optional können Sie einen Proxy-Header an die Anfragen anfügen, die von den Prüfsystemen der Systemdiagnose gestellt werden.
    • Anfragepfad und Antwort: Bei HTTP-, HTTPS- und HTTP2-Protokollen können Sie optional einen URL-Pfad angeben, den die Prüfsysteme der Systemdiagnose kontaktieren. Weitere Informationen finden Sie unter Zusätzliche Flags für HTTP-, HTTPS- und HTTP/2-Systemdiagnosen.
    • Anfrage und Antwort: Bei TCP- und SSL-Protokollen können Sie einen zu sendenden ASCII-Textstring und einen erwarteten Textantwortstring angeben. Weitere Informationen finden Sie unter Zusätzliche Flags für SSL- und TCP-Systemdiagnosen.
    • Überprüfungsintervall: Definieren Sie die Zeitspanne vom Start einer Prüfung bis zum Start der nächsten.
    • Zeitlimit: Definieren Sie die Zeitspanne, die Google Cloud auf eine Antwort auf eine Prüfung wartet. Der Wert muss kleiner oder gleich dem Überprüfungsintervall sein.
    • Schwellenwert für Intaktheit: Definieren Sie die Anzahl der sequenziellen Prüfungen, die erfolgreich sein müssen, damit die VM-Instanz als fehlerfrei gilt.
    • Fehlerschwellenwert: Definieren Sie die Anzahl der sequenziellen Prüfungen, die fehlschlagen müssen, damit die VM-Instanz als fehlerhaft gilt.
  4. Klicken Sie auf Erstellen.

gcloud

  • Verwenden Sie zum Erstellen einer globalen Systemdiagnose den geeigneten Befehl compute health-checks create:

    gcloud compute health-checks create PROTOCOL NAME \
    --global \
    --description=DESCRIPTION \
    --check-interval=CHECK_INTERVAL \
    --timeout=TIMEOUT \
    --healthy-threshold=HEALTHY_THRESHOLD \
    --unhealthy-threshold=UNHEALTHY_THRESHOLD \
    PORT_SPECIFICATION \
    ADDITIONAL_FLAGS

  • Verwenden Sie zum Erstellen einer regionalen Systemdiagnose den geeigneten Befehl compute health-checks create:

    gcloud compute health-checks create PROTOCOL NAME \
    --region=REGION \
    --description=DESCRIPTION \
    --check-interval=CHECK_INTERVAL \
    --timeout=TIMEOUT \
    --healthy-threshold=HEALTHY_THRESHOLD \
    --unhealthy-threshold=UNHEALTHY_THRESHOLD \
    PORT_SPECIFICATION \
    ADDITIONAL_FLAGS

Ersetzen Sie Folgendes:

  • PROTOCOL definiert das für die Systemdiagnose verwendete Protokoll. Gültige Optionen sind grpc, http, https, http2, ssl und tcp.
  • NAME ist der Name der Systemdiagnose. Innerhalb eines bestimmten Projekts: Jede globale Systemdiagnose muss einen eindeutigen Namen haben und regionale Systemdiagnosen müssen innerhalb einer bestimmten Region eindeutige Namen haben.
  • REGION: Die Region der Systemdiagnose. Bei regionalen Load Balancern muss die Region der Systemdiagnose mit der Region des Back-End-Dienstes übereinstimmen.
  • DESCRIPTION ist eine optionale Beschreibung.
  • CHECK_INTERVAL ist die Zeitspanne vom Start der Verbindung eines Prüfsystems zur Systemdiagnose bis zum Start der nächsten. Die Einheit sind Sekunden. Wenn keine Angabe gemacht wird, verwendet Google Cloud den Wert 5s (5 Sekunden).
  • TIMEOUT ist die Zeitspanne, die Google Cloud bei einer Prüfung auf eine Antwort wartet. Der Wert von TIMEOUT muss kleiner oder gleich CHECK_INTERVAL sein. Die Einheit sind Sekunden. Wenn keine Angabe gemacht wird, verwendet Google Cloud den Wert 5s (5 Sekunden).
  • HEALTHY_THRESHOLD und UNHEALTHY_THRESHOLD geben die Anzahl der sequenziellen Testdurchläufe an, die bestanden werden oder fehlschlagen müssen, damit die VM-Instanz als fehlerfrei oder fehlerhaft eingestuft wird. Wenn einer der Parameter nicht angegeben ist, verwendet Google Cloud den Standardschwellenwert 2.
  • PORT_SPECIFICATION: Definiert die Portspezifikation mit einem der Flags zur Portspezifikation.
  • ADDITIONAL_FLAGS sind weitere Flags zur Festlegung von Ports und Optionen speziell für das PROTOCOL. Weitere Informationen finden Sie unter Zusätzliche Flags für HTTP-, HTTPS- und HTTP/2-Systemdiagnosen, Zusätzliche Flags für SSL- und TCP-Systemdiagnosen oder Zusätzliches Flag für gRPC-Systemdiagnosen.

Terraform

Verwenden Sie zum Erstellen einer globalen Systemdiagnose die Ressource google_compute_health_check. 

resource "google_compute_health_check" "health_check_tcp_with_logging" {
  provider = google-beta

  name = "health-check-tcp"

  timeout_sec        = 1
  check_interval_sec = 1

  tcp_health_check {
    port = "22"
  }

  log_config {
    enable = true
  }
}

Verwenden Sie zum Erstellen einer regionalen Systemdiagnose die Ressource google_compute_region_health_check. 

resource "google_compute_region_health_check" "default" {
  name               = "tcp-health-check-region-west"
  timeout_sec        = 5
  check_interval_sec = 5
  tcp_health_check {
    port = "80"
  }
  region = "us-west1"
}

Informationen zum Anwenden oder Entfernen einer Terraform-Konfiguration finden Sie unter Grundlegende Terraform-Befehle.

API

Systemdiagnosen ändern

Sie können eine Systemdiagnose nicht in eine Legacy-Systemdiagnose (oder umgekehrt) umwandeln, indem Sie die Systemdiagnose ändern. Sie können auch den Namen oder Bereich einer Systemdiagnose nicht ändern (z. B. global in regional).

Console

  1. Rufen Sie in der Google Cloud Console die Seite "Systemdiagnosen" auf.
    Zur Seite "Systemdiagnosen"
  2. Klicken Sie auf eine Systemdiagnose, um die zugehörigen Details anzusehen.
  3. Wenn Sie die Systemdiagnose ändern müssen, klicken Sie auf Bearbeiten und gehen Sie dann so vor:
    • Nehmen Sie nach Bedarf Änderungen an den Parametern vor.
    • Klicken Sie auf Speichern.

gcloud

  1. Geben Sie den Namen und den Bereich der Systemdiagnose an. Eine Anleitung finden Sie unter Systemdiagnosen auflisten.

  2. Mit Ausnahme des Namens, Protokolls und des Bereichs einer Systemdiagnose können Sie alle allgemeinen Flags, Flags zur Portspezifikation und andere zusätzliche Flags ändern. Verwenden Sie zum Ändern einer vorhandenen Systemdiagnose den geeigneten compute health-checks update-Befehl. Bei Flags, die Sie weglassen, bleiben die vorkonfigurierten Einstellungen erhalten.

    • Beispiel für die Änderung einer globalen Systemdiagnose: Der folgende Befehl ändert eine globale HTTP-Systemdiagnose mit dem Namen hc-http-port-80, indem ihr Prüfintervall, Zeitlimit und Anfragepfad geändert werden:

      gcloud compute health-checks update http hc-http-port-80 \
    --global \
    --check-interval=20s \
    --timeout=15s \
    --request-path="/health"

    • Beispiel für die Änderung einer regionalen Systemdiagnose: Der folgende Befehl ändert eine regionale TCP-Systemdiagnose in us-west1 mit dem Namen hc-west1-tcp-ldap, indem die Portspezifikation geändert wird:

      gcloud compute health-checks update tcp hc-west1-tcp-ldap \
    --region=us-west1 \
    --port=631

API

  1. Geben Sie den Namen und den Bereich der Systemdiagnose an. Eine Anleitung finden Sie unter Systemdiagnosen auflisten.

  2. Mit Ausnahme des Namens, Protokolls und des Bereichs einer Systemdiagnose können Sie mit diesen API-Aufrufen alle allgemeinen Flags, Flags zur Portspezifikation und andere zusätzliche Flags ändern. Verwenden Sie patch-API-Aufrufe, um alle vorkonfigurierten Einstellungen beizubehalten, die nicht explizit in der Anfrage festgelegt wurden.

Systemdiagnosen auflisten

Console

  1. Rufen Sie in der Google Cloud Console die Seite "Systemdiagnosen" auf.
    Zur Seite "Systemdiagnosen"
  2. Klicken Sie auf eine Systemdiagnose, um die zugehörigen Details anzusehen.

gcloud

Verwenden Sie den Befehl compute health-checks list, um Systemdiagnosen aufzulisten:

  • So listen Sie globale Systemdiagnosen auf:

    gcloud compute health-checks list \
    --global

  • So listen Sie regionale Systemdiagnosen auf: Ersetzen Sie REGION_LIST durch eine durch Kommas getrennte Liste der abzufragenden Google Cloud-Regionen.

    gcloud compute health-checks list \
    --regions=REGION_LIST

Nachdem Sie den Namen und den Bereich einer Systemdiagnose kennen, können Sie mit dem Befehl compute health-checks describe die aktuelle Konfiguration ansehen.

  • Um eine globale Systemdiagnose zu beschreiben, ersetzen Sie NAME durch deren Namen.

    gcloud compute health-checks describe NAME \
    --global

  • Um eine regionale Systemdiagnose zu beschreiben, ersetzen Sie NAME durch deren Namen und REGION durch deren Region.

    gcloud compute health-checks describe NAME \
    --region=REGION

API

Verwenden Sie diese API-Aufrufe, um Systemdiagnosen aufzulisten:

Verwenden Sie Folgendes, um die aktuelle Konfiguration einer Systemdiagnose zu beschreiben:

Zusätzliche Flags

In diesem Abschnitt werden zusätzliche Flags beschrieben, die Sie beim Erstellen oder Ändern einer Systemdiagnose verwenden können. Einige Flags, wie die Portspezifikation, müssen mithilfe von gcloud oder der API festgelegt werden.

Flags zur Portspezifikation

Wenn Sie eine Systemdiagnose mit der Google Cloud-Befehlszeile oder der API erstellen, haben Sie zwei Möglichkeiten, den Port der Systemdiagnose anzugeben. Die folgende Tabelle enthält Optionen der Portspezifikation für gültige Kombinationen von Load-Balancern und Back-Ends. Der Begriff Instanzgruppe bezieht sich auf nicht verwaltete Instanzgruppen, zonal verwaltete Instanzgruppen oder regional verwaltete Instanzgruppen.

Jede Systemdiagnose kann nur einen Typ von Portspezifikation verwenden.

Produkt Backend-Typ Optionen für die Portspezifikation
Externer Passthrough Network Load Balancer Instanzgruppen und unterstützte NEGs

--port: Geben Sie einen TCP-Port als Zahl an, von 1 bis 65535.

Das Flag --use-serving-port wird für eine Systemdiagnose ignoriert, die mit einem internen Passthrough-Network Load Balancer verknüpft ist, da Back-End-Dienste für diesen Load Balancer keine benannten Ports abonnieren. Dies liegt daran, dass es sich um Pass-Through-Load-Balancer handelt, die Pakete direkt an Back-Ends weiterleiten, anstatt neue Verbindungen vom Load Balancer zum Back-End zu erstellen.
Zielpools Legacy-Systemdiagnosen unterstützen nur die Spezifikation für die Portnummer (--port).
Interner Passthrough-Network Load Balancer Instanzgruppen und unterstützte NEGs

--port: Geben Sie einen TCP-Port als Zahl an, von 1 bis 65535.

Das Flag --use-serving-port wird für eine Systemdiagnose ignoriert, die mit einem internen Passthrough-Network Load Balancer verknüpft ist, da Back-End-Dienste für diesen Load Balancer keine benannten Ports abonnieren. Dies liegt daran, dass es sich um Pass-Through-Load-Balancer handelt, die Pakete direkt an Back-Ends weiterleiten, anstatt neue Verbindungen vom Load Balancer zum Back-End zu erstellen.
Globaler externer Application Load Balancer

Klassischer Application Load Balancer

Regionaler externer Application Load Balancer

Regionenübergreifender interner Application Load Balancer

Regionaler interner Application Load Balancer

Globaler externer Proxy-Network Load Balancer

Klassischer Proxy-Network Load Balancer

Regionaler externer Proxy-Network Load Balancer

Regionenübergreifender interner Proxy-Network Load Balancer

Regionaler interner Proxy-Network Load Balancer

Cloud Service Mesh 		Unterstützte NEGs
  • --port: Geben Sie einen TCP-Port als Zahl an, von 1 bis 65535.
  • --use-serving-port: Verwenden Sie den Port jedes Endpunkts in der Netzwerk-Endpunktgruppe.
Instanzgruppen
  • --port: Geben Sie einen TCP-Port als Zahl an, von 1 bis 65535.
  • --use-serving-port: Verwenden Sie denselben benannten Port der Instanzgruppe, den der Back-End-Dienst verwendet.

Wenn Sie die Portspezifikation beim Erstellen der Systemdiagnose weglassen, verwendet Google Cloud die folgenden Standardeinstellungen:

  • Wenn das Protokoll der Systemdiagnose TCP oder HTTP ist, wird --port=80 verwendet.
  • Wenn das Protokoll der Systemdiagnose SSL, HTTPS oder HTTP2 ist, wird --port=443 verwendet.
  • Wenn das Protokoll der Systemdiagnose GRPC lautet, gibt es keinen implizierten Standardwert und Sie müssen die Portspezifikation angeben.

Zusätzliche Flags für HTTP-, HTTPS- und HTTP/2-Systemdiagnosen

Zusätzlich zu den allgemeinen Flags und Portspezifikationen können Sie die folgenden optionalen Flags für HTTP-, HTTPS- und HTTP/2-Systemdiagnosen verwenden. In diesem Beispiel wird eine HTTP-Systemdiagnose namens hc-http-port-80 unter Verwendung von Port 80 mit Standardkriterien für Intervall, Zeitlimit und Fehlerschwellenwert erstellt.

gcloud compute health-checks create HTTP_PROTOCOL hc-http-port-80 \
    COMMON_FLAGS \
    PORT_SPECIFICATION \
    --host=HOST \
    --proxy-header=PROXY_HEADER \
    --request-path=REQUEST_PATH \
    --response=RESPONSE
  • HTTP_PROTOCOL: Kann http (HTTP/1.1 ohne TLS), https (HTTP/1.1 mit TLS) oder http2 (HTTP/2 mit TLS) sein.
  • COMMON_FLAGS: Definiert die allgemeinen Flags. Siehe Erstellungsverfahren.
  • PORT_SPECIFICATION: Definiert die Portspezifikation mit einem der Flags zur Portspezifikation.
  • Mit HOST können Sie einen Host-HTTP-Header angeben. Wenn nicht angegeben, wird die IP-Adresse der Weiterleitungsregel des Load-Balancers verwendet.
  • PROXY_HEADER muss entweder NONE oder PROXY_V1 sein. Wenn nichts angegeben ist, verwendet Google Cloud NONE. Beim Wert PROXY_V1 wird dem Header PROXY UNKNOWN\r\n hinzugefügt.
  • REQUEST_PATH gibt den URL-Pfad an, den Google Cloud beim Senden von Systemdiagnoseanfragen verwendet. Wenn nichts angegeben ist, werden Systemdiagnoseanfragen an / gesendet.
  • RESPONSE definiert eine optionale erwartete Antwort. Antwortstrings müssen die folgenden Regeln erfüllen:
    • Der Antwortstring muss aus ASCII-Zeichen, Ziffern und Leerzeichen bestehen.
    • Der Antwortstring kann bis zu 1.024 Zeichen lang sein.
    • Der Abgleich von Platzhaltern wird nicht unterstützt.
    • Die inhaltsbasierte Überprüfung unterstützt keine Inversion. Operatoren wie ! in HAProxy werden beispielsweise nicht unterstützt.

Wenn Google Cloud den erwarteten Antwortstring an einer beliebigen Stelle in den ersten 1.024 Byte des empfangenen Antworttexts findet und der HTTP-Status 200 (OK) ist, gilt die Prüfung als erfolgreich.

Die Flags --request-path und --response ändern die Erfolgskriterien für die Prüfung der Systemdiagnose.

Zusätzliche Flags für SSL- und TCP-Systemdiagnosen

Zusätzlich zu den allgemeinen Flags und Portspezifikationen können Sie die folgenden optionalen Flags für SSL- und TCP-Systemdiagnosen verwenden. In diesem Beispiel wird eine TCP-Systemdiagnose namens hc-tcp-3268 unter Verwendung von Port 3268 mit Standardkriterien für Intervall, Zeitlimit und Fehlerschwellenwert erstellt.

gcloud compute health-checks create tcp hc-tcp-3268 \
    COMMON_FLAGS \
    PORT_SPECIFICATION \
    --proxy-header=PROXY_HEADER \
    --request=REQUEST_STRING \
    --response=RESPONSE_STRING
  • Das Protokoll kann tcp (wie in diesem Beispiel) oder ssl sein.
  • COMMON_FLAGS: Definiert die allgemeinen Flags. Siehe Erstellungsverfahren.
  • PORT_SPECIFICATION: Definiert die Portspezifikation mit einem der Flags zur Portspezifikation.
  • PROXY_HEADER muss entweder NONE oder PROXY_V1 sein. Wenn nichts angegeben ist, verwendet Google Cloud NONE. Beim Wert PROXY_V1 wird dem Header PROXY UNKNOWN\r\n hinzugefügt.
  • REQUEST_STRING: Sie können einen bis zu 1.024 ASCII-Zeichen langen String angeben, der gesendet wird, nachdem die TCP- oder SSL-Sitzung erstellt wurde.
  • RESPONSE_STRING: Sie können einen String für die erwartete Antwort von bis zu 1.024 ASCII-Zeichen Länge angeben.

Die Flags --request und --response ändern die Erfolgskriterien für die Prüfung der Systemdiagnose. Wenn Sie das Flag --response entweder allein oder in Verbindung mit dem Flag --request verwenden, muss die zurückgegebene Antwort genau mit dem erwarteten Antwortstring übereinstimmen.

Zusätzliches Flag für gRPC-Systemdiagnosen

Der Back-End-gRPC-Server muss den gRPC-Systemdiagnosedienst implementieren, wie im gRPC-Systemdiagnoseprotokoll beschrieben. Google Cloud sendet durch Aufrufen der Methode Check des Systemdiagnosedienstes in Ihrem Back-End eine HealthCheckRequest-Nachricht an Ihre Back-Ends. Für den Dienstparameter in der Anfrage wird ein leerer String festgelegt, sofern kein gRPC-Dienstname angegeben ist.

Eine gRPC-Systemdiagnose kann den Status eines gRPC-Dienstes prüfen. Sie können einen String mit bis zu 1.024 ASCII-Zeichen verwenden. Das ist der Name eines bestimmten gRPC-Dienstes, der auf einer Back-End-VM oder NEG ausgeführt wird. Verwenden Sie dazu das folgende optionale Flag für gRPC-Systemdiagnosen:

--grpc-service-name=GRPC_SERVICE_NAME

Es können zum Beispiel folgende Dienste und der Status vorliegen, die der Back-End-Server beim gRPC-Systemdiagnosedienstes des Back-Ends registriert.

  • MyPackage.ServiceA mit dem Auslieferungsstatus SERVING
  • MyPackage.ServiceB mit dem Auslieferungsstatus NOT_SERVING
  • Leerer Dienstname mit Auslieferungsstatus NOT_SERVING

Wenn Sie eine Systemdiagnose für MyPackage.ServiceA erstellen, gibt diese Prüfung HEALTHY zurück, da der Status des Dienstes SERVING lautet.

gcloud beta compute health-checks create grpc MyGrpcHealthCheckServiceA \
    --grpc-service-name=MyPackage.ServiceA

Wenn Sie eine Systemdiagnose für MyPackage.ServiceB erstellen, gibt diese Prüfung UNHEALTHY zurück, da der Dienststatus NOT_SERVING lautet.

Wenn Sie eine Systemdiagnose für MyPackage.ServiceC erstellen, die nicht beim gRPC-Systemdiagnosedienst registriert ist, gibt die Systemdiagnose den gRPC-Status NOT_FOUND zurück. Dieser entspricht UNHEALTHY.

Wenn Sie eine Systemdiagnose für den leeren Dienstnamen erstellen, gibt diese Prüfung den Status UNHEALTHY zurück, da der leere Dienstname mit dem Status NOT_SERVING registriert ist.

Legacy-Systemdiagnosen

In diesem Abschnitt wird beschrieben, wie Sie Legacy-HTTP- und HTTPS-Systemdiagnosen erstellen, ändern und auflisten. Sie können eine Legacy-Systemdiagnose nicht in eine Systemdiagnose und eine Systemdiagnose nicht in eine Legacy-Systemdiagnose konvertieren.

Informationen dazu, welche Arten von Load Balancern Legacy-Systemdiagnosen unterstützen, finden Sie in der Load Balancer-Anleitung.

Legacy-Systemdiagnosen erstellen

Console

Obwohl auf der Seite der Systemdiagnosen der Google Cloud Console sowohl Systemdiagnosen als auch Legacy-Systemdiagnosen aufgeführt sind und Sie diese bearbeiten können, können Sie auf der Seite der Systemdiagnosen der Google Cloud Console keine neue Legacy-Systemdiagnose erstellen.

Eine Legacy-Systemdiagnose kann in der Google Cloud Console nur beim Erstellen eines zielpoolbasierten externen Passthrough-Network Load Balancers erstellt werden. Wenn Sie die Legacy-Systemdiagnose allein erstellen möchten, verwenden Sie die gcloud- oder API-Anweisungen in diesem Abschnitt.

gcloud

Verwenden Sie zum Erstellen einer Legacy-Systemdiagnose den Befehl compute http-health-checks create:

gcloud compute LEGACY_CHECK_TYPE create NAME \
    --description=DESCRIPTION \
    --check-interval=CHECK_INTERVAL \
    --timeout=TIMEOUT \
    --healthy-threshold=HEALTHY_THRESHOLD \
    --unhealthy-threshold=UNHEALTHY_THRESHOLD \
    --host=HOST \
    --port=PORT \
    --request-path=REQUEST_PATH

Ersetzen Sie Folgendes:

  • LEGACY_CHECK_TYPE ist http-health-checks für eine Legacy-HTTP-Systemdiagnose oder https-health-checks für eine Legacy-HTTPS-Systemdiagnose. Wenn Sie die Legacy-Systemdiagnose für einen zielpoolbasierten externen Network Load Balancer erstellen, müssen Sie http-health-checks verwenden.
  • NAME ist der Name der Legacy-Systemdiagnose. Innerhalb eines bestimmten Projekts muss jede Legacy-Systemdiagnose einen eindeutigen Namen haben.
  • DESCRIPTION ist eine optionale Beschreibung.
  • CHECK_INTERVAL ist die Zeitspanne vom Start einer Prüfung bis zum Start der nächsten. Die Einheit sind Sekunden. Wenn keine Angabe gemacht wird, verwendet Google Cloud den Wert 5s (5 Sekunden).
  • TIMEOUT ist die Zeitspanne, die Google Cloud auf eine Antwort auf eine Prüfung wartet. Der Wert von TIMEOUT muss kleiner oder gleich CHECK_INTERVAL sein. Die Einheit sind Sekunden. Wenn keine Angabe gemacht wird, verwendet Google Cloud den Wert 5s (5 Sekunden).
  • HEALTHY_THRESHOLD und UNHEALTHY_THRESHOLD geben die Anzahl der sequenziellen Testdurchläufe an, die bestanden werden oder fehlschlagen müssen, damit die VM-Instanz als fehlerfrei oder fehlerhaft eingestuft wird. Wenn einer der Parameter nicht angegeben ist, verwendet Google Cloud den Standardschwellenwert 2.
  • Unter HOST können Sie einen Host-HTTP-Header angeben. Wenn nicht angegeben, wird die IP-Adresse der Weiterleitungsregel des Load-Balancers verwendet.
  • Unter PORT können Sie eine Portnummer angeben. Wenn nichts angegeben ist, verwendet Google Cloud 80.
  • REQUEST_PATH gibt den URL-Pfad an, den Google Cloud beim Senden von Systemdiagnoseanfragen verwendet. Wenn nichts angegeben ist, werden Systemdiagnoseanfragen an / gesendet.

API

Terraform

Legacy-Systemdiagnosen ändern

Console

  1. Rufen Sie in der Google Cloud Console die Seite "Systemdiagnosen" auf.
    Zur Seite "Systemdiagnosen"
  2. Klicken Sie auf eine Systemdiagnose, um die zugehörigen Details anzusehen.
  3. Klicken Sie auf Bearbeiten , nehmen Sie die gewünschten Änderungen vor und klicken Sie dann auf Speichern.

gcloud

  • Verwenden Sie zum Ändern einer Legacy-HTTP-Systemdiagnose den Befehl compute http-health-checks update und ersetzen Sie dabei NAME durch deren Namen. Beim Ändern einer Systemdiagnose mit gcloud werden vorkonfigurierte Einstellungen für die Flags beibehalten, die Sie auslassen. OTHER_OPTIONS sind die Optionen, die unter Legacy-Systemdiagnose erstellen beschrieben werden.

    gcloud compute http-health-checks update NAME \
  OTHER_OPTIONS

  • Verwenden Sie zum Ändern einer Legacy-HTTPS-Systemdiagnose den Befehl compute https-health-checks update und ersetzen Sie dabei NAME durch deren Namen. Beim Ändern einer Systemdiagnose mit gcloud werden vorkonfigurierte Einstellungen für die Flags beibehalten, die Sie auslassen. OTHER_OPTIONS sind die Optionen, die unter Legacy-Systemdiagnose erstellen beschrieben werden.

    gcloud compute https-health-checks update NAME \
  OTHER_OPTIONS

API

Mit Ausnahme des Namens und Typs einer Legacy-Systemdiagnose können Sie alle für die Erstellung verwendeten Flags ändern. Die patch-API-Aufrufe behalten alle vorkonfigurierten Einstellungen bei, die nicht explizit in der Patch-Anfrage festgelegt wurden.

Systemdiagnosen vom älteren Typ auflisten

Console

  1. Rufen Sie in der Google Cloud Console die Seite "Systemdiagnosen" auf.
    Zur Seite "Systemdiagnosen"
  2. Klicken Sie auf eine Legacy-Systemdiagnose, um die zugehörigen Details anzusehen.

gcloud

  1. Verwenden Sie den Befehl compute http-health-checks list, um Legacy-HTTP-Systemdiagnosen aufzulisten:

    gcloud compute http-health-checks list

    Verwenden Sie den Befehl compute https-health-checks list, um Legacy-HTTPS-Systemdiagnosen aufzulisten:

    gcloud compute https-health-checks list

  2. Verwenden Sie zum Beschreiben einer Legacy-HTTP-Systemdiagnose den Befehl compute http-health-checks describe und ersetzen Sie dabei NAME durch deren Namen.

    gcloud compute http-health-checks describe NAME

    Verwenden Sie zum Beschreiben einer Legacy-HTTPS-Systemdiagnose den Befehl compute https-health-checks describe und ersetzen Sie NAME durch deren Namen.

    gcloud compute https-health-checks describe NAME

API

  1. So listen Sie Legacy-Systemdiagnosen auf:

  2. So beschreiben Sie eine Legacy-Systemdiagnose:

Erforderliche Firewallregeln erstellen

Sie müssen Firewallregeln für eingehenden Traffic erstellen, die auf alle VMs mit Load Balancing angewendet werden können und Traffic von IP-Bereichen des Systemdiagnose-Probers zulassen. Im folgenden Beispiel wird eine Firewallregel erstellt, die auf VM-Instanzen angewendet wird, die durch ein bestimmtes Ziel-Tag gekennzeichnet sind.

In diesem Beispiel wird der gesamte TCP-Traffic von Google Cloud-Systemdiagnosen zu Ihren VM-Instanzen zugelassen. (TCP-Traffic umfasst SSL-, HTTP-, HTTPS- und HTTP/2-Traffic.) Wenn Sie möchten, können Sie Ports zusammen mit dem TCP-Protokoll angeben; wenn Sie jedoch Ports angeben, werden Ihre Firewallregeln möglicherweise für eine bestimmte Systemdiagnose spezifisch. Durch die Verwendung von tcp:80 für das Protokoll und den Port wird TCP-Traffic auf Port 80 zugelassen, sodass Google Cloud Ihre VMs über HTTP an Port 80 kontaktieren könnte, aber nicht über HTTPS an Port 443.

Console

  1. Rufen Sie in der Google Cloud Console die Seite Firewall auf.
    Zu den Firewall-Richtlinien
  2. Klicken Sie auf Firewallregel erstellen.
  3. Geben Sie auf der Seite Firewallregel erstellen die folgenden Informationen an:
    • Name: Geben Sie einen Namen für die Regel an. Verwenden Sie für dieses Beispiel fw-allow-health-checks.
    • Netzwerk: Wählen Sie ein VPC-Netzwerk aus.
    • Priorität: Geben Sie eine Zahl für die Priorität ein. Niedrigere Zahlen haben höhere Prioritäten. Achten Sie darauf, dass die Firewallregel eine höhere Priorität hat als andere Regeln, die möglicherweise eingehenden Traffic ablehnen.
    • Traffic-Richtung: Wählen Sie eingehend aus.
    • Aktion bei Übereinstimmung: Wählen Sie Zulassen aus.
    • Ziele: Wählen Sie Angegebene Ziel-Tags aus und geben Sie dann Tags in das Feld Ziel-Tags ein. Verwenden Sie für dieses Beispiel allow-health-checks.
    • Quellfilter: Wählen Sie IP-Bereiche aus.
    • Quell-IP-Bereiche: Geben Sie den Quell-IP-Bereich entsprechend dem Load Balancer-Typ, dem Traffictyp und dem Typ der Systemdiagnose ein. Weitere Informationen finden Sie unter Prüfungs-IP-Bereiche und Firewallregeln.
    • Zulässige Protokolle und Ports: Verwenden Sie tcp und den in Ihrer Systemdiagnose konfigurierten Port. TCP ist das zugrunde liegende Protokoll für alle Systemdiagnose-Protokolle.
    • Klicken Sie auf Erstellen.
  4. Fügen Sie das Netzwerk-Tag auf jeder Ihrer Instanzen mit Load-Balancing hinzu, sodass diese neue Firewallregel für eingehenden Traffic auf sie angewendet wird. In diesem Beispiel wird allow-health-checks für das Netzwerk-Tag verwendet.

gcloud

  1. Erstellen Sie mit dem folgenden gcloud-Befehl eine Firewallregel namens fw-allow-health-checks, die eingehende TCP-Verbindungen von Google Cloud-Systemdiagnosen zu Instanzen in Ihrem VPC-Netzwerk mit dem Tag allow-health-checks zulässt. Je nach Load Balancer-Typ werden für IPv6-Traffic zu den Backends unterschiedliche Prüf-IP-Bereiche und Firewallregeln unterstützt.

    Ersetzen Sie NETWORK_NAME durch den Namen Ihres VPC-Netzwerks und PORT durch die von Ihrem Load-Balancer verwendeten Ports.

    gcloud compute firewall-rules create fw-allow-health-checks \
    --network=NETWORK_NAME \
    --action=ALLOW \
    --direction=INGRESS \
    --source-ranges=SOURCE_IP_RANGE \
    --target-tags=allow-health-checks \
    --rules=tcp:PORT

    Der Wert für SOURCE_IP_RANGE hängt vom Load Balancer-Typ, dem Traffictyp und dem Typ der Systemdiagnose ab. Weitere Informationen finden Sie unter Prüfungs-IP-Bereiche und Firewallregeln.

  2. Fügen Sie das Netzwerk-Tag auf jeder Ihrer Instanzen mit Load-Balancing hinzu, sodass diese neue Firewallregel für eingehenden Traffic auf sie angewendet wird. In diesem Beispiel wird allow-health-checks für das Netzwerk-Tag verwendet.

Weitere Informationen finden Sie in der Dokumentation zu gcloud-Firewallregeln und in der API-Dokumentation.

Weitere Dokumentation:

Systemdiagnosen mit Load Balancern verknüpfen

Lesen Sie den Hilfeartikel Übersicht über Systemdiagnosen: Systemdiagnose auswählen, falls Sie dies noch nicht getan haben.

Informationen zum Verknüpfen einer Systemdiagnose mit einem neuen Load Balancer finden Sie in der Einrichtungsanleitung für den entsprechenden Load Balancer. In diesem Abschnitt wird beschrieben, wie Sie eine Systemdiagnose mit dem Backend-Dienst eines vorhandenen Load Balancers verknüpfen.

Folgende Voraussetzungen sollten für diesen Abschnitt erfüllt sein. Sie haben:

Console

So verknüpfen Sie eine Systemdiagnose mit einem vorhandenen Load-Balancer:

  1. Öffnen Sie in der Google Cloud Console die Seite "Load-Balancing".
    Zur Seite „Load-Balancing“
  2. Klicken Sie auf einen Load Balancer, um dessen Details aufzurufen.
  3. Klicken Sie auf Bearbeiten und anschließend auf Back-End-Konfiguration.
  4. Wählen Sie aus dem Menü Systemdiagnose eine Systemdiagnose aus.
  5. Klicken Sie auf Aktualisieren.

gcloud

So verknüpfen Sie eine Systemdiagnose mit einem vorhandenen Back-End-Dienst:

  1. Ermitteln Sie den Namen und den Bereich des Backend-Dienstes. Passthrough-Network Load Balancer und Proxy-Network Load Balancer haben nur einen Backend-Dienst pro Load Balancer. Die Application Load Balancer haben einen oder mehrere Backend-Dienste, die mit einer einzelnen URL-Zuordnung verknüpft sind.

    • Führen Sie den folgenden Befehl aus, um Backend-Dienste für interne Passthrough-Network Load Balancer aufzulisten.

      gcloud compute backend-services list \
    --region=REGION \
    --filter="loadBalancingScheme=INTERNAL"

    • Führen Sie den folgenden Befehl aus, um Backend-Dienste für externe Passthrough-Network Load Balancer aufzulisten.

      gcloud compute backend-services list \
    --region=REGION \
    --filter="loadBalancingScheme=EXTERNAL"

    • Führen Sie den folgenden Befehl aus, um Backend-Dienste für globale externe Proxy-Network Load Balancer aufzulisten.

      gcloud compute backend-services list \
    --global \
    --filter="loadBalancingScheme=EXTERNAL_MANAGED" \
    --filter="protocol=(SSL,TCP)"

    • Führen Sie den folgenden Befehl aus, um Backend-Dienste für klassische Proxy-Network Load Balancer aufzulisten.

      gcloud compute backend-services list \
    --global \
    --filter="loadBalancingScheme=EXTERNAL" \
    --filter="protocol=(SSL,TCP)"

    • Führen Sie den folgenden Befehl aus, um Backend-Dienste für regionenübergreifende interne Proxy-Network Load Balancer aufzulisten.

      gcloud compute backend-services list \
    --global \
    --filter="loadBalancingScheme=INTERNAL_MANAGED" \
    --filter="protocol=(SSL,TCP)"

    • Führen Sie den folgenden Befehl aus, um Backend-Dienste für regionale externe Proxy-Network Load Balancer aufzulisten.

      gcloud compute backend-services list \
    --region=REGION \
    --filter="loadBalancingScheme=EXTERNAL_MANAGED" \
    --filter="protocol=(SSL,TCP)"

    • Führen Sie den folgenden Befehl aus, um Backend-Dienste für regionale interne Proxy-Network Load Balancer aufzulisten.

      gcloud compute backend-services list \
    --region=REGION \
    --filter="loadBalancingScheme=INTERNAL_MANAGED" \
    --filter="protocol=(SSL,TCP)"

    • Zum Identifizieren von Backend-Diensten für globale externe Application Load Balancer, klassische Application Load Balancer und regionenübergreifende interne Application Load Balancer ermitteln Sie zuerst eine URL-Zuordnung und beschreiben diese anschließend. URL-Zuordnungen und Backend-Dienste für diese Load Balancer sind immer global, unabhängig von der Netzwerkdienststufe. Ersetzen Sie URL_MAP_NAME durch den Namen der URL-Zuordnung. Die vom Load-Balancer verwendeten Back-End-Dienste sind in der Antwort aufgeführt.

      gcloud compute url-maps list \
    --global

      gcloud compute url-maps describe URL_MAP_NAME \
    --global

    • Zum Identifizieren von Backend-Diensten für einen regionalen externen Application Load Balancer oder einen regionalen internen Application Load Balancer ermitteln Sie zuerst eine URL-Zuordnung und beschreiben diese anschließend. Sowohl URL-Zuordnungen als auch Backend-Dienste für diese Load Balancer sind regional. Ersetzen Sie REGION_LIST durch eine durch Kommas getrennte Liste der abzufragenden Google Cloud-Regionen. Ersetzen Sie URL_MAP_NAME durch den Namen der URL-Zuordnung und REGION durch die Region. Die vom Load-Balancer verwendeten Backend-Dienste sind in der Antwort aufgeführt.

      gcloud compute url-maps list \
    --regions=REGION_LIST

      gcloud compute url-maps describe URL_MAP_NAME \
    --region=REGION

  2. Ermitteln Sie eine Systemdiagnose. Siehe Systemdiagnosen auflisten.

  3. Verknüpfen Sie mit dem Befehl compute backend-services update eine Systemdiagnose mit dem Back-End-Dienst. Jeder Back-End-Dienst muss auf eine einzelne Systemdiagnose verweisen. Ersetzen Sie in den folgenden Befehlen BACKEND_SERVICE_NAME durch den Namen des Backend-Dienstes, HEALTH_CHECK_NAME durch den Namen der Systemdiagnose und gegebenenfalls REGION durch die Google Cloud-Region des Backend-Dienstes, den Status oder beide.

    • So ändern Sie die Systemdiagnose eines internen Passthrough-Network Load Balancer: Der Backend-Dienst eines internen Passthrough-Network Load Balancer ist regional. Er kann auf eine globale oder regionale Systemdiagnose verweisen. Das folgende Beispiel zeigt eine regionale Systemdiagnose. Wenn Sie eine globale Systemdiagnose mit Ihrem internen Passthrough-Network Load Balancer verwenden, verwenden Sie --global-health-checks anstelle von --health-checks-region.

      gcloud compute backend-services update BACKEND_SERVICE_NAME \
    --region=REGION \
    --health-checks=HEALTH_CHECK_NAME \
    --health-checks-region=REGION

    • So ändern Sie die Systemdiagnose eines Backend-Dienst-basierten externen Network Load Balancer: Ein externer Passthrough-Network Load Balancer-Backend-Dienst ist regional. Er kann auf eine regionale Systemdiagnose verweisen.

      gcloud compute backend-services update BACKEND_SERVICE_NAME \
    --region=REGION \
    --health-checks=HEALTH_CHECK_NAME \
    --health-checks-region=REGION

    • So ändern Sie die Systemdiagnose für einen globalen externen Proxy-Network Load Balancer, klassischen Proxy-Network Load Balancer, globalen externen Application Load Balancer, klassischen Application Load Balancer oder einen regionenübergreifenden internen Application Load Balancer: Sowohl der Backend-Dienst als auch die Systemdiagnose sind für diese Load Balancer global. Application Load Balancer können auf mehrere Systemdiagnosen verweisen, wenn sie auf mehr als einen Backend-Dienst verweisen.

      gcloud compute backend-services update BACKEND_SERVICE_NAME \
    --global \
    --health-checks HEALTH_CHECK_NAME \
    --global-health-checks

    • So ändern Sie die Systemdiagnose für einen regionalen externen Application Load Balancer, regionalen externen Proxy-Network Load Balancer, regionalen internen Application Load Balancer oder einen regionalen internen Proxy-Network Load Balancer: Sowohl der Backend-Dienst als auch die Systemdiagnose sind regional. Einige Load Balancer verweisen möglicherweise auf mehrere Systemdiagnosen, wenn sie auf mehr als einen Backend-Dienst verweisen können.

      gcloud compute backend-services update BACKEND_SERVICE_NAME \
    --region=REGION \
    --health-checks=HEALTH_CHECK_NAME \
    --health-checks-region=REGION

API

  1. Sie können Back-End-Dienste mit dem API-Aufruf backendServices.list auflisten.

  2. Rufen Sie Systemdiagnosen auf.

  3. Verwenden Sie einen der folgenden API-Aufrufe, um eine Systemdiagnose mit einem Backend-Dienst zu verknüpfen:

Legacy-Systemdiagnosen mit zielpoolbasierten externen Passthrough-Network Load Balancern verknüpfen

Informationen zum Verknüpfen einer Legacy-Systemdiagnose mit einem neuen externen Passthrough-Network Load Balancer finden Sie unter Externen Passthrough-Network Load Balancer mit einem Zielpool einrichten. In diesem Abschnitt wird beschrieben, wie Sie eine Legacy-Systemdiagnose mit einem zielpoolbasierten externen Passthrough-Network Load Balancer verknüpfen.

Folgende Voraussetzungen sollten für diesen Abschnitt erfüllt sein. Sie haben:

Console

So verknüpfen Sie eine Systemdiagnose mit einem vorhandenen zielpoolbasierten externen Passthrough-Network Load Balancerr:

  1. Öffnen Sie in der Google Cloud Console die Seite "Load-Balancing".
    Zur Seite „Load-Balancing“
  2. Klicken Sie auf einen Load Balancer, um dessen Details aufzurufen.
  3. Klicken Sie auf Bearbeiten und anschließend auf Back-End-Konfiguration.
  4. Wählen Sie aus dem Menü Systemdiagnose eine Legacy-Systemdiagnose aus. (Es werden nur zulässige Systemdiagnosen angezeigt.)
  5. Klicken Sie auf Aktualisieren.

gcloud

So verknüpfen Sie eine Systemdiagnose mit einem vorhandenen zielpoolbasierten externen Passthrough-Network Load Balancerr:

  1. Ermitteln Sie den Zielpool bzw. die Zielpools. Ein externer Passthrough-Network Load Balancer hat mindestens einen Zielpool und möglicherweise einen sekundären Back-up-Pool.

    gcloud compute target-pools list

  2. Ermitteln Sie eine Legacy-Systemdiagnose mithilfe des HTTP-Protokolls. Rufen Sie bei Bedarf die Legacy-Systemdiagnosen auf.

  3. Verknüpfen Sie die Legacy-Systemdiagnose mit dem Zielpool bzw. den Zielpools. Ersetzen Sie in den folgenden Befehlen TARGET_POOL_NAME durch den Namen des Zielpools, REGION durch seine Region und LEGACY_CHECK_NAME durch den Namen der Legacy-Systemdiagnose. Die Legacy-Systemdiagnose muss das HTTP-Protokoll verwenden.

    • So entfernen Sie eine Legacy-HTTP-Systemdiagnose aus einem Zielpool:

      gcloud compute target-pools remove-health-checks TARGET_POOL_NAME \
    --region=REGION \
    --http-health-check LEGACY_CHECK_NAME

    • So fügen Sie einem Zielpool eine Legacy-HTTP-Systemdiagnose hinzu:

      gcloud compute target-pools add-health-checks TARGET_POOL_NAME \
    --region=REGION \
    --http-health-check LEGACY_CHECK_NAME

API

  1. Sie können Zielpools mit dem API-Aufruf targetPools.list auflisten.

  2. Rufen Sie die Legacy-Systemdiagnosen auf und ermitteln Sie eine Legacy-HTTP-Systemdiagnose.

  3. Wenn Sie eine Legacy-HTTP-Systemdiagnose mit einem Zielpool verknüpfen möchten, verwenden Sie den API-Aufruf targetPools.addHealthCheck.

Status der Systemdiagnose prüfen

Nachdem Sie eine Systemdiagnose mit einem Back-End-Dienst oder einem Zielpool verknüpft haben, können Sie den sofortigen Status der Systemdiagnose für die Back-Ends des Load-Balancers abrufen.

Console

  1. Wechseln Sie zur Seite der Load-Balancing-Zusammenfassung.
    Zur Seite "Load-Balancing"
  2. Klicken Sie auf den Namen eines Load-Balancers.
  3. Prüfen Sie unter Back-End die Spalte Fehlerfrei. Der Systemstatus wird für jede Back-End-Instanzgruppe oder Netzwerk-Endpunktgruppe gemeldet.

gcloud

  • Bestimmen Sie für alle Load-Balancer mit Ausnahme von poolbasierten externen Passthrough-Network Load Balancern den Namen und den Bereich (global oder regional) des Backend-Dienstes. Eine vollständige Liste der Load Balancer und Bereiche finden Sie unter Backend-Dienste.

    Verwenden Sie den Befehl compute backend-services get-health. Ersetzen Sie dabei NAME durch den Namen des Backend-Dienstes und bei Bedarf REGION durch die Region.

    • So rufen Sie den sofortigen Systemzustand eines globalen Back-End-Dienstes ab:

      gcloud compute backend-services get-health GLOBAL_BACKEND_SERVICE_NAME \
    --global

    • So rufen Sie den sofortigen Systemzustand eines regionalen Backend-Dienstes ab:

      gcloud compute backend-services get-health REGIONAL_BACKEND_SERVICE_NAME \
    --region=REGION

  • Identifizieren Sie für zielpoolbasierte externe Passthrough-Network Load Balancer den Namen und die Region des Zielpools des Load Balancers und verwenden Sie dann den Befehl compute target-pools get-health. Ersetzen Sie dabei NAME durch den Namen des Zielpools und REGION durch seine Region.

    gcloud compute target-pools get-health TARGET_POOL_NAME \
    --region=REGION

API

  • Bestimmen Sie für alle Load-Balancer mit Ausnahme von poolbasierten externen Passthrough-Network Load Balancern den Namen und den Bereich (global oder regional) des Backend-Dienstes. Eine vollständige Liste der Load Balancer und Bereiche finden Sie unter Backend-Dienste.

  • Verwenden Sie für zielpoolbasierte externe Passthrough-Network Load Balancer targetPools.getHealth.