Systemdiagnosen erstellen

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

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

• Google Cloud-Firewallregeln
• Übersicht über Systemdiagnosen
• Übersicht über Back-End-Dienste

Hinweis: Auf dieser Seite wird beschrieben, wie Sie eine bestimmte Load-Balancer-Komponente vor oder nach dem Erstellen eines Load-Balancers erstellen. Die Arbeit mit bestimmten Komponenten ist für erweiterte Konfigurationen nützlich und für einige Konfigurationsoptionen erforderlich. Bevor Sie die Informationen auf dieser Seite nutzen, müssen Sie den erforderlichen Typ des Google Cloud-Load-Balancers kennen. Für einen schnellen Einstieg in Ihre Load-Balancer-Konfiguration sollten Sie einem End-to-End-Konfigurationsbeispiel folgen.

Kategorien, Protokolle und Ports der Systemdiagnose

Google Cloud organisiert Systemdiagnosen nach Kategorie und Protokoll.

Es gibt zwei Systemdiagnose-Kategorien: Systemdiagnosen und Legacy-Systemdiagnosen. Jede Kategorie unterstützt einen anderen Satz von Protokollen und eine Methode zur Angabe des Ports, der für die Systemdiagnose verwendet wird.

Traffic Director und die meisten Load-Balancer verwenden Nicht-Legacy-Systemdiagnosen, für das Netzwerk-Load-Balancing ist jedoch die Verwendung von Legacy-Systemdiagnosen erforderlich. Weitere Informationen zur Bestimmung der entsprechenden Kategorie, des Protokolls und der Portspezifikationsmethode finden Sie unter Auswählen einer Systemdiagnose auf der Seite Systemdiagnose.

Das Protokoll, das Sie für eine Systemdiagnose auswählen, muss nicht mit dem Protokoll übereinstimmen, das vom Load-Balancer verwendet wird, in einigen Fällen ist dies sogar nicht möglich. Weitere Informationen finden Sie unter Protokolle und Load-Balancer.

Der Begriff "Systemdiagnose" bezieht sich nicht auf Legacy-Systemdiagnosen, die in diesem Dokument explizit als "Legacy-Systemdiagnosen" bezeichnet werden.

Systemdiagnosen auflisten

Console

Hinweis: Auf der Seite "Systemdiagnosen" der Cloud Console werden sowohl Systemdiagnosen als auch Legacy-Systemdiagnosen aufgeführt.

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:

• So listen Sie globale Systemdiagnosen auf: healthChecks.list

• So listen Sie regionale Systemdiagnosen auf: regionHealthChecks.list

Verwenden Sie diese API-Aufrufe, um die aktuelle Konfiguration einer Systemdiagnose zu beschreiben:

• So beschreiben Sie eine globale Systemdiagnose: healthChecks.get

• So beschreiben Sie eine regionale Systemdiagnose: regionHealthChecks.get

Systemdiagnosen erstellen

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

Sie können auch unabhängig von der Load-Balancer-Konfiguration eine Systemdiagnose 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 Cloud Console, mit dem gcloud-Befehlszeilentool oder den REST APIs erstellen.

Hinweis: Sie müssen Legacy-HTTP-Systemdiagnosen für Netzwerk-Load-Balancer verwenden. Sie können eine Legacy-Systemdiagnose auswählen oder erstellen, wenn Sie die Konfiguration des Netzwerk-Load-Balancers in der Cloud Console abschließen. Anstelle dieses Abschnitts finden Sie weitere Informationen unter 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.
   • Protokoll: Wählen Sie ein Protokoll für die Systemdiagnose aus.
   • Port: Geben Sie eine Portnummer an. Wenn Sie eine Systemdiagnose in der 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
  

Dabei gilt:

• protocol definiert das für die Systemdiagnose verwendete Protokoll. Gültige Optionen sind 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: Alle Load-Balancer mit Ausnahme von internen HTTP(S)-Load-Balancern verwenden globale Systemdiagnosen (--global). Interne HTTP(S)-Load-Balancer verwenden regionale Systemdiagnosen, deren Region mit der Region des Back-End-Dienstes übereinstimmen muss.
• 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 Einheiten 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 oder Zusätzliche Flags für SSL- und TCP-Systemdiagnosen.

API

• Verwenden Sie zum Erstellen einer globalen Systemdiagnose healthChecks.insert.

• Verwenden Sie zum Erstellen einer globalen Systemdiagnose regionHealthChecks.insert.

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 optionalen 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 optionalen Flags ändern. Verwenden Sie patch-API-Aufrufe, um alle vorkonfigurierten Einstellungen beizubehalten, die nicht explizit in der Anfrage festgelegt wurden.

   • Verwenden Sie zum Ändern einer globalen Systemdiagnose entweder healthChecks.update oder healthChecks.patch.

   • Verwenden Sie zum Ändern einer regionalen Systemdiagnose entweder regionHealthChecks.update oder regionHealthChecks.patch.

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 dem gcloud-Befehlszeilentool 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, verwaltete zonale Instanzgruppen oder verwaltete regionale Instanzgruppen.

Jede Systemdiagnose kann nur einen Typ von Portspezifikation verwenden.

Produkt	Back-End-Typ	Optionen für die Portspezifikation
Internes TCP/UDP-Load-Balancing	Instanzgruppen	• --port: Geben Sie einen TCP-Port als Zahl an, von 1 bis 65535. Sie können das Flag --use-serving-port nicht für eine Systemdiagnose verwenden, die mit einem internen TCP/UDP-Load-Balancer verknüpft ist, da für Back-End-Dienste für interne TCP/UDP-Load-Balancer keine Portspezifikation vorhanden ist.
Internes HTTP(S) Load Balancing TCP Proxy Load Balancing SSL Proxy Load Balancing Externes HTTP(S) Load Balancing Traffic Director	Zonale 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 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, ist kein impliziter Standardwert vorhanden. müssen Sie 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 eine HealthCheckRequest-Nachricht an Ihre Back-Ends, indem Sie die Methode Check des Systemdiagnosedienstes in Ihrem Back-End aufrufen. Der Dienstparameter in der Anfrage wird auf einen leeren String gesetzt, wenn 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

Zum Beispiel könnten Sie die folgenden Dienste und Status haben, die sich vom Back-End-Server beim gRPC-Healthcare-Dienst des Back-Ends registrieren.

• 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 wie folgt erstellen, gibt die Systemdiagnose 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 der Systemdiagnosetest UNHEALTHY zurück, da der Dienststatus NOT_SERVING lautet.

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

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

Alte Systemdiagnosen

In diesem Abschnitt wird beschrieben, wie Sie Legacy-HTTP-Systemdiagnosen und Legacy-HTTPS-Systemdiagnosen auflisten, erstellen und ändern. Beachten Sie, dass ein Netzwerk-Load-Balancer nur eine Legacy-HTTP-Systemdiagnose verwenden kann, keine Legacy-HTTPS-Systemdiagnose.

Hinweis: Das Netzwerk-Load-Balancing greift auf Legacy-HTTP-Systemdiagnosen zurück, um den Status der Instanzen im Zielpool zu ermitteln. Ein Netzwerk-Load-Balancer kann nur eine Legacy-HTTP-Systemdiagnose verwenden, keine Legacy-HTTPS-Systemdiagnose.

Legacy-Systemdiagnosen 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:

   • Verwenden Sie httpHealthChecks.list, um Legacy-HTTP-Systemdiagnosen aufzulisten.

   • Verwenden Sie httpsHealthChecks.list, um Legacy-HTTPS-Systemdiagnosen aufzulisten.

2. So beschreiben Sie eine Legacy-Systemdiagnose:

   • Verwenden Sie httpHealthChecks.get, um die Legacy-HTTP-Systemdiagnose zu beschreiben.

   • Verwenden Sie httpsHealthChecks.get, um die Legacy-HTTPS-Systemdiagnose zu beschreiben.

Legacy-Systemdiagnosen erstellen

Console

Obwohl auf der Seite der Systemdiagnosen der 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 Cloud Console keine neue Legacy-Systemdiagnose erstellen.

Verwenden Sie zum Erstellen einer Legacy-Systemdiagnose die Seite "Netzwerk-Load-Balancer" der Cloud Console oder 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

Dabei gilt:

• 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 Netzwerk-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 anzugeben. 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

• Verwenden Sie zum Erstellen einer Legacy-HTTP-Systemdiagnose den API-Aufruf httpHealthChecks.insert.

• Verwenden Sie zum Erstellen einer Legacy-HTTPS-Systemdiagnose httpsHealthChecks.insert.

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.

• Verwenden Sie zum Ändern einer Legacy-HTTP-Systemdiagnose entweder httpHealthChecks.update oder httpHealthChecks.patch.

• Verwenden Sie zum Ändern einer Legacy-HTTPS-Systemdiagnose entweder httpsHealthChecks.update oder httpsHealthChecks.patch.

Erforderliche Firewallregeln

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. In den folgenden Beispielen werden Firewallregeln erstellt, die auf VM-Instanzen nach Zieltag anwendbar sind. Weitere Informationen zur Angabe von Zielen für Firewallregeln finden Sie in der Erläuterung der Ziele in der Übersicht über Firewallregeln und unter Netzwerk-Tags konfigurieren.

Jedes dieser Beispiele lässt den gesamten TCP-Traffic von Google Cloud-Systemdiagnosen zu Ihren VM-Instanzen zu. (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.

Firewallregeln für Systemdiagnosen

Das folgende Beispiel erstellt eine Firewallregel für eingehenden Traffic für nachstehende Load-Balancer:

• Internes TCP/UDP-Load-Balancing (Systemdiagnosen)
• Internes HTTP(S)-Load-Balancing (Systemdiagnosen)
• TCP-Proxy-Load-Balancing (Systemdiagnosen)
• SSL-Proxy-Load-Balancing (Systemdiagnosen)
• HTTP(S)-Load-Balancing (Systemdiagnosen und Legacy-Systemdiagnosen)

Für diese Load-Balancer lauten die Quell-IP-Bereiche der Systemdiagnosen (einschließlich der Legacy-Systemdiagnosen, falls beim HTTP(S)-Load-Balancing verwendet):

• 35.191.0.0/16
• 130.211.0.0/22

Nur beim internen HTTP(S)-Load-Balancing umfasst der Quell-IP-Bereich alle IP-Adressen im Nur-Proxysubnetz.

Sollten Sie Regeln für Netzwerk-Load-Balancing erstellen müssen, finden Sie weitere Informationen dazu im nächsten Abschnitt Regeln für Netzwerk-Load-Balancing.

Console

1. Rufen Sie in der Google Cloud Console die Seite "Firewallregeln" auf.
   Zur Seite "Firewall"
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 Textfeld Ziel-Tags ein. Verwenden Sie für dieses Beispiel allow-health-checks.
   • Quellfilter: Wählen Sie IP-Bereiche aus.
   • Quell-IP-Bereiche: 35.191.0.0/16,130.211.0.0/22.
   • Zulässige Protokolle und Ports: Verwenden Sie tcp. TCP ist das zugrunde liegende Protokoll für alle Systemdiagnose-Protokolle.
   • Klicken Sie auf Erstellen.
4. Fügen Sie das Netzwerktag 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. Ersetzen Sie network-name durch den Namen Ihres VPC-Netzwerks.

   gcloud compute firewall-rules create fw-allow-health-checks \
       --network=network-name \
       --action=ALLOW \
       --direction=INGRESS \
       --source-ranges=35.191.0.0/16,130.211.0.0/22 \
       --target-tags=allow-health-checks \
       --rules=tcp

2. Fügen Sie das Netzwerktag 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.

Regeln für Netzwerk-Load-Balancing

Das folgende Beispiel erstellt eine Firewallregel für eingehenden Traffic für das Netzwerk-Load-Balancing, wofür eine Legacy-Systemdiagnose benötigt wird. Die Quell-IP-Bereiche der Legacy-Systemdiagnosen für das Netzwerk-Load-Balancing lauten:

• 35.191.0.0/16
• 209.85.152.0/22

• 209.85.204.0/22

Console

1. Rufen Sie in der Google Cloud Console die Seite "Firewallregeln" auf.
   Zur Seite "Firewall"
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-network-lb-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 Textfeld Ziel-Tags ein. Verwenden Sie für dieses Beispiel allow-network-lb-health-checks.
   • Quellfilter: Wählen Sie IP-Bereiche aus.
   • Quell-IP-Bereiche: 35.191.0.0/16, 209.85.152.0/22, 209.85.204.0/22.
   • Zulässige Protokolle und Ports: Verwenden Sie tcp. TCP ist das zugrunde liegende Protokoll für HTTP und HTTPS.
   • Klicken Sie auf Erstellen.
4. Fügen Sie das Netzwerktag 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-network-lb-health-checks für das Netzwerk-Tag verwendet.

gcloud

1. Erstellen Sie mit dem folgenden gcloud-Befehl eine Firewallregel namens fw-allow-network-lb-health-checks, die eingehende TCP-Verbindungen von Google Cloud-Systemdiagnosen zu Instanzen in Ihrem VPC-Netzwerk mit dem Tag allow-network-lb-health-checks zulässt. Ersetzen Sie network-name durch den Namen Ihres VPC-Netzwerks.

   gcloud compute firewall-rules create fw-allow-network-lb-health-checks \
       --network=network-name \
       --action=ALLOW \
       --direction=INGRESS \
       --source-ranges=35.191.0.0/16,209.85.152.0/22,209.85.204.0/22 \
       --target-tags=allow-network-lb-health-checks \
       --rules=tcp

2. Fügen Sie das Netzwerktag 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-network-lb-health-checks für das Netzwerk-Tag verwendet.

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

Systemdiagnosen mit Load-Balancern und Traffic Director zuordnen

In diesem Abschnitt werden bestimmte Empfehlungen für Systemdiagnosen und die Anforderungen beschrieben, die erfüllt sein müssen, bevor eine Systemdiagnose einem Load-Balancer oder Traffic Director zugeordnet wird.

Protokollieren

Es empfiehlt sich, eine Systemdiagnose (oder Legacy-Systemdiagnose) zu verwenden, deren Protokoll dem Protokoll entspricht, das vom Back-End-Dienst oder Zielpool des Load-Balancers verwendet wird. Die Protokolle der Systemdiagnose und des Load-Balancers müssen jedoch nicht identisch sein. Beispiele:

• Beim internen TCP/UDP-Load-Balancing können Sie für das Protokoll des Back-End-Dienstes nur TCP oder UDP verwenden. Wenn Sie HTTP-Traffic von VMs hinter einem internen TCP/UDP-Load-Balancer weiterleiten, ist es sinnvoll, eine Systemdiagnose mithilfe des HTTP-Protokolls durchzuführen.

• Ein Netzwerk-Load-Balancer muss eine Legacy-HTTP-Systemdiagnose verwenden. Er kann keine Legacy-HTTPS-Systemdiagnose oder eine moderne Systemdiagnose verwenden. Wenn Sie einen Netzwerk-Load-Balancer verwenden, um TCP-Traffic auszugleichen, müssen Sie einen HTTP-Dienst auf den VMs ausführen, für die das Load-Balancing gilt, damit diese auf Systemdiagnosetests reagieren können.

• Verwenden Sie für Back-End-Dienste, die das gRPC-Protokoll verwenden, nur gRPC- oder TCP-Systemdiagnosen. Verwenden Sie keine HTTP(S) - oder HTTP/2-Systemdiagnosen.

Systemdiagnosen für Back-End-Dienste

In diesem Abschnitt wird die Verknüpfung einer Systemdiagnose mit einem Back-End-Dienst folgender Typen von Load-Balancern beschrieben:

• Internes TCP/UDP-Load-Balancing
• Internes HTTP(S)-Load-Balancing
• TCP-Proxy-Load-Balancing
• SSL-Proxy-Load-Balancing
• HTTP(S)-Load-Balancing

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

• Einen internen TCP/UDP-Load-Balancer, einen TCP-Proxy-Load-Balancer, einen SSL-Proxy-Load-Balancer oder einen externen HTTP(S)-Load-Balancer erstellt.
• Eine Systemdiagnose erstellt
• Die Firewallregeln für Systemdiagnosen konfiguriert

Informationen zum Zuordnen einer Systemdiagnose zu einem neuen internen TCP/UDP-Load-Balancer, TCP-Proxy-Load-Balancer, SSL-Proxy-Load-Balancer oder zu einem externen HTTP(S)-Load-Balancer finden Sie in der Einrichtungsanleitung für den jeweiligen Load-Balancer.

Console

So verknüpfen Sie eine Systemdiagnose mit einem vorhandenen internen TCP/UDP-Load-Balancer, TCP-Proxy-Load-Balancer, SSL-Proxy-Load-Balancer oder mit einem externen HTTP(S)-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 Back-End-Dienstes. Interne TCP/UDP-Load-Balancer, TCP-Proxy-Load-Balancer und SSL-Proxy-Load-Balancer haben nur ein Back-End pro Load-Balancer. Externe HTTP(S)-Load-Balancer und internen HTTP(S)-Load-Balancer haben einen oder mehrere Back-End-Dienste, die mit einer einzelnen URL-Zuordnung verknüpft sind.

   • Führen Sie den folgenden Befehl aus, um Back-End-Dienste für interne TCP/UDP-Load-Balancer aufzulisten. Ersetzen Sie dabei region-list durch eine durch Kommas getrennte Liste der abzufragenden Google Cloud-Regionen.

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

   • Führen Sie den folgenden Befehl aus, um Back-End-Dienste für TCP-Proxy-Load-Balancer aufzulisten. Back-End-Dienste für TCP-Proxy-Load-Balancer sind immer global, unabhängig von der Netzwerkdienststufe.

     gcloud compute backend-services list \
         --global \
         --filter="loadBalancingScheme=EXTERNAL" \
         --filter="protocol=TCP"
     

   • Führen Sie den folgenden Befehl aus, um Back-End-Dienste für SSL-Proxy-Load-Balancer aufzulisten. Back-End-Dienste für SSL-Proxy-Load-Balancer sind immer global, unabhängig von der Netzwerkdienststufe.

     gcloud compute backend-services list \
         --global \
         --filter="loadBalancingScheme=EXTERNAL" \
         --filter="protocol=SSL"
     

   • Zum Identifizieren von Back-End-Diensten für einen externen HTTP(S)-Load-Balancer ermitteln Sie zuerst eine URL-Zuordnung und beschreiben diese anschließend. URL-Zuordnungen und Back-End-Dienste für externe HTTP(S)-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 Back-End-Diensten für einen internen HTTP(S)-Load-Balancer ermitteln Sie zuerst eine URL-Zuordnung und beschreiben diese anschließend. URL-Zuordnungen und Back-End-Dienste für interne HTTP(S)-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 Back-End-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 Back-End-Dienstes, health-check-name durch den Namen der Systemdiagnose und gegebenenfalls region durch die Google Cloud-Region des Back-End-Dienstes, den Status oder beide.

   • So ändern Sie die Systemdiagnose eines internen TCP/UDP-Load-Balancers: Der Back-End-Dienst eines internen TCP/UDP-Load-Balancers ist regional. Er kann auf eine globale oder regionale Systemdiagnose verweisen. Das folgende Beispiel zeigt eine Referenz zur regionalen Systemdiagnose. Wenn Sie für Ihren internen TCP/UDP-Load-Balancer eine globale Systemdiagnose 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 für einen TCP-Proxy-Load-Balancer, einen SSL-Proxy-Load-Balancer oder einen externen HTTP(S)-Load-Balancer: Sowohl der Back-End-Dienst als auch die Systemdiagnose sind für diese Load-Balancer global. Ein externer HTTP(S)-Load-Balancer kann auf mehrere Systemdiagnosen verweisen, wenn er auf mehr als einen Back-End-Dienst verweist.

     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 internen HTTP(S)-Load-Balancer: Sowohl der Back-End-Dienst als auch die Systemdiagnose sind regional. Ein interner HTTP(S)-Load-Balancer kann auf mehrere Systemdiagnosen verweisen, wenn er auf mehr als einen Back-End-Dienst verweist.

     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. Systemdiagnosen aufrufen

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

   • backendServices.update
   • backendServices.patch

Legacy-Systemdiagnosen für Netzwerk-Load-Balancing

In diesem Abschnitt wird beschrieben, wie Sie für das Netzwerk-Load-Balancing eine Legacy-Systemdiagnose mit einem Zielpool verknüpfen. Folgende Voraussetzungen sollten für diesen Abschnitt erfüllt sein. Sie haben:

• Einen Netzwerk-Load-Balancer erstellt
• Eine Legacy-Systemdiagnose erstellt
• Die Firewallregeln für das Netzwerk-Load-Balancing konfiguriert

Informationen zum Verknüpfen einer Legacy-Systemdiagnose mit einem neuen Netzwerk-Load-Balancer finden Sie unter Netzwerk-Load-Balancing einrichten. Wenn Sie einen neuen Netzwerk-Load-Balancer erstellen, müssen Sie eine Legacy-Systemdiagnose mit seinem Zielpool verknüpfen.

Console

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

1. Öffnen Sie in der Google Cloud Console die Seite "Load-Balancing".
   Zur Seite "Load-Balancing"
2. Klicken Sie auf einen Netzwerk-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 Netzwerk-Load-Balancer:

1. Ermitteln Sie die Zielpools. Netzwerk-Load-Balancer haben mindestens einen Zielpool und möglicherweise einen sekundären Sicherungspool.

   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

• Identifizieren Sie für alle Load-Balancer außer Netzwerk-Load-Balancer den Namen und den Bereich des Back-End-Dienstes. Interne TCP/UDP-Load-Balancer und interne HTTP(S)-Load-Balancer verwenden regionale Back-End-Dienste. TCP-Proxy-Load-Balancer, SSL-Proxy-Load-Balancer und externe HTTP(S)-Load-Balancer verwenden globale Back-End-Dienste.

  Verwenden Sie den Befehl compute backend-services get-health. Ersetzen Sie dabei name durch den Namen des Back-End-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 name \
        --global \
        --format=get(name, healthStatus)
    

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

    gcloud compute backend-services get-health name \
        --region=region \
        --format=get(name, healthStatus)
    

• Ermitteln Sie bei Netzwerk-Load-Balancern den Namen und die Region des Load-Balancer-Zielpools und verwenden Sie dann den Befehl compute target-pools get-health. Ersetzen Sie dabei name durch den Namen des Zielpools und region durch die Region.

  gcloud compute target-pools get-health name \
          --region=region \
      --format=get(name, healthStatus)
  

API

• Identifizieren Sie für alle Load-Balancer außer Netzwerk-Load-Balancer den Namen und den Bereich des Back-End-Dienstes. Interne TCP/UDP-Load-Balancer und interne HTTP(S)-Load-Balancer verwenden regionale Back-End-Dienste. TCP-Proxy-Load-Balancer, SSL-Proxy-Load-Balancer und externe HTTP(S)-Load-Balancer verwenden globale Back-End-Dienste.

  • Mit backendServices.getHealth können Sie den sofortigen Systemzustand eines globalen Back-End-Dienstes ermitteln.

  • Mit regionBackendServices.getHealth können Sie den sofortigen Systemzustand eines regionalen Back-End-Dienstes ermitteln.

• Verwenden Sie für Netzwerk-Load-Balancer targetPools.getHealth.