Die Health-Endpoints verstehen
MobilityManager stellt Health-Endpunkte bereit, mit denen Orchestrierungswerkzeuge, Load-Balancer und Überwachungswerkzeuge prüfen können, ob die Anwendung aktiv und bereit ist, Anfragen zu bedienen. Dieser Artikel beschreibt jeden Endpunkt und wie Sie ihn verwenden.
Die Endpunkte
| Endpunkt | Bedeutung | Typische Verwendung |
|---|---|---|
/healthz | Kombinierter Zustand — alle Prüfungen müssen bestanden werden. | Startup-Probe, allgemeine Zustandsprüfung. |
/livez | Liveness — nur mit live markierte Prüfungen müssen bestanden werden. | Liveness-Probe: Reagiert der Prozess? |
/readyz | Readiness — nur mit ready markierte Prüfungen müssen bestanden werden. | Readiness-Probe: Kann Anfragen angenommen werden? |
/health | Kombinierter Zustand, gleichbedeutend mit /healthz. | Alternativer Zustandspfad. |
All diese sind in jeder Umgebung verfügbar, da die Produktionsüberwachung auf sie angewiesen ist. Jeder gibt HTTP 200 zurück, wenn er fehlerfrei ist, und einen Nicht-200-Status, wenn eine erforderliche Prüfung fehlschlägt.
Liveness gegenüber Readiness
- Liveness (
/livez) beantwortet die Frage "Läuft die Anwendung?" Ein anhaltender Fehler signalisiert dem Orchestrierungswerkzeug, den Container neu zu starten. - Readiness (
/readyz) beantwortet die Frage "Kann die Anwendung im Moment Anfragen annehmen?" Ein Fehler entfernt den Pod aus dem Load-Balancer, ohne ihn neu zu starten. - Kombiniert (
/healthz) erfordert, dass jede Prüfung bestanden wird, und eignet sich gut für eine Startup-Probe, die den Datenverkehr abriegelt, bis die Anwendung vollständig initialisiert ist.
Hinweis: Health-Check-Anfragen sind vom verteilten Tracing ausgenommen, sodass häufiges Prüfen keine Telemetrie-Störgeräusche verursacht.
Wie Kubernetes sie verwendet
Das bereitgestellte Kubernetes-Deployment bildet die Endpunkte auf Probes ab:
- livenessProbe →
/livez - readinessProbe →
/readyz - startupProbe →
/healthz
Die Startup-Probe gibt der Anwendung Zeit zur Initialisierung, bevor die Liveness- und Readiness-Prüfungen übernehmen. Docker Compose verwendet ebenfalls /healthz für seinen Container-Health-Check.
Den Zustand manuell prüfen
curl -i http://localhost:8080/healthz
curl -i http://localhost:8080/livez
curl -i http://localhost:8080/readyzEine fehlerfreie Instanz gibt für jeden 200 OK zurück. Ein Readiness-Fehler bei bestandener Liveness-Prüfung bedeutet üblicherweise, dass die Anwendung läuft, eine Abhängigkeit (etwa die Datenbank) jedoch noch nicht verfügbar ist.
Tipp: Die Onboarding-Weiterleitung fängt diese Pfade niemals ab, sodass Probes weiterhin erfolgreich sind, auch während das System unkonfiguriert ist und auf den Einrichtungsassistenten wartet.
Verwandte Artikel
- Überblick über die Kubernetes-Bereitstellung
- Migrationen und die Onboarding-Weiterleitung beim Start
- Fehlersuche bei einem fehlgeschlagenen Start
- Checkliste zur Produktionshärtung
