Systemdiagnosen – Übersicht

Cloud de Confiance by S3NS bietet konfigurierbare Systemdiagnosen für Cloud de Confiance Load-Balancer-Back-Ends und anwendungsbasierte automatische Reparatur für verwaltete Instanzgruppen. In diesem Dokument werden wichtige Konzepte der Systemdiagnose behandelt.

Sofern nicht anders angegeben, werden Cloud de Confiance Systemdiagnosen durch dedizierte Softwareaufgaben implementiert, die gemäß den in einer Systemdiagnoseressource angegebenen Parametern eine Verbindung zu Back-Ends herstellen. Jeder Verbindungsversuch wird als Prüfung bezeichnet. Cloud de Confiance zeichnet den Erfolg oder Misserfolg jeder Prüfung auf.

Anhand einer konfigurierbaren Anzahl von sequenziellen erfolgreichen oder fehlgeschlagenen Prüfungen wird für jedes Back-End ein Gesamtsystemzustand berechnet. Back-Ends, die bei der konfigurierten Anzahl von Durchläufen erfolgreich reagieren, werden als fehlerfrei betrachtet. Back-Ends, die bei der konfigurierten Anzahl von Durchläufen nicht erfolgreich reagieren, sind fehlerhaft.

Der Gesamtsystemzustand jedes Back-Ends bestimmt, ob es berechtigt ist, neue Anfragen zu erhalten. Sie können die Kriterien konfigurieren, die eine erfolgreiche Prüfung definieren. Dies wird unter Funktionsweise von Systemdiagnosen ausführlich erläutert.

Systemdiagnosen, die durch dedizierte Softwareaufgaben implementiert werden, verwenden spezielle Routen, die nicht in Ihrem Virtual Private Cloud-Netzwerk (VPC) definiert sind. Weitere Informationen finden Sie unter Pfade für Systemdiagnosen.

Kategorien, Protokolle und Ports der Systemdiagnose

Systemdiagnosen haben eine Kategorie und ein Protokoll. Die beiden Kategorien sind Systemdiagnosen und Legacy-Systemdiagnosen sowie die folgenden unterstützten Protokolle:

• Systemdiagnosen

  • Regional (gRPC, TCP, SSL, HTTP, HTTPS oder HTTP/2)
  • Regionales gRPC (mit TLS) (Vorschau)
  • Global (gRPC, TCP, SSL, HTTP, HTTPS oder HTTP/2)
  • Globales gRPC (mit TLS) (Vorschau)

• Legacy-Systemdiagnosen:

  • Legacy global (HTTP)

Das Protokoll und der Port legen fest, wie die Systemdiagnoseprüfungen durchgeführt werden. Eine Systemdiagnose kann beispielsweise das HTTP-Protokoll an TCP-Port 80 oder das TCP-Protokoll für einen benannten Port in einer Instanzgruppe verwenden.

Sie können eine Legacy-Systemdiagnose nicht in eine Systemdiagnose und eine Systemdiagnose nicht in eine Legacy-Systemdiagnose konvertieren.

Systemdiagnose auswählen

Systemdiagnosen müssen mit dem Typ des Load-Balancers und den Back-End-Typen kompatibel sein. Bei der Auswahl einer Systemdiagnose müssen folgende Faktoren berücksichtigt werden:

• Kategorie: Systemdiagnose oder Legacy-Systemdiagnose Nur für zielpoolbasierte externe Passthrough-Network Load Balancer sind Legacy-Systemdiagnosen erforderlich. Für alle anderen Produkte verwenden Sie reguläre Systemdiagnosen.
• Protokoll:Protokoll, mit dem Cloud de Confiance die Back-Ends prüft. 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.
• Portspezifikation:Ports, die Cloud de Confiance mit dem Protokoll verwendet. Sie müssen einen Port für die Systemdiagnose angeben. Systemdiagnosen haben zwei Methoden zur Portspezifikation: --port und --use-serving-port. Für Legacy-Systemdiagnosen gibt es eine Methode: --port. Weitere Informationen zu den Anforderungen an den Systemdiagnoseport pro Load-Balancer finden Sie unter Flags für die Portspezifikation.

Im nächsten Abschnitt werden die gültigen Auswahlmöglichkeiten für Systemdiagnosen für jeden Load-Balancer- und Backend-Typ beschrieben.

Load-Balancer-Anleitung

Diese Tabelle enthält die unterstützte Systemdiagnosekategorie und den Bereich für jeden Load-Balancer-Typ.

Load-Balancer	Kategorie und Bereich der Systemdiagnose
Regionaler externer Application Load Balancer Regionaler interner Application Load Balancer Regionaler interner Proxy-Network Load Balancer Regionaler externer Proxy-Network Load Balancer	Systemdiagnose (regional)
Externer Passthrough-Network Load Balancer	Backend-Dienst-basierter Load Balancer: Systemdiagnose (regional) Zielpool-basierter Load Balancer: Legacy-Systemdiagnose (global mit dem HTTP-Protokoll)
Interner Passthrough-Network-Load-Balancer	Systemdiagnose (global oder regional)

Weitere Nutzungshinweise

• Bei Back-Ends von VM-Instanzgruppen werden Systemdiagnosen nur für gestartete VM-Instanzen ausgeführt. Angehaltene VM-Instanzen empfangen keine Systemdiagnosepakete.

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

• Für einen zielpoolbasierten externen Passthrough-Network 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 externen Passthrough-Network 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.
  
  Für fast alle anderen Load-Balancer-Typen müssen Sie reguläre Nicht-Legacy-Systemdiagnosen verwenden, bei denen das Protokoll mit dem Backend-Dienst-Protokoll des Load-Balancers übereinstimmt.

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

• Bestimmte Envoy-basierte Load Balancer, die Hybrid-NEG-Backends verwenden, unterstützen keine gRPC-Systemdiagnosen. Weitere Informationen finden Sie in der Übersicht zu Hybrid-NEGs.

Funktionsweise von Systemdiagnosen

In den folgenden Abschnitten wird beschrieben, wie Systemdiagnosen funktionieren.

Prüfungen

Wenn Sie eine Systemdiagnose oder Legacy-Systemdiagnose erstellen, legen Sie die folgenden Flags fest oder akzeptieren deren Standardwerte. Jede von Ihnen erstellte Systemdiagnose oder Legacy-Systemdiagnose wird von mehreren Prüfungen implementiert. Diese Flags steuern, wie häufig jede Prüfung Instanzen in Instanzgruppen oder Endpunkte in zonalen NEGs auswertet.

Die Einstellungen einer Systemdiagnose können nicht pro Back-End konfiguriert werden. Systemdiagnosen sind mit einem gesamten Backend-Dienst verknüpft. Bei einem zielpoolbasierten externen Passthrough-Netzwerk-Load-Balancer wird eine Legacy-HTTP-Systemdiagnose mit dem gesamten Zielpool verknüpft. Daher sind die Parameter für die Prüfung für alle Backends, auf die von einem bestimmten Backend-Dienst oder Zielpool verwiesen wird, gleich.

Konfigurations-Flag	Zweck	Standardwert
Prüfintervall check-interval	Das Prüfintervall ist die Zeit vom Start einer Prüfung, die von einem Prober aus erfolgt ist, bis zum Start der nächsten Prüfung, die vom selben Prober aus erfolgt ist. Die Einheit sind Sekunden.	5s (5 Sekunden)
Zeitlimit timeout	Das Zeitlimit ist die Zeit, die Cloud de Confiance auf eine Antwort für eine Prüfung wartet. Der Wert muss kleiner oder gleich dem Prüfintervall sein. Die Einheit sind Sekunden.	5s (5 Sekunden)

Prüfungs-IP-Bereiche und Firewallregeln

Damit Systemdiagnosen funktionieren, müssen Sie allow-Firewallregeln für eingehenden Traffic erstellen, damit Traffic aus Cloud de Confiance -Probern eine Verbindung zu Ihren Back-Ends herstellen kann. Eine Anleitung finden Sie unter Erforderliche Firewallregeln erstellen.

In der folgenden Tabelle sind die zuzulassenden Quell-IP-Bereiche für jeden Load Balancer aufgeführt:

Produkt	Quell-IP-Bereiche für Systemdiagnoseprüfungen
Regionaler externer Application Load Balancer Regionaler interner Application Load Balancer Regionaler externer Proxy-Network Load Balancer Regionaler interner Proxy-Network Load Balancer Interner Passthrough-Network Load Balancer	Bei IPv4-Traffic zu den Back-Ends: 177.222.80.0/23 Bei IPv6-Traffic zu den Back-Ends: 2a13:7500:8301:b029:0:2b::/96
Externer Passthrough-Network Load Balancer	Bei IPv4-Traffic zu den Back-Ends: 177.222.87.64/26 Bei IPv6-Traffic zu den Back-Ends: 2a13:7500:241:30::/64 Für zielpoolbasierte Load-Balancer: 177.222.87.0/26

Sicherheitsaspekte für Prüfungs-IP-Bereiche

Beachten Sie bei der Planung von Systemdiagnosen und den erforderlichen Firewallregeln die folgenden Informationen:

• Die IP-Bereiche der Probes gehören Google. Cloud de Confiance verwendet spezielle Routen außerhalb Ihres VPC-Netzwerks, jedoch innerhalb des Produktionsnetzwerks von Google, für die Kommunikation zwischen Systemdiagnose-Probern und Backend-VMs.

• Die Prüfungs-IP-Bereiche werden ausschließlich im Produktionsnetzwerk von Google für Systemdiagnose und Load Balancing verwendet. Cloud de Confiance und das Produktionsnetzwerk von Google verhindern, dass die Prüfungs-IP-Bereiche für andere Zwecke verwendet werden, indem Folgendes erzwungen wird:

  • Google-Edge-Router verwerfen Pakete aus dem Internet, wenn die Pakete gefälschte Quell-IP-Adressen aus einem Prüfungs-IP-Bereich enthalten.

  • Sie können die Probe-IP-Bereiche nicht für Subnetze in Ihren VPC-Netzwerken verwenden. Weitere Informationen finden Sie unter Unzulässige IPv4-Subnetzbereiche und IPv6-Spezifikationen.

Bedeutung von Firewallregeln

FürCloud de Confiance müssen Sie die erforderlichen allow-Firewallregeln für eingehenden Traffic erstellen, um Traffic von Probern zu Ihren Back-Ends zuzulassen:

• Die Prüfungs-IP-Bereiche sind ein vollständiger Satz möglicher IP-Adressen, die vonCloud de Confiance -Probern verwendet werden. Wenn Sie tcpdump oder ein ähnliches Tool verwenden, beobachten Sie möglicherweise nicht den Traffic von allen IP-Adressen in allen Prüfungs-IP-Bereichen. Erstellen Sie als Best Practice Firewallregeln für eingehenden Traffic, die alle Prüfungs-IP-Bereiche als Quellen zulassen. Cloud de Confiance kann neue Prober automatisch ohne Benachrichtigung implementieren.

• Sie sollten diese Regeln nur auf Protokolle und Ports beschränken, die mit den von Ihren Systemdiagnosen verwendeten übereinstimmen.

Wenn Sie keine allow-Firewallregeln für eingehenden Traffic haben, die die Systemdiagnose zulassen, blockiert die implizierte deny-Regel für eingehenden Traffic den eingehenden Traffic. Wenn Prober Ihre Back-Ends nicht kontaktieren können, betrachtet der Load-Balancer Ihre Back-Ends als fehlerhaft.

Mehrere Prüfungen und Häufigkeit

Cloud de Confiance sendet Systemdiagnoseprüfungen von mehreren redundanten Systemen, den sogenannten Probern. Prober verwenden bestimmte Quell-IP-Bereiche. Cloud de Confiance verlässt sich bei der Implementierung einer Systemdiagnose nicht nur auf einen einzelnen Prober. Stattdessen bewerten mehrere Prober die Instanzen in Instanzgruppen-Back-Ends oder die Endpunkte in zonalen NEG-Back-Ends gleichzeitig. Wenn ein Prober fehlschlägt, erfasstCloud de Confiance die Systemzustände des Back-Ends weiterhin.

Die Intervall- und Zeitlimiteinstellungen, die Sie für eine Systemdiagnose konfigurieren, werden auf alle Prober angewendet. Für ein bestimmtes Back-End zeigen Software-Zugriffslogs und tcpdump häufigere Prüfungen als die von Ihnen konfigurierten Einstellungen an.

Dieses Verhalten ist normal und Sie können die Anzahl der Prober, die Cloud de Confiance für Systemdiagnosen verwendet, nicht konfigurieren. Sie können jedoch die Auswirkungen mehrerer simultaner Prüfungen kalkulieren, indem Sie die folgenden Faktoren berücksichtigen.

• Berücksichtigen Sie Folgendes, um die Prüfungshäufigkeit pro Back-End-Dienst zu schätzen:

  • Basishäufigkeit pro Back-End-Dienst: Jeder Systemdiagnose ist eine Prüfungshäufigkeit zugeordnet, die umgekehrt proportional zum konfigurierten Prüfintervall ist:

    ¹⁄_{(Prüfintervall)}

    Wenn Sie eine Systemdiagnose mit einem Back-End-Dienst verknüpfen, legen Sie eine Basishäufigkeit fest, die von jedem Prober für Back-Ends in diesem Back-End-Dienst verwendet wird.

  • Prüfungsskalierungsfaktor: Die Basishäufigkeit des Back-End-Dienstes wird mit der Anzahl der von Cloud de Confiance gleichzeitig verwendeten Prober multipliziert. Diese Zahl kann variieren, liegt jedoch in der Regel zwischen 5 und 10.

• Mehrere Weiterleitungsregeln für interne Passthrough-Netzwerk-Load-Balancer. Wenn Sie mehrere interne Weiterleitungsregeln mit jeweils unterschiedlicher IP-Adresse konfiguriert haben, die auf denselben regionalen internen Back-End-Dienst verweisen, verwendetCloud de Confiance mehrere Prober, um jede IP-Adresse zu prüfen. Die Prüfungshäufigkeit pro Back-End-Dienst wird mit der Anzahl der konfigurierten Weiterleitungsregeln multipliziert.

• Mehrere Weiterleitungsregeln für externe Passthrough-Netzwerk-Load-Balancer. Wenn Sie mehrere Weiterleitungsregeln konfiguriert haben, die auf denselben Back-End-Dienst oder Zielpool verweisen, verwendet Cloud de Confiance mehrere Prober, um jede IP-Adresse zu prüfen. Die Prüfungshäufigkeit pro Back-End-VM wird mit der Anzahl der konfigurierten Weiterleitungsregeln multipliziert.

• Mehrere Zielproxys für externe Application Load Balancer. Wenn Sie mehrere Zielproxys haben, die Traffic an dieselbe URL-Zuordnung weiterleiten, Cloud de Confiance verwendet mehrere Prober, um die jedem Zielproxy zugeordnete IP-Adresse zu prüfen. Die Prüfungshäufigkeit pro Back-End-Dienst wird mit der Anzahl der konfigurierten Zielproxys multipliziert.

• Mehrere Zielproxys für externe Proxy-Netzwerk-Load-Balancer und regionale interne Proxy-Netzwerk-Load-Balancer. Wenn Sie mehrere Zielproxys konfiguriert haben, die Traffic an denselben Backend-Dienst weiterleiten, verwendetCloud de Confiance mehrere Prober, um die jedem Zielproxy zugeordnete IP-Adresse zu prüfen. Die Prüfungshäufigkeit pro Back-End-Dienst wird mit der Anzahl der konfigurierten Zielproxys multipliziert.

• Summe der Back-End-Dienste. Wenn ein Back-End von mehreren Back-End-Diensten verwendet wird, werden die Back-End-Instanzen so oft kontaktiert, wie es der Häufigkeitssumme der Systemdiagnose jedes Back-End-Dienstes entspricht.

  Mit NEG-Back-Ends ist es schwieriger, die genaue Anzahl der Systemdiagnoseprüfungen zu ermitteln. Beispielsweise kann derselbe Endpunkt in mehreren zonalen NEGs vorliegen. Diese zonalen NEGs haben nicht unbedingt denselben Satz von Endpunkten und unterschiedliche Endpunkte können auf dasselbe Backend verweisen.

Ziel für Prüfungspakete

In der folgenden Tabelle sind die Netzwerkschnittstelle und Ziel-IP-Adressen aufgeführt, an die Systemdiagnose-Prober Pakete abhängig vom Typ des Load-Balancers senden.

Für externe Passthrough-Network Load Balancer und interne Passthrough-Network Load Balancer muss die Anwendung an die IP-Adresse des Load Balancers (oder eine beliebige IP-Adresse 0.0.0.0) gebunden werden.

Load-Balancer	Zielnetzwerkschnittstelle	Ziel-IP-Adresse
Regionaler externer Application Load Balancer Regionaler interner Application Load Balancer Regionaler externer Proxy-Network Load Balancer Regionaler interner Proxy-Network Load Balancer	Für Instanzgruppen-Back-Ends die primäre Netzwerkschnittstelle (nic0). Für zonale NEG-Back-Ends mit GCE_VM_IP_PORT-Endpunkten die Netzwerkschnittstelle im VPC-Netzwerk, das der NEG zugeordnet ist. Für zonale NEG-Back-Ends mit NON_GCP_PRIVATE_IP_PORT-Endpunkten muss der Endpunkt eine Schnittstelle einer lokalen Ressource darstellen, die über eine Route im VPC-Netzwerk erreichbar ist, die der NEG zugeordnet ist und sich in der Region befindet, die die NEG enthält.	Für Instanzgruppen-Back-Ends die primäre interne IPv4-Adresse, die der primären Netzwerkschnittstelle (nic0) jeder Instanz zugeordnet ist. Für zonale NEG-Back-Ends mit GCE_VM_IP_PORT-Endpunkten die IP-Adresse des Endpunkts: entweder eine primäre interne IPv4-Adresse der Netzwerkschnittstelle oder eine interne IPv4-Adresse aus einem Alias-IP-Bereich der Netzwerk-Schnittstelle. Für zonale NEG-Back-Ends mit NON_GCP_PRIVATE_IP_PORT-Endpunkten die IP-Adresse des Endpunkts.
Externer Passthrough-Network Load Balancer	Primäre Netzwerkschnittstelle (nic0)	IP-Adresse der externen Weiterleitungsregel Wenn mehrere Weiterleitungsregeln auf denselben Backend-Dienst verweisen (denselben Zielpool für zielpoolbasierte externe Passthrough-Netzwerk-Load-Balancer), sendet Cloud de Confiance Prüfungen an jede IP-Adresse der Weiterleitungsregel. Dies kann zu einer höheren Anzahl von Prüfungen führen.
Interner Passthrough-Network-Load-Balancer	Sowohl für Instanzgruppen-Backends als auch für zonale NEG-Backends mit GCE_VM_IP-Endpunkten hängt die verwendete Netzwerkschnittstelle davon ab, wie der Backend-Dienst konfiguriert ist. Weitere Informationen finden Sie unter Backend-Dienste und Netzwerkschnittstellen.	Die IP-Adresse der internen Weiterleitungsregel. Wenn mehrere Weiterleitungsregeln auf denselben Back-End-Dienst verweisen, Cloud de Confiancesendet Prüfungen an die IP-Adresse jeder Weiterleitungsregel. Dies kann zu einer höheren Anzahl von Prüfungen führen.

Erfolgskriterien für HTTP, HTTPS und HTTP/2

Für HTTP-, HTTPS- und HTTP/2-Systemdiagnosen muss immer ein HTTP-200 (OK)-Antwortcode vor dem Ablauf des Zeitlimits der Systemdiagnose empfangen werden. Alle anderen HTTP-Antwortcodes, einschließlich Weiterleitungsantwortcodes wie 301 und 302, gelten als fehlerhaft.

Neben der Anforderung eines HTTP-200 (OK)-Antwortcodes können Sie Folgendes tun:

• Konfigurieren Sie jeden Systemdiagnose-Prober so, dass HTTP-Anfragen an einen bestimmten Anfragepfad anstelle des Standardanfragepfads / gesendet werden.

• Konfigurieren Sie jeden Systemdiagnose-Prober so, dass er im HTTP-Antworttext nach dem Vorhandensein eines erwarteten Antwortstrings sucht. Der erwartete Antwortstring darf nur aus druckbaren ASCII-Zeichen mit einem Byte bestehen, die sich in den ersten 1.024 Byte des HTTP-Antworttexts befinden.

In der folgenden Tabelle sind gültige Kombinationen von Anfragepfad- und Antwort-Flags aufgeführt, die für HTTP-, HTTPS- und HTTP/2-Systemdiagnosen verfügbar sind.

Konfigurations-Flags	Prober-Verhalten	Erfolgskriterien
Weder --request-path noch --response angegeben	Der Prober verwendet / als Anfragepfad.	Nur HTTP-Antwortcode 200 (OK).
Sowohl --request-path als auch --response angegeben	Der Prober verwendet den konfigurierten Anfragepfad.	Der HTTP-Antwortcode 200 (OK) und die ersten 1.024 ASCII-Zeichen des HTTP-Antworttexts müssen mit dem erwarteten Antwortstring übereinstimmen.
Nur --response angegeben	Der Prober verwendet / als Anfragepfad.	Der HTTP-Antwortcode 200 (OK) und die ersten 1.024 ASCII-Zeichen des HTTP-Antworttexts müssen mit dem erwarteten Antwortstring übereinstimmen.
Nur --request-path angegeben	Der Prober verwendet den konfigurierten Anfragepfad.	Nur HTTP-Antwortcode 200 (OK).

Erfolgskriterien für SSL und TCP

Für TCP- und SSL-Systemdiagnosen gelten die folgenden grundlegenden Erfolgskriterien:

• Bei TCP-Systemdiagnosen muss ein Prober für die Systemdiagnose vor Ablauf des Zeitlimits für die Systemdiagnose eine TCP-Verbindung zum Backend öffnen.

• Bei SSL-Systemdiagnosen muss ein Prober für die Systemdiagnose vor Ablauf des Zeitlimits für die Systemdiagnose eine TCP-Verbindung zum Backend öffnen und den TLS/SSL-Handshake abschließen.

• Bei TCP-Systemdiagnosen muss die TCP-Verbindung auf eine der folgenden Arten geschlossen werden:

  • indem der Prober für die Systemdiagnose entweder ein FIN- oder ein RST-Paket (Reset, zurücksetzen) sendet.
  • Indem das Backend ein FIN-Paket sendet. Wenn ein Backend ein TCP-RST-Paket sendet, könnte die Prüfung als nicht erfolgreich eingestuft werden, wenn der Prober für die Systemdiagnose bereits ein FIN-Paket gesendet hat.

In der folgenden Tabelle sind gültige Kombinationen von Anfrage- und Antwort-Flags aufgeführt, die für TCP- und SSL-Systemdiagnosen verfügbar sind. Sowohl Anfrage- als auch Antwort-Flags dürfen nur aus druckbaren ASCII-Zeichen mit einem Byte bestehen. Jeder String darf maximal 1.024 Zeichen lang sein.

Konfigurations-Flags	Prober-Verhalten	Erfolgskriterien
Weder --request noch --response angegeben	Der Prober sendet keinen Anfragestring.	Nur grundlegende Erfolgskriterien.
Sowohl --request als auch --response angegeben	Der Prober sendet den konfigurierten Anfragestring.	Die grundlegenden Erfolgskriterien und der vom Prober empfangene Antwortstring müssen genau mit dem erwarteten Antwortstring übereinstimmen.
Nur --response angegeben	Der Prober sendet keinen Anfragestring.	Die grundlegenden Erfolgskriterien und der vom Prober empfangene Antwortstring müssen genau mit dem erwarteten Antwortstring übereinstimmen.
Nur --request angegeben	Der Prober sendet den konfigurierten Anfragestring.	Nur grundlegende Erfolgskriterien (Antwortstrings werden nicht geprüft).

Erfolgskriterien für gRPC

gRPC-Systemdiagnosen werden nur mit gRPC-Anwendungen, Cloud de Confiance Load Balancern und Cloud Service Mesh verwendet. Cloud de Confiance unterstützt zwei Arten von gRPC-Systemdiagnosen:

• GRPC_WITH_TLS-Systemdiagnosen (Vorabversion) werden für die Systemdiagnose von gRPC-Back-Ends mit aktivierter TLS verwendet. Sie unterstützen die nicht authentifizierte TLS-Verschlüsselung. Das bedeutet, dass bei den Systemdiagnosen die Identität des Servers nicht überprüft wird.
• GRPC-Systemdiagnosen werden für die Systemdiagnose unsicherer gRPC-Backends verwendet. Sie unterstützen keine Authentifizierung und Verschlüsselung und können daher nicht für gRPC-Backends mit aktiviertem TLS verwendet werden.

Wenn Sie gRPC-Systemdiagnosen (mit oder ohne TLS) verwenden, achten Sie darauf, dass der gRPC-Dienst die RPC-Antwort mit dem Status OK und dem Statusfeld auf SERVING bzw. NOT_SERVING gesetzt sendet.

Hier finden Sie weitere Informationen:

• Zusätzliches Flag für gRPC-Systemdiagnosen
• gRPC-Dokumentation für Systemdiagnosen

Erfolgskriterien für Legacy-Systemdiagnosen

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.

Systemzustand

Cloud de Confiance ermittelt mit den folgenden Konfigurations-Flags den Gesamtzustand aller Back-Ends, an die Traffic verteilt wird.

Konfigurations-Flag	Zweck	Standardwert
Schwellenwert für Intaktheit healthy-threshold	Der Schwellenwert für Intaktheit gibt die Anzahl der aufeinanderfolgenden erfolgreichen Prüfergebnisse an, die nötig sind, damit ein zuvor fehlerhaftes Back-End als fehlerfrei gilt.	Ein Grenzwert von 2 Prüfungen.
Fehlerschwellenwert unhealthy-threshold	Der Fehlerschwellenwert gibt die Anzahl der aufeinanderfolgenden fehlgeschlagenen Prüfergebnisse an, die nötig sind, damit ein zuvor fehlerfreies Back-End als fehlerhaft eingestuft wird.	Ein Grenzwert von 2 Prüfungen.

Cloud de Confiance stuft Back-Ends als fehlerfrei ein, wenn der Schwellenwert für Intaktheit erreicht wurde. Fehlerfreie Back-Ends können neue Verbindungen erhalten.

Cloud de Confiance stuft Back-Ends als fehlerhaft ein, wenn der Fehlerschwellenwert erreicht wurde. Fehlerhafte Back-Ends können keine neuen Verbindungen erhalten. Vorhandene Verbindungen werden jedoch nicht sofort beendet. Stattdessen bleibt die Verbindung so lange bestehen, bis eine Zeitüberschreitung auftritt oder der Traffic unterbrochen wird.

Bestehende Verbindungen geben möglicherweise keine Antworten zurück, je nachdem, warum die Prüfung fehlgeschlagen ist. Ein fehlerhaftes Back-End kann fehlerfrei werden, wenn es den Schwellenwert für Intaktheit wieder erreicht.

Das spezifische Verhalten, wenn alle Backends fehlerhaft sind, hängt vom Typ des verwendeten Load Balancers ab:

Zusätzliche Hinweise

In den folgenden Abschnitten finden Sie weitere Hinweise zur Verwendung von Systemdiagnosen auf Cloud de Confiance.

Zertifikate und Systemdiagnosen

Cloud de Confiance Systemdiagnose-Prober führen keine Zertifikatsprüfung durch, auch nicht bei Protokollen, die erfordern, dass Ihre Back-Ends Zertifikate verwenden (SSL, HTTPS und HTTP/2). Beispiel:

• Sie können selbst signierte oder von einer Zertifizierungsstelle signierte Zertifikate verwenden.
• Abgelaufene oder noch nicht gültige Zertifikate sind möglich.
• Weder das CN- noch das subjectAlternativeName-Attribut müssen mit einem Host-Header oder DNS-PTR-Eintrag übereinstimmen.

Header

Bei Systemdiagnosen, die ein beliebiges Protokoll verwenden, jedoch nicht bei Legacy-Systemdiagnosen können Sie mithilfe des Flags --proxy-header einen Proxy-Header festlegen.

Bei Systemdiagnosen, die HTTP-, HTTPS- oder HTTP/2-Protokolle verwenden, und bei Legacy-Systemdiagnosen können Sie mithilfe des Flags --host einen HTTP-Host-Header festlegen.

Wenn Sie benutzerdefinierte Anfrageheader verwenden, beachten Sie, dass der Load Balancer diese Header nur Clientanfragen hinzufügt, nicht den Systemdiagnoseprüfungen. Wenn Ihr Backend einen bestimmten Header für die Autorisierung erfordert, der im Systemdiagnosepaket fehlt, schlägt die Systemdiagnose möglicherweise fehl.

Beispiel für eine Systemdiagnose

Das Beispiel für die Systemdiagnose verwendet die folgenden Einstellungen:

• Intervall: 30 Sekunden
• Zeitlimit: 5 Sekunden
• Protokoll: HTTP
• Fehlerschwellenwert: 2 (Standard)
• Schwellenwert für Intaktheit: 2 (Standard)

Mit diesen Einstellungen verhält sich die Systemdiagnose folgendermaßen:

1. Mehrere redundante Systeme werden gleichzeitig mit den Parametern der Systemdiagnose konfiguriert. Die Intervall- und Zeitlimiteinstellungen werden auf jedes System angewendet. Weitere Informationen finden Sie unter Mehrere Prüfungen und Häufigkeit.

2. Jeder Systemdiagnose-Prober führt Folgendes aus:

   1. Initiiert alle 30 Sekunden eine HTTP-Verbindung von einer der Quell-IP-Adressen zur Back-End-Instanz.
   2. Wartet bis zu fünf Sekunden auf den HTTP-Antwortcode 200 (OK) (das Erfolgskriterium für HTTP-, HTTPS- und HTTP/2-Protokolle).

3. Ein Back-End gilt als fehlerhaft, wenn mindestens ein System für die Systemdiagnoseprüfung folgende Voraussetzungen erfüllt:

   1. Es erhält keinen HTTP 200 (OK)-Antwortcode für zwei aufeinanderfolgende Prüfungen. Beispielsweise wird die Verbindung möglicherweise abgelehnt oder es kommt zu einer Verbindungs- oder Socket-Zeitüberschreitung.
   2. Es erhält zwei aufeinanderfolgende Antworten, die nicht den protokollspezifischen Erfolgskriterien entsprechen.

4. Ein Back-End gilt als fehlerfrei, wenn mindestens ein System für die Systemdiagnoseprüfung zwei aufeinanderfolgende Antworten empfängt, die den protokollspezifischen Erfolgskriterien entsprechen.

In diesem Beispiel initiiert jeder Prober alle 30 Sekunden eine Verbindung. Zwischen den Verbindungsversuchen eines Probers liegen 30 Sekunden, unabhängig von der Dauer des Zeitlimits (ganz gleich, ob es eine Zeitüberschreitung der Verbindung gab oder nicht). Mit anderen Worten: Das Zeitlimit muss immer kleiner oder gleich dem Intervall sein und das Zeitlimit verlängert das Intervall nicht.

In diesem Beispiel hat jeder Prober folgende Zeitintervalle (in Sekunden):

1. t=0: Prüfung A starten
2. t=5: Prüfung A stoppen
3. t=30: Prüfung B starten
4. t=35: Prüfung B stoppen
5. t=60: Prüfung C starten
6. t=65: Prüfung C stoppen

Nächste Schritte

• Informationen zum Erstellen, Ändern und Verwenden von Systemdiagnosen unter Systemdiagnosen verwenden
• Aktivieren Sie Systemdiagnose-Logging, um Fehler bei Systemdiagnosen zu beheben.