# Health Checks: Die Lebensversicherung für hochverfügbare Dienste

TL;DR / Management Summary Ein Loadbalancer ist nur so gut wie seine Fähigkeit, defekte Server zu erkennen. Health Checks (auch Liveness-Probes genannt) sind periodische Tests, die der Balancer gegen jedes Backend ausführt. Ein Senior Admin nutzt keine simplen “Ping”-Tests, sondern implementiert logische Applikations-Checks (z.B. eine Datenbank-Abfrage via HTTP-Endpoint), um sicherzustellen, dass der Server nicht nur erreichbar ist, sondern auch sinnvoll arbeitet.

# 1. Ebenen der Prüfung

Vom Kabel zur Logik.

1. Layer 3 (Ping): Prüft nur, ob der Host online ist. (Sagt nichts über den Webdienst aus).
2. Layer 4 (TCP Connect): Prüft, ob der Port (z.B. 80) offen ist. (Sagt nichts über die Applikation aus).
3. Layer 7 (HTTP Check): Prüft, ob die Webseite den Status 200 OK liefert.
4. Deep App Check: Prüft, ob spezifischer Inhalt auf der Seite steht (z.B. “DB-Connection: Success”).

# 2. Parameter eines Health Checks

Die Empfindlichkeit einstellen.

• Interval: Wie oft wird getestet? (z.B. alle 5 Sekunden).
• Timeout: Wie lange darf die Antwort dauern? (z.B. 2 Sekunden).
• Fall (Unhealthy Threshold): Nach wie vielen Fehlversuchen wird der Server gesperrt? (z.B. 3x).
• Rise (Healthy Threshold): Nach wie vielen Erfolgen darf der Server wieder in den Pool? (z.B. 2x).

# 3. Deep Dive: Der ‘Status-Page’ Trick

Echte Intelligenz im Backend.

Anstatt die Startseite der Webseite zu prüfen (die oft groß und langsam ist):

• Aktion: Erstellen Sie eine winzige Datei /health.php.
• Logik: Das Script prüft intern die Verbindung zum SQL-Server und zum Redis-Cache.
• Vorteil: Der Loadbalancer bekommt in Millisekunden ein klares Signal über den Gesamtzustand des Stacks.

# 4. Day-2 Operations: Wartungsmodus (Draining)

Sanftes Abschalten.

Ein guter Health Check erkennt auch administrative Zustände.

• Aktion: Der Loadbalancer sucht nach einem spezifischen HTTP-Header oder einer Datei (z.B. maintenance.txt).
• Workflow: Der Admin erstellt die Datei auf dem Server -> Der Loadbalancer nimmt den Server aus dem Pool -> Bestehende User arbeiten zu Ende -> Wartung ohne Downtime.

# 5. Troubleshooting & “War Stories”

Wenn der Check den Server ‘tötet’.

# Top 3 Fehlerbilder

1. Symptom: Alle Server sind gleichzeitig Offline.

   • Ursache: Der Loadbalancer selbst hat keine Netzwerkverbindung zum Backend-VLAN oder der DNS-Name des Health-Checks lässt sich nicht auflösen.
   • Lösung: Lokaler Host-Eintrag am Balancer nutzen.

2. Symptom: “Flapping” (Server geht ständig an und aus).

   • Ursache: Die Timeouts sind zu knapp bemessen. Eine kurze Lastspitze am Server führt zum Failover.
   • Fix: Timeout auf das Doppelte der maximalen App-Antwortzeit setzen.

3. Symptom: “False Positive”. Balancer sagt Online, aber User sehen Fehler.

   • Ursache: Port 80 ist offen (L4 Check), aber die Festplatte ist im Read-Only Modus.

# “War Story”: Der “DDoS” durch Monitoring

Ein Admin konfigurierte 10 verschiedene Loadbalancer (in verschiedenen RZs) so, dass sie alle 1 Sekunde einen komplexen Health-Check gegen eine einzelne Datenbank-VM ausführten. Das Ergebnis: Die Datenbank verarbeitete 10 Anfragen pro Sekunde nur durch das Monitoring. Die Log-Files füllten sich mit Gigabytes an “Health Check success” Meldungen, was schlussendlich die Disk füllte und zum echten Absturz führte. Lehre: Koordinieren Sie Ihre Monitoring-Frequenzen. Ein Intervall von 5-10 Sekunden reicht für die meisten Enterprise-Anwendungen völlig aus.

# 6. Monitoring & Reporting

Status-Historie.

# Backend Availability Dashboard

Visualisieren Sie in Grafana (Artikel 698):

• Uptime per Backend Node.
• Mean Time Between Failures (MTBF).
• Alert: Wenn ein Server mehr als 5x pro Stunde aus dem Pool fliegt -> Automatische Hardware-Diagnose einleiten.

# 7. Fazit & Empfehlung

Health Checks sind die Augen des Loadbalancers.

• Empfehlung: Nutzen Sie immer Layer-7 Checks für Web-Applikationen. Nur sie liefern die nötige Tiefe.
• Wichtig: Verwenden Sie für die Health-Checks einen separaten Account/Pfad, der nicht in Ihren Standard-Access-Logs auftaucht, um das Rauschen zu minimieren.

# Anhang: Cheatsheet (Test-Methoden)

# Referenzen

• Google SRE Book: Monitoring Distributed Systems
• HAProxy Docs: Health Checking
• NGINX: HTTP Health Checks Guide