Ein typischer Health-Check sendet eine Anfrage an einen Endpoint, sieht eine 200-Antwort und markiert den Service als gesund. In modernen Anwendungen reicht das nicht aus. Die Anwendungs-Homepage kann antworten, während die Datenbankverbindung langsam ist, die Cache-Schicht defekt ist, eine nachgelagerte Abhängigkeit ausgefallen ist oder der Login-Flow aufgehört hat zu funktionieren. Wenn der Load Balancer diesen Unterschied nicht erkennen kann, routet er weiterhin Traffic zu Backends, die antworten, aber keine echte Arbeit leisten können.
Einzelschrittprüfungen fallen bei sitzungsbasierten Protokollen noch kürzer. Für FTP, LDAP, Oracle oder benutzerdefinierte TCP-Protokolle bedeutet ein offener Port nicht, dass der Service gesund ist. Ein echter Health-Check muss sich anmelden, einen Befehl senden, die erwartete Antwort empfangen, sich bei Bedarf abmelden und den Antwortinhalt validieren. Andernfalls erscheint der Service erreichbar, während echte Benutzeroperationen fehlschlagen.
Inhaltsvalidierung wird brüchig, wenn sie auf Plain-Text-Matching beschränkt ist. Eine API kann immer das Wort "OK" zurückgeben, während der Abhängigkeitsstatus, die Latenzmetrik oder die Geschäftsregel innerhalb des JSON fehlschlägt. Wenn ein Health-Check die Bedeutung der Antwort nicht abfragen kann, werden Verschlechterungen auf Anwendungsebene spät erkannt.
Der richtige Ansatz besteht darin, Health-Checks mit Protokolltiefe, mehrstufigen Szenarien, Inhaltsabfragen und konfigurierbaren Rise/Fall-Schwellenwerten anzugehen. Probe-Operationen müssen vom Haupt-Traffic-Flow isoliert laufen, damit langsame oder ausgefallene Health-Checks den Benutzer-Traffic nicht verzögern.
TR7 Aktives Health-Monitoring liefert dieses Modell: Es überwacht 11 Protokolle aus einer einzigen Konfiguration, führt mehrstufige Szenarien aus, validiert Inhaltsbedeutung mit JSONata und hält nur wirklich gesunde Ziele in Rotation.
TR7 transformiert Health-Checking von einer Einzel-Protokoll-Kontrolle in ein Multi-Protokoll-, szenariobasiertes und inhaltsvalidiertes Entscheidungssystem.
TCP-, UDP-, HTTP-, HTTPS-, PING-, DNS-, FTP-, FTPS-, LDAP-, LDAPS- und Oracle-Prüfungen werden alle vom selben Health-Check-Objekt aus verwaltet. Abhängig vom ausgewählten checkType werden nur die relevanten Felder angezeigt, sodass Operatoren nicht mit irrelevanten Parametern belastet werden.
Für TCP-, UDP- und Oracle-Prüfungen werden geordnete Kontrollflows mit send-, expect-, regex- und wait-Schritten aufgebaut. Wenn ein Schritt fehlschlägt, wird die Probe als fehlgeschlagen markiert und der Backend-Gesundheitszustand entsprechend aktualisiert.
Für HTTP- und HTTPS-Prüfungen werden JSONata-Abfragen verwendet, um den echten Zustand innerhalb einer JSON-Antwort zu lesen. Ein Backend gilt nicht als gesund, weil es 200 zurückgibt — Felder wie Abhängigkeitsstatus, Score, Latenz oder Geschäftszustand können ebenfalls überprüft werden.
Die Anzahl aufeinanderfolgender fehlgeschlagener Antworten, die erforderlich sind, um ein Backend als ungesund zu markieren, und die Anzahl aufeinanderfolgender erfolgreicher Antworten, die erforderlich sind, um es zurückzubringen, werden unabhängig konfiguriert. Dies verhindert, dass vorübergehende Netzwerkschwankungen Backends kontinuierlich in und aus der Rotation zu- und abschalten.
Aktives Health-Monitoring macht verschiedene Service-Typen aus demselben Editor definierbar, testbar und mit operativen Schwellenwerten verwaltbar.
TR7 unterstützt TCP-, UDP-, HTTP-, HTTPS-, PING-, DNS-, FTP-, FTPS-, LDAP-, LDAPS- und Oracle-Health-Checks. Operatoren benötigen keine separaten Tools für eine Oracle-Datenbank, ein LDAP-Verzeichnis, einen DNS-Server, ein FTPS-Repository oder eine HTTP-API. Relevante Felder erscheinen basierend auf dem ausgewählten Protokolltyp; nicht verwandte Felder werden ausgeblendet. Dieses Modell macht Health-Checking über heterogene Backends hinweg standardisiert und wartbar.
Für TCP-Prüfungen können sendText-, expectText-, expectRegex- und wait-Schritte sequenziell ausgeführt werden. SMTP-Banner, IMAP-Capability-Abfragen, Redis-PING/PONG-Austausche, MQTT-Antworten und benutzerdefinierte TCP-Protokollnachrichten sind alle mit diesem Modell testbar. Anstatt nur eine Verbindung zu öffnen, wird ein echter Protokolldialog ausgeführt. Wenn ein Schritt nicht das erwartete Ergebnis produziert, wird das Backend als ungesund markiert.
Für UDP-Prüfungen sind send-, wait-, expectText- und expectRegex-Schritte verfügbar. Die zu sendenden Daten können im Text-, Hex- oder Base64-Format definiert werden, was Flexibilität für Binärprotokoll-Probes bietet. Für DNS, NTP, RADIUS, SIP und ähnliche UDP-Services wird die erwartete Protokollantwort validiert — nicht nur ob der Port geöffnet ist. Dies macht UDP-Services aktiv und sinnvoll überwachbar.
HTTP/HTTPS-Health-Checks unterstützen Methode, URI, benutzerdefinierte Header-Liste, Request-Body und virtuellen Host. Ein API-Endpoint kann mit einem Authorization-Header, JSON-Body oder benutzerdefiniertem Host-Header geprobt werden. Akzeptable Status-Codes müssen kein einzelner Wert sein — 200, 204 oder 304 können alle als gesund angesehen werden. Dieses Design bringt Health-Checking näher an die echte Anwendungsnutzung.
Wenn contentCheckMode auf jsonata gesetzt ist, wird der Response-Body als JSON ausgewertet und der JSONata-Ausdruck ausgeführt. Service-Status, Abhängigkeitsergebnis, Datenbanklatenz oder eine Geschäftsmetrik können alle in einem einzigen Ausdruck geprüft werden. Wenn der Ausdruck ein wahrhaftes Ergebnis produziert, ist das Backend gesund; ein falsches Ergebnis markiert es als fehlgeschlagen. JSONata-Fehler werden protokolliert, sodass ein falscher Ausdruck oder eine unerwartete Antwortstruktur sichtbar wird.
Für einfache Szenarien, die kein JSONata erfordern, führt contentQuery eine Textsuche im Response-Body durch. Marker-Strings wie "Welcome", "UP" oder "Service Ready" — oder anwendungsspezifischer Text — können schnell geprüft werden. Dieser Modus bietet eine einfache Lösung für einfache Health-Endpoints oder Legacy-Anwendungen. Operatoren wählen zwischen Basis-Check und JSONata basierend auf dem Szenario.
LDAP/LDAPS-Prüfungen können nicht nur den Port-Zugang testen, sondern die echte Bind-Operation. Ein mit Benutzername und Passwort durchgeführter Bind validiert den Verzeichnis-Service auf Authentifizierungsebene. Selbst wenn der Port geöffnet ist, kann ein Backend als ungesund markiert werden, wenn die Bind-Queue, Autorisierung oder der Service ein Problem hat. Dies bietet kritische Sichtbarkeit besonders für AAM- und Enterprise-Zugriffsflows.
Oracle-Health-Checks unterstützen Verbindungsdetails, Benutzername, Passwort und Szenario-Schritte. SQL wird über executeCmd ausgeführt und der erwartete Text oder die minimale Zeilenzahl wird überprüft. Anstatt eines einfachen Verbindungstests können echte Datenzugriffe und Geschäftsmetriken abgefragt werden. Dieser Ansatz macht die Frage der Datenbankverfügbarkeit aus Anwendungsperspektive bedeutsam.
Health-Checks operieren zusammen mit Intervall, Timeout, Schwellenwert, Szenario-Zusammensetzung, Instanzidentität und systeminternen spezialisierten Kontrollen.
testInterval ist von 0,5 bis 3600 Sekunden konfigurierbar; der Standard ist 1 Sekunde. timeout ist von 0,01 bis 3600 Sekunden konfigurierbar. Aggressiver Timeout ermöglicht schnelleres Failover, kann aber das False-Positive-Risiko erhöhen und sollte auf das Service-Verhalten abgestimmt werden.
requiredFailure ist standardmäßig 2; requiredSuccess ist standardmäßig 3. Diese Schwellenwerte bestimmen, wie schnell ein Service aus der Rotation entfernt und wie vorsichtig er zurückgebracht wird. Beide Seiten des Schwellenwerts werden unabhängig verwaltet, um vorübergehende Schwankungen zu filtern.
Ein einzelner Health-Check kann mehrere atomare Prüfungen mit AND/OR-Logik kombinieren. Das bedeutet, dass nicht nur ein einzelnes Probe-Ergebnis, sondern mehrere Abhängigkeiten oder Protokollschritte zusammen bewertet werden können. Komplexe Service-Gesundheit wird realistischer modelliert.
Derselbe Health-Check pflegt für jedes Backend einen separaten Zustand. Die Health-Check-Instanz-ID wird durch Check und Ziel differenziert. Das bedeutet, dass selbst wenn dasselbe Check-Profil auf mehrere Ziele angewendet wird, die Gesundheitsgeschichte jedes Ziels unabhängig verfolgt wird.
Die negate-Einstellung kehrt die normale Erfolgslogik um. Dieser Modus wird verwendet, wenn eine bestimmte URL unerreichbar sein soll, eine bestimmte Antwort nicht zurückgegeben werden soll oder ein Service-Pfad unzugänglich bleiben soll. Eine erfolgreiche Antwort wird als Fehler behandelt; eine fehlgeschlagene Antwort wird als Erfolg behandelt.
Systeminterne Health-Checks wie Gateway-Monitore und Cluster-IP-Verbindungsprüfungen können automatisch generiert werden. Diese Prüfungen werden verwendet, um nicht nur Anwendungs-Backends, sondern auch die Konnektivität und Upstream-Erreichbarkeit rund um TR7 zu überwachen. Das Modell kann mit zusätzlichen Check-Typen wie Datencenter-Prüfungen auf der GTM-Seite erweitert werden.
Ein E-Commerce-Team kann einen HTTP-Check mit JSONata verwenden, um nicht nur zu überprüfen, ob der Warenkorb-Service 200 zurückgibt, sondern auch ob Datenbanklatenz und Verfügbarkeitsmetriken innerhalb der Grenzen liegen. Ein langsames oder abhängigkeitsdegradiertes Backend wird automatisch aus der Rotation entfernt.
Banking-Teams können Oracle-Checks verwenden, um über das Öffnen einer Verbindung hinauszugehen und tatsächlich echte SQL-Abfragen auszuführen. Wenn die erwartete Zeilenzahl oder das Abfrageergebnis nicht erfüllt wird, wird das Backend als ungesund markiert und Traffic wird zu sicheren Zielen geleitet.
Behördenanwendungen können überprüfen, ob ein Verzeichnis-Service nicht nur auf Port-Ebene, sondern durch eine echte Bind-Operation funktioniert. Wenn der Port geöffnet ist, aber die Authentifizierung fehlschlägt, behandelt das System dies als Gesundheitsproblem.
Telekommunikations-Teams können echte Datensatz-Abfragen für eine kritische Domain mit einem DNS-Check durchführen. Der geöffnete DNS-Port ist nicht ausreichend — der Resolver muss die erwartete Antwort produzieren, um als gesund zu gelten.
Traffic-Entscheidungen auf zuverlässige Gesundheitsdaten über 11 Protokolle, mehrstufige Szenarien und JSONata-Inhaltsvalidierung stützen. Lassen Sie uns ein Live-Setup auf Ihren eigenen Services durchgehen.