Systemdiagnosen erstellen

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 Traffic Director erstellt und verwendet werden.

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

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 zielpoolbasierte Netzwerk-Load-Balancing müssen jedoch Legacy-Systemdiagnosen verwendet werden. Informationen zur Bestimmung der entsprechenden Kategorie, des Protokolls und der Portspezifikationsmethode finden Sie auf der Seite Übersicht über Systemdiagnosen unter Systemdiagnose auswählen.

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

  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 diese API-Aufrufe, um die aktuelle Konfiguration einer Systemdiagnose zu beschreiben:

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.

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 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: 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, Zusätzliche Flags für SSL- und TCP-Systemdiagnosen oder Zusätzliches Flag für gRPC-Systemdiagnosen.

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

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
Netzwerk-Load-Balancing Instanzgruppen • --port: Geben Sie einen TCP-Port nach Nummer an, von 1 bis 65535
Das Flag --use-serving-port wird für eine mit einem Netzwerk-Load-Balancer verknüpfte Systemdiagnose ignoriert, da Back-End-Dienste für Netzwerk-Load-Balancer keine Portspezifikation haben.
Internes TCP/UDP-Load-Balancing Instanzgruppen • --port: Geben Sie einen TCP-Port nach Nummer an, von 1 bis 65535
Das Flag --use-serving-port wird für eine mit einem internen TCP/UDP-Load-Balancer verknüpfte Systemdiagnose ignoriert, da Back-End-Dienste für interne TCP/UDP-Load-Balancer keine Portspezifikation haben.
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, 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.

Alte Systemdiagnosen

In diesem Abschnitt wird beschrieben, wie Sie Legacy-HTTP-Systemdiagnosen und Legacy-HTTPS-Systemdiagnosen auflisten, erstellen und ändern.

Wenn die Antwort der Legacy-Systemdiagnose-Prüfung HTTP 200 OK lautet, gilt die Prüfung als erfolgreich. Alle anderen HTTP-Antwortcodes, einschließlich der Weiterleitung (301, 302), gelten als fehlerhaft.

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:

  2. So beschreiben Sie eine Legacy-Systemdiagnose:

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 zielpoolbasierten 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

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.

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

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

Im folgenden Beispiel wird eine Firewallregel für eingehenden Traffic für das Netzwerk-Load-Balancing erstellt. Die Quell-IP-Bereiche für das Netzwerk-Load-Balancing lauten:

  • 35.191.0.0/16
  • 209.85.152.0/22
  • 209.85.204.0/22

Diese Bereiche gelten für beide Arten von Netzwerk-Load-Balancern: zielpoolbasierte Netzwerk-Load-Balancer die Legacy-Systemdiagnosen verwenden und Back-End-Dienst- und Netzwerk-Load-Balancer die Nicht-Legacy-Systemdiagnosen verwenden.

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 verknüpfen

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

Übereinstimmung mit dem Protokoll

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.

  • Für einen pool-basierten Netzwerk-Load-Balancer muss eine Legacy-HTTP-Systemdiagnose verwendet werden. Es kann keine Legacy-HTTPS-Systemdiagnose oder irgendeine Nicht-Legacy-Systemdiagnosen verwendet werden. Wenn Sie einen Zielpool-basierten Netzwerk-Load-Balancer zum Ausgleich von TCP-Traffic verwenden, müssen Sie einen HTTP-Dienst auf den VMs ausführen, für die das Load-Balancing erfolgt, damit diese auf Systemdiagnosetests reagieren können.

    Ein auf dem Back-End-Dienst basierender Netzwerk-Load-Balancer kann Nicht-Legacy-Systemdiagnosen verwenden. Sie können also eine Systemdiagnose verwenden, deren Protokoll dem Protokoll entspricht, das vom Back-End-Dienst des Netzwerk-Load-Balancers verwendet wird.

  • 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
  • Back-End-Dienst-basiertes Netzwerk-Load-Balancing

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

Informationen zum Verknüpfen einer Systemdiagnose mit einem neuen internen TCP/UDP-Load-Balancer, einem TCP-Proxy-Load-Balancer, einem SSL-Proxy-Load-Balancer, einem externen HTTP(S)-Load-Balancer oder einem Back-End-basierten Netzwerk-Load-Balancer finden Sie in dem Einrichtungsleitfaden für den entsprechenden 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, einem externen HTTP(S)-Load-Balancer oder einem Back-End-basierten Netzwerk-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. Netzwerk-Load-Balancer, interner TCP/UDP-Load-Balancer, TCP-Proxy-Load-Balancer und SSL-Proxy-Load-Balancer haben nur einen Back-End-Dienst pro Load-Balancer. Die externen und internen HTTP(S)-Load-Balancer haben mindestens einen Back-End-Dienst, der einer einzelnen URL-Zuordnung zugeordnet ist.

    • 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 \
    --filter="region:( REGION1 REGION2 ... ) AND loadBalancingScheme=INTERNAL"

    • Führen Sie den folgenden Befehl aus, um Back-End-Dienste für Netzwerk-Load-Balancer aufzulisten. Ersetzen Sie dabei jede REGION durch die Google Cloud-Region, die abgefragt werden soll.

      gcloud compute backend-services list \
    --filter="region:( REGION1 REGION2 ... ) AND loadBalancingScheme=EXTERNAL"

    • 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 regionale Systemdiagnose. Wenn Sie eine globale Systemdiagnose mit Ihrem internen TCP/UDP-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 Back-End-Dienst-basierten Netzwerk-Load-Balancers: Der Back-End-Dienst eines Netzwerk-Load-Balancers 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 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:

Legacy-Systemdiagnosen für zielpoolbasiertes 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:

Informationen zum Verknüpfen einer Legacy-Systemdiagnose mit einem neuen Netzwerk-Load-Balancer finden Sie unter Netzwerk-Load-Balancing mit einem Zielpool einrichten. Sie müssen beim Erstellen eines Netzwerk-Load-Balancers eine Legacy-Systemdiagnose mit seinem Zielpool verknüpfen.

Console

So verknüpfen Sie eine Systemdiagnose mit einem vorhandenen zielpoolbasierten 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 zielpoolbasierten Netzwerk-Load-Balancer:

  1. Ermitteln Sie den Zielpool bzw. die Zielpools. Ein Netzwerk-Load-Balancer hat 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 mit Ausnahme von pool-basierten Netzwerk-Load-Balancer den Namen und den Umfang des Back-End-Dienstes. Back-End-Dienst-basiertes Netzwerk-Load-Balancing, internes TCP/UDP-Load-Balancing und internes HTTP(S)-Load-Balancing verwenden regionale Back-End-Dienste. TCP-Proxy-Load-Balancing, SSL-Proxy-Load-Balancing und HTTP(S)-Load-Balancing 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)

  • Identifizieren Sie für zielpoolbasierte Netzwerk-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 NAME \
        --region=REGION \
    --format=get(name, healthStatus)

API

  • Bestimmen Sie für alle Load-Balancer mit Ausnahme von pool-basierten Netzwerk-Load-Balancern den Namen und den Umfang des Back-End-Dienstes. Back-End-Dienst-basiertes Netzwerk-Load-Balancing, internes TCP/UDP-Load-Balancing und internes HTTP(S)-Load-Balancing verwenden regionale Back-End-Dienste. TCP-Proxy-Load-Balancing, SSL-Proxy-Load-Balancing und HTTP(S)-Load-Balancing verwenden globale Back-End-Dienste.

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