Cron-Job-Überwachung mit Heartbeats: ein praktisches Tutorial

Cron-Jobs, die erfolgreich ausgeführt werden, sind einfach. Cron-Jobs, die laut fehlschlagen, sind auch einfach: Die Fehler-E-Mail landet in Ihrem Posteingang. Die schwierigen sind Cron-Jobs, die ganz aufhören zu laufen. Der Server startet neu, der Container wird verdrängt, das Benutzerkonto wird deaktiviert, der Systemd-Timer wurde durch eine Konfigurationsänderung maskiert. Der Job wird nie ausgeführt, es wird kein Fehler erzeugt, und Sie finden es drei Wochen später heraus, wenn die Sicherungen, von denen Sie ausgingen, dass sie stattfinden, weg sind. Heartbeat-Überwachung fängt genau diesen Fehlermodus.

Wie Heartbeat-Überwachung funktioniert

Ein Heartbeat-Monitor invertiert die normale Sonde-Beziehung. Statt dass ein externer Prober Ihren Service aufruft, ruft Ihr Job den Monitor auf. Sie definieren eine Schonfrist (z.B. 'dieser Job sollte jede Stunde pingen, geben Sie fünf Minuten Spielraum'). Wenn der Monitor aufhört, Pings zu hören, öffnet er ein Downtime-Ereignis und warnt Sie.

Das Ergebnis ist ein Dead-Man's-Switch-Mechanismus. Solange der Job läuft und Erfolg meldet, bleibt der Monitor still. Wenn der Job nicht mehr pingt (weil er abstürzte, weil der Server offline ist, weil jemand den Timer deaktiviert hat), wird die Warnung ausgelöst. Aus drei Wochen stillem Backup-Fehler wird ein Fünf-Minuten-Incident.

Wann man Heartbeats statt regulärer Checks verwendet

Heartbeats sind kein Ersatz für HTTP-Überwachung. Sie decken eine andere Jobklasse ab: alles, das out-of-band zeitgesteuert läuft.

• Backup-Jobs: nächtliche Dumps, S3-Synchronisierung, Remote-rsync.
• Data-Pipeline-Läufe: ETL-Jobs, tägliche Berichtserstellung, Rechnungsabstimmung.
• Geplante Marketing-E-Mails: wöchentliche Newsletter, Drip-Kampagnen.
• SSL-Erneuerungs-Jobs: certbot, acme.sh.
• Alles, das in Cron, Systemd-Timern, GitHub Actions-Zeitplänen, Cloudflare Workers-Cron oder AWS EventBridge läuft.

So fügen Sie einen Heartbeat zu einem Bash-Cron-Job hinzu

Das einfachste Muster ist ein einzelner curl-Aufruf am Ende Ihres Skripts. Die Heartbeat-URL ist eindeutig für den Monitor; checken Sie sie nicht in die Versionskontrolle ein.

Ein Muster, das Fehler elegant behandelt: `do_the_work && curl -fsS --retry 3 https://your-monitor.example/heartbeat`. Das && sendet den Heartbeat nur ab, wenn die eigentliche Arbeit erfolgreich war. Das --retry 3 behandelt vorübergehende Netzwerkprobleme. Das -fsS macht curl bei Erfolg leise und bei Fehler laut, was Cron möchte.

Heartbeats aus Python und Node

Dasselbe Muster in zwei häufigen Programmiersprachen. Beide wrappen die Arbeit in try/except und melden Erfolg nur bei einem sauberen Lauf.

• Python: `try: do_the_work(); requests.post('https://your-monitor.example/heartbeat', timeout=10); except Exception: logger.exception('job failed')`
• Node: `try { await doTheWork(); await fetch('https://your-monitor.example/heartbeat', { method: 'POST' }); } catch (err) { console.error('job failed', err); }`
• Wichtig: Senden Sie den Heartbeat nicht in einem finally-Block. Finally wird sowohl bei Erfolg als auch bei Fehler ausgeführt. Sie möchten, dass der Heartbeat ein positives Signal ist, nicht einfach nur ein Zeichen dafür, dass das Skript gelaufen ist.

Das Toleranzfenster richtig einstellen

Das Toleranzfenster ist der Parameter, der am häufigsten falsch eingestellt wird. Zu kurz und Sie bekommen Fehlalarme, wenn der Job ein paar Sekunden zu spät läuft. Zu lang und ein echter Fehler bleibt für Stunden unbemerkt.

Eine gute Faustregel ist das Doppelte der normalen Job-Dauer plus 5 Minuten. Eine nächtliche Sicherung, die normalerweise 8 Minuten dauert, benötigt ein Toleranzfenster von 8 * 2 + 5 = 21 Minuten. Ein wöchentlicher Job, der 2 Stunden dauert, benötigt ein Toleranzfenster von 2 * 2 + 0,5 = 4,5 Stunden. Das Toleranzfenster schützt Sie vor harmloser Varianz, nicht vor echten Fehlern.

Heartbeat-Muster, die Sie zuerst einrichten sollten

Wenn Sie von Grund auf neu anfangen, fangen drei Heartbeats die meisten stillen Fehler auf, die Probleme verursachen. Ein Monitor für nächtliche Sicherungen mit einem Toleranzfenster von 6 Stunden. Ein Monitor für SSL-Erneuerung auf dem Cron-Job, der certbot oder acme.sh ausführt, mit einem Toleranzfenster von einer Woche. Ein Monitor für tägliche Berichte oder Abrechnungsabstimmung mit einem Toleranzfenster von 90 Minuten. Diese drei fangen zusammen die Fehlermodi ein, die am längsten unbemerkt bleiben und die größten Folgen haben. Sobald diese eingerichtet sind, fügen Sie nach und nach einen Heartbeat zu jedem anderen geplanten Job hinzu.