Health Checks und Failover

Die wichtigsten Befehle zum Merken

• curl --max-time 2 — jeden Check zeitlich begrenzen.
• curl --write-out — HTTP-Status und Dauer vergleichen.

Befehle und Optionen

Befehl oder Option	Bedeutung
--silent --show-error	Fortschritt verbergen, Transportfehler zeigen.
--max-time 2	Jeden Transfer auf zwei Sekunden begrenzen.
--output /dev/null	Antwortinhalt verwerfen.
--write-out '…'	Das benannte Ergebnis nach der Anfrage ausgeben.
%{http_code} / %{time_total}	HTTP-Status / vergangene Sekunden anzeigen.
/live, /ready, /	Liveness-, Readiness- und Proxy-Anwendungspfad des Tests.

Die Pfade sind vereinbarte Testendpunkte, keine automatisch vorhandenen Standards. Ohne HTTP-Fehlermodus müssen Status und Transportdiagnose gemeinsam gelesen werden.

Die entscheidenden Konzepte

1. Ein Health Check stellt eine bestimmte Frage

Ein Health Check prüft eine Bedingung aus Sicht eines Beobachters. TCP kann einen annehmenden Listener zeigen; HTTP kann Route und erwartete Antwort prüfen.

Beides beweist nicht zwingend einen erfolgreichen Geschäftsvorgang. Bestimme zuerst die Frage: Macht der Prozess Fortschritt, darf er Verkehr erhalten oder gelingt eine ganze Benutzerreise? Ein Endpunkt ersetzt nicht sicher jede Gesundheitsebene.

2. Liveness und Readiness brauchen verschiedene Reaktionen

Liveness fragt, ob der Prozess weiterlaufen soll oder etwa einen Neustart benötigt. Readiness fragt, ob er momentan normalen Verkehr erhalten soll. Startup-Prüfungen können der Initialisierung eigenen Spielraum geben.

Eine Anwendung kann leben und vorübergehend nicht dienen können. Alle Instanzen wegen einer ausgefallenen gemeinsamen Datenbank neu zu starten kann den Ausfall verstärken. Prüftiefe und Controllerreaktion müssen zum zu behebenden Fehler passen.

3. Erkennung braucht Zeit und stabile Schwellen

Periodische Prüfungen erkennen Ausfälle nicht sofort. Intervall, Timeout und erforderliche aufeinanderfolgende Fehler bestimmen die Verzögerung. Erfolgsschwellen können ständiges Hinzufügen und Entfernen instabiler Backends begrenzen.

Schnelle Reaktion und Fehlalarme stehen in Spannung. Langsame Checks verbrauchen zudem Ressourcen im gestressten System. Aktive Proben und passive reale Anfragefehler liefern verschiedene, kombinierbare Belege.

4. Failover braucht ein tragfähiges Ziel

Ein ungesundes Backend nicht mehr auszuwählen hilft nur mit anderen leistungsfähigen Backends. Restkapazität, gemeinsame Abhängigkeiten, Sitzungszustand und Datenkonsistenz bestimmen das Ergebnis.

Bestehende Verbindungen und laufende Anfragen können nach Umschaltung weiter scheitern. Retries können unklare Operationen verdoppeln. Failover ist ein Wiederherstellungsablauf, keine Fehlerfreiheitszusage. Er braucht kontrollierte Tests von Erkennung und Anwendungsverhalten nach dem Wechsel.

Ein kleines Beispiel

Optional: Vergleiche vorhandene Backendchecks und Proxyanfrage. Die Befehle beobachten nur und ändern weder Backendzustand noch Prozess oder Proxyrichtlinie.

curl --silent --show-error --max-time 2 --output /dev/null --write-out 'live: http=%{http_code} total=%{time_total}s\n' http://localhost:8081/live
curl --silent --show-error --max-time 2 --output /dev/null --write-out 'ready: http=%{http_code} total=%{time_total}s\n' http://localhost:8081/ready
curl --silent --show-error --max-time 2 --output /dev/null --write-out 'service: http=%{http_code} total=%{time_total}s\n' http://localhost:8080/

Lies Status und Dauer gemäß Testvertrag. Erfolgreiche Liveness bei fehlgeschlagener Readiness kann vorübergehend korrekt sein. Die Proxyanfrage kann ein anderes Backend als das direkt geprüfte treffen.

HTTP-Code 000 bedeutet häufig fehlende HTTP-Antwort; prüfe curl-Fehler statt eines vermeintlichen Anwendungsstatus. Diese Momentaufnahme demonstriert weder automatische Entfernung noch Schwellen oder unterbrechungsfreies Failover. Dafür ist ein eigener kontrollierter Ausfalltest nötig. Aufräumen entfällt.

Merke dir: Health Checks steuern konkrete Wiederherstellung. Failover braucht passende Erkennung, Routing, Restkapazität und Anwendungssemantik.