Der Load Balancer markiert das Backend als „gesund“: Port 443 antwortet. Unterdessen lehnt PostgreSQL Verbindungen ab – jede API-Anfrage gibt 503 zurück. Benutzer sehen einen Ausfall; Die Hostüberwachung wird grün angezeigt. Das Team verschwendet zwanzig Minuten mit der Suche nach „Netzwerk“, obwohl der Gesundheitscheck die Basis nie getestet hat.
Dieses Szenario wiederholt sich jede Woche auf scheinbar gut konfigurierten Stacks: gültiges TLS-Zertifikat, aktiver Webprozess, bestandener TCP-Test. Das Problem ist nicht der Host – es ist die Frage der Sonde.
Eine Gesundheitsprüfung der Anwendung beantwortet eine bestimmte Frage: Kann diese Instanz jetzt eine repräsentative Anfrage verarbeiten? Nicht: Hört jemand einen Port ab? Die Unterscheidung ändert alles, wenn eine kritische Abhängigkeit fällt, ohne dass der Webserver stoppt.
TCP, leichtes HTTP und umfassende Überprüfung
Teams zögern oft zwischen drei Untersuchungsebenen. Jeder hat seinen Platz – aber nur die dritte Ebene schützt den Endbenutzer.
| Geben Sie | ein Prüfen | Grenze |
|---|---|---|
| TCP-Verbindung | Hörprozess | Schnell, blind |
HTTP 200 / | Startseite | Kann im CDN ausgeblendet werden |
| HTTP „/health/live“ | Prozess + Laufzeit | Minimal |
| HTTP „/health/ready“ | DB, Cache, Deps | Traffic-Entzug bei Ausfall |
„/health/live“ dient der Liveness (Kubernetes): keine Datenbank – dies vermeidet eine Schleife von Neustarts, wenn Postgres nicht verfügbar ist, die Anwendung selbst aber noch läuft. /health/ready dient der Bereitschaft: umfasst nur kritische Abhängigkeiten – Basis, Cache, Warteschlange, falls erforderlich.
Eine Prüfung, die bestanden wird, wenn die Basis tot ist, leitet den Verkehr zu einem Sinkhole weiter. Dies ist der frustrierendste Fall: Auf der Infrastrukturseite ist alles grün, auf der Clientseite ist alles rot.
Entwerfen Sie schnelle und zuverlässige Kontrollen
Ein guter Gesundheitsendpunkt respektiert vier Regeln. Erstens ein Timeout von weniger als ein oder zwei Sekunden, abgestimmt zwischen dem Load Balancer und dem Kubelet – eine langsame Prüfung blockiert die Entfernung von Datenverkehr, wenn Sie ihn am meisten benötigen.
Dann keine Nebenwirkungen: keine Erstellung von Testaufträgen in der Produktion, kein Versand von E-Mails, kein Schreiben in die Datenbank. Das Probe liest den Status; sie ändert es nicht.
Drittens eine stabile Antwort in JSON: { "status": "ok", "checks": { "db": "ok" } } – durch Überwachung analysierbar und im Vorfall für einen Menschen lesbar.
Schließlich ein zwei bis fünf Sekunden langer Cache im Speicher, wenn die Sonden aggressiv sind. Vermeiden Sie die Wiederverwendung einer umfangreichen Seite (WordPress-Verwaltung, komplettes Dashboard) als Sonde: Sie verschwenden mit jeder Umfrage Prozessor.
Hosting-Distributor, Kubernetes und geteilt
OVHcloud, Hetzner und Scaleway bieten Splitter mit konfigurierbarer HTTP-Sonde an. Stellen Sie die Prüfung auf „/health/ready“, ein angemessenes Intervall (fünf bis zehn Sekunden) und aufeinanderfolgende Fehler- und Erfolgsschwellenwerte ein, um dauerhafte Failover zu vermeiden.
Richten Sie auf Kubernetes die Prüfpfade auf den externen Dispatcher aus – eine inkonsistente Doppelprüfung führt zu permanenten Wechseln zwischen fehlerfrei und fehlerhaft.
Überwachen Sie bei der Freigabe ohne benutzerdefinierte Probe eine externe URL (UptimeRobot usw.) mit Warnung. Es ist eine Ergänzung und kein Ersatz für eine interne Sonde, die Abhängigkeiten testet.
Sicherheits- und Informationsleck
Eine öffentliche Auflistung von Versionen, Umgebung und Clusternamen unter „/health“ ist eine Einladung. Ratenbegrenzung, internes Netzwerk, IP-Whitelist. In sensiblen Infrastrukturen mTLS-Authentifizierung zwischen Dispatcher und Anwendung.
Ein Angreifer, der „/health“ untersucht, entdeckt manchmal den Status Ihrer Datenbank, die Version Ihres Frameworks oder die interne Topologie – alles nützliche Informationen für die gezielte Durchführung eines Angriffs.
Der Gipfel: Grün für die Überwachung, Rot für den Kunden
Die Sonde sollte sich an die minimale Benutzerreise halten – nicht an die Transportschicht.
Entscheide dich und gehe ohne blinden Fleck voran
Implementieren Sie separate Live- und Ready-Endpunkte mit jeweils klarer Verantwortung: Der erste entscheidet, ob der Prozess neu gestartet werden soll, der zweite, ob die Instanz Datenverkehr empfangen kann. Beziehen Sie nur kritische Abhängigkeiten in Ready ein – nicht den gesamten Business-Stack. Sichern Sie den Endpunkt im internen Netzwerk oder auf der IP-Whitelist. Richten Sie Load Balancer und Kubernetes aus auf denselben Pfaden und Schwellenwerten. Validierung in der Vorproduktion: Basis abschneiden → der Datenverkehr muss ohne massiven Neustart der Pods entfernt werden. Vergleichen Sie Dispatcher-Angebote über das Verzeichnis und den Vergleicher.
Häufig gestellte Fragen
Warum reicht eine TCP-Prüfung auf Port 80 selten aus?
Bei einer TCP-Prüfung wird nur überprüft, ob ein Socket geöffnet ist – nicht, ob die Anwendung korrekt reagiert oder ob die Datenbank erreichbar ist. Der Port ist möglicherweise geöffnet, während PHP-FPM voll ist, die Anwendung 500 Fehler zurückgibt oder PostgreSQL Verbindungen ablehnt. Bei einem Vorfall verschwenden Sie wertvolle Zeit mit der Diagnose des „Netzwerks“, obwohl das Problem anwendungsbezogen ist.
Was sollte ein /health/ready-Endpunkt enthalten?
Leichte Prüfungen kritischer Abhängigkeiten: Datenbank-Ping, Redis-PING, Warteschlange, falls erforderlich – ohne die gesamte Geschäftslogik zu starten. Der Timeout muss kurz bleiben (ein bis zwei Sekunden). Im Falle eines Fehlers wird die Instanz aus dem Datenverkehr entfernt; Es wird nicht unbedingt neu gestartet, wodurch eine Verschlimmerung eines Datenbankvorfalls vermieden wird.
Öffentlicher oder interner Gesundheitscheck?
Bevorzugen Sie einen internen Endpunkt – privates Netzwerk, IP-Whitelist oder gegenseitige Authentifizierung. Ein nicht authentifiziertes öffentliches „/health“ kann zu einem Hinweis auf einen Angreifer oder ein Informationsleck (Softwareversion, Datenbankstatus) werden. Wenn ein öffentlicher Endpunkt unvermeidbar ist, begrenzen Sie die offengelegten Informationen und wenden Sie eine strenge Ratenbegrenzung an.
Wie kann verhindert werden, dass die Gesundheitsprüfung die App überlastet?
Speichern Sie das Ergebnis für einige Sekunden im Speicher, beschränken Sie parallele Prüfungen und verwenden Sie einen dedizierten Endpunkt ohne ausführliche Protokolle. Bei Shared vervielfacht ein Dispatcher, der jede Sekunde prüft, die Last – konfigurieren Sie ein Intervall von fünf bis zehn Sekunden und einen leichtgewichtigen Endpunkt.
„Gesund“ bedeutet „bereit zum Servieren“ – nicht „Port antwortet auf Telnet“.