Heartbeat Monitoring erkennt Ausfälle, indem es ein periodisches Signal, den Heartbeat, von einem Job, Service oder System erwartet und alarmiert, wenn es nicht innerhalb des Intervalls plus Karenzzeit eintrifft. Es kehrt klassisches Monitoring um: Stille ist der Alarm. Typische Einsätze sind Cronjobs, Backups, Batch-Pipelines und die Prüfung des Alertings selbst.
Was Heartbeat Monitoring ist
Das meiste Monitoring wartet darauf, dass etwas Schlechtes passiert: ein Fehler, eine langsame Antwort, ein fehlgeschlagener Health Check. Für Aufgaben, deren Ausfall gar kein Signal erzeugt, funktioniert das nicht. Ein nächtliches Backup, das nie startet, schreibt kein Fehlerlog. Ein Cronjob auf einem abgebauten Host hört einfach auf. Heartbeat Monitoring schließt diese Lücke: Der Job sendet bei jedem erfolgreichen Lauf ein Signal, und das Monitoring alarmiert, wenn es nicht rechtzeitig eintrifft.
Dasselbe Prinzip heißt auch Dead Man's Switch, nach der Sicherheitsfahrschaltung in Zügen, die bremst, sobald der Fahrer sie nicht mehr betätigt. Es passt überall dort, wo ausbleibende Aktivität der Fehler ist.
So funktioniert es
- Zeitplan festlegen. Für jeden Job definieren Sie das erwartete Intervall, etwa alle 24 Stunden oder einen Cron-Ausdruck, sowie eine Karenzzeit, die normale Laufzeitschwankungen abfängt.
- Heartbeat senden. Am Ende eines erfolgreichen Laufs ruft der Job eine eindeutige URL auf, pusht eine Metrik oder schreibt einen Zeitstempel. Optional meldet er auch den Start, um die Laufzeit zu messen, sowie explizite Fehlschläge.
- Stille auswerten. Kommt innerhalb von Intervall plus Karenzzeit kein Heartbeat an, öffnet das Monitoring einen Alert. Viele Umsetzungen alarmieren zusätzlich, wenn ein Lauf gestartet, aber nie beendet wurde.
Ein minimales Beispiel für ein Backup-Skript:
#!/bin/sh
set -e
pg_dump app > /backups/app.sql
curl -fsS --retry 3 https://heartbeat.example.com/ping/backup-nightlyDank set -e wird der Ping nur gesendet, wenn der Dump erfolgreich war. URL und Dienst sind beispielhaft, das Muster funktioniert mit jedem Werkzeug, das Check-ins annimmt.
Heartbeat, Health Check und synthetisches Monitoring
| Ansatz | Richtung | Erkennt |
|---|---|---|
| Health Check | Pull: Monitoring fragt den Service | Service gerade nicht erreichbar oder ungesund |
| Synthetischer Check | Pull: Monitoring simuliert einen Nutzer | Defekte User Journeys und Endpunkte von außen |
| Heartbeat | Push: Job meldet sich beim Monitoring | Jobs, die nicht, zu spät oder nie vollständig liefen |
Pull-basierte Checks brauchen einen erreichbaren Endpunkt, den Batch-Jobs, Worker hinter NAT und kurzlebige Container nicht haben. Heartbeats funktionieren überall, wo ausgehende Anfragen möglich sind.
Wer überwacht das Monitoring?
Ein zweiter wichtiger Einsatz ist die Prüfung des Alerting-Pfads selbst. Fallen Prometheus, Alertmanager oder die Benachrichtigungsintegration aus, feuert kein Alert und alles wirkt ruhig. Das Projekt kube-prometheus liefert deshalb einen Watchdog-Alert, der immer feuert. Alertmanager leitet ihn laufend an einen externen Dead Man's Switch weiter. Bleiben diese Benachrichtigungen aus, alarmiert der externe Dienst die Rufbereitschaft. Dasselbe gilt für Log- und Telemetrie-Pipelines: Ein erwarteter Datenstrom, der verstummt, ist ein Incident.
In Prometheus lassen sich Heartbeats als Staleness-Prüfung formulieren, etwa mit kube-state-metrics:
time() - kube_cronjob_status_last_successful_time{cronjob="backup-nightly"} > 26 * 3600Was Sie mit Heartbeats absichern sollten
- Geplante Jobs: Cronjobs, Kubernetes-CronJobs, zeitgesteuerte Serverless-Funktionen und CI-Pipelines, die nach Zeitplan laufen.
- Datenpipelines: ETL- und ELT-Jobs, Report-Generierung, Datenexporte an Partner und der Neuaufbau von Suchindizes.
- Housekeeping: Backups, Zertifikatserneuerungen, Log-Rotation und Aufräumjobs, deren Ausfall sich erst Wochen später bemerkbar macht.
- Langlaufende Worker: Queue-Consumer, die sich während der Verarbeitung regelmäßig melden sollten.
- Edge-Geräte und entfernte Standorte, die das Internet erreichen, aber selbst nicht von außen erreichbar sind.
Als Faustregel gilt: Alles, dessen unbemerkter Stillstand für einen Tag Schaden anrichten würde, verdient einen Heartbeat. Beginnen Sie mit den Jobs, deren Ausfall am teuersten wäre, und erweitern Sie die Abdeckung schrittweise, statt alles auf einmal einzurichten.
Best Practices
- Bei Erfolg pingen, nicht beim Start. Ein Heartbeat vor getaner Arbeit beweist nur, dass der Scheduler lief.
- Karenzzeiten bewusst wählen. Zu kurz erzeugt Rauschen und Alert Fatigue, zu lang verzögert die Erkennung über den relevanten Zeitpunkt hinaus.
- Ein Heartbeat pro Job und Umgebung, damit ein fehlender Check-in auf genau eine Ursache zeigt.
- Den Check-in robust machen mit kurzen Timeouts und Retries, und ein fehlgeschlagener Ping darf niemals den Job selbst scheitern lassen.
- Owner und Runbook im Alert dokumentieren, denn Jobs geraten oft in Vergessenheit, bis sie ausfallen.
Typische Fehler
Typisch ist, nur den Start eines Jobs zu überwachen, Heartbeats bei geplanter Wartung nicht zu pausieren und „erfolgreich gelaufen“ mit „das Richtige getan“ gleichzusetzen. Ein Backup-Job, der nach zwei Sekunden mit leerer Datei endet, sendet einen perfekten Heartbeat. Ergänzen Sie dort, wo es zählt, eine Plausibilitätsmetrik wie Dateigröße oder Datensatzanzahl.
Wie Obseria unterstützt
Job-Metriken und Logs, die per OpenTelemetry oder Prometheus an Obseria gehen, können Staleness- und Absence-Alerts auslösen, und das Incident Management leitet sie an das zuständige Team weiter. Für die Außensicht auf Endpunkte und User Journeys kombinieren Sie Heartbeats mit synthetischem Monitoring von über 50 Standorten.
