Cron-Jobs überwachen: 5 Muster mit Heartbeat-Prüfungen

Cron ist hervorragend darin, Dinge nach Plan zu starten, und katastrophal darin, Ihnen zu sagen, wenn es das nicht tut. Ein Backup, das aufhört zu laufen, wirft selten einen Fehler aus, den Sie sehen. Es tut einfach still nichts, und Sie merken es Wochen später, wenn Sie das Backup brauchen und es nicht da ist. Das ist das Problem des stillen Versagens, und genau deshalb braucht jede geplante Aufgabe, auf die es ankommt, eine Heartbeat-Prüfung.

Ein Heartbeat (oder "Dead Man's Switch") dreht die Logik um. Statt zu alarmieren, wenn etwas schiefläuft, pingt Ihre Aufgabe einen Monitoring-Endpoint an, wenn alles in Ordnung ist. Kommt der erwartete Ping nicht rechtzeitig, alarmiert der Monitor. Kein Ping, keine Nachricht, großes Problem.

Unten stehen fünf Muster, vom einfachsten bis zum robustesten. Alle setzen voraus, dass Sie eine Heartbeat-URL aus Ihrem Monitoring-Tool haben.

Muster 1: Klassischer Dead Man's Switch

Das einfachste mögliche Setup. Ihre Aufgabe ruft nach Abschluss eine URL auf. Erhält der Monitor im erwarteten Fenster keine Nachricht, alarmiert er.

# Tägliches Backup um 02:30, Ping nach Abschluss
30 2 * * * /usr/local/bin/backup.sh && curl -fsS https://ihr-monitor/ping/abc123

Auf && kommt es an: curl läuft nur dann, wenn backup.sh mit Code 0 (Erfolg) endet. Schlägt das Backup fehl, wird kein Ping gesendet und der Monitor fängt es ab. Die Schalter -fsS sorgen dafür, dass curl bei HTTP-Fehlern still scheitert, echte Probleme aber trotzdem zeigt.

Schwäche: Es bestätigt nur, dass das Skript lief und mit null endete. Schluckt das Skript eigene Fehler und endet trotzdem mit null, bekommen Sie ein falsches "alles in Ordnung".

Muster 2: Ping nur bei echtem Erfolg

Machen Sie das Erfolgssignal explizit, statt sich auf die Verkettung von Exit-Codes in der Shell zu verlassen. In mehrstufigen Skripten ist das klarer.

#!/bin/bash
set -euo pipefail   # bei jedem Fehler laut abbrechen
run_the_backup
verify_the_backup    # wirklich prüfen, dass die Ausgabe existiert und Sinn ergibt
curl -fsS https://ihr-monitor/ping/abc123   # nur erreicht, wenn alles oben durchlief

set -euo pipefail bedeutet, dass jeder fehlgeschlagene Befehl das Skript noch vor dem Ping abbricht. Das Hinzufügen eines echten Verifikations-Schritts (die Backup-Datei existiert, ist größer als null Byte) schließt das Loch "mit null geendet, aber nichts getan" aus Muster 1.

Muster 3: Exit-Code-Wrapper

Wenn Sie die Aufgabe selbst nicht anpassen können (Drittanbieter-Binary, Vendor-Skript), umhüllen Sie sie. Der Wrapper signalisiert den Start, führt die Aufgabe aus und meldet den Exit-Code.

#!/bin/bash
URL=https://ihr-monitor/ping/abc123
curl -fsS "$URL/start"                  # Signal "ich bin gestartet"
/opt/vendor/report-generator            # Aufgabe, die Sie nicht kontrollieren
EXIT=$?
curl -fsS "$URL/$EXIT"                   # Exit-Code melden

Das Signalisieren des Starts erlaubt dem Monitor auch, die Laufzeit zu messen und eine Aufgabe zu erkennen, die gestartet, aber nie beendet wurde (hängengeblieben). Das Melden des Exit-Codes erlaubt ihm, "lief in Ordnung" von "lief und scheiterte" zu unterscheiden.

Muster 4: Bedingter Ping (nur pingen, wenn die Arbeit sinnvoll war)

Manche Aufgaben laufen nach Plan, machen aber nur manchmal echte Arbeit (ein Queue-Prozessor, der die Queue oft leer vorfindet). Sie wollen keine "fehlender Heartbeat"-Warnung, wenn die Aufgabe legitim nichts getan hat. Pingen Sie nur, wenn echte Arbeit passiert ist, und weiten Sie den Plan entsprechend aus.

#!/bin/bash
PROCESSED=$(process_queue)
if [ "$PROCESSED" -gt 0 ]; then
  curl -fsS "https://ihr-monitor/ping/abc123?count=$PROCESSED"
fi

Setzen Sie die erwartete Periode des Monitors auf die längste reale Lücke zwischen echten Läufen. Der Preis ist Empfindlichkeit: ein längeres Fenster bedeutet langsamere Erkennung, nutzen Sie es also nur, wenn unregelmäßige Arbeit wirklich erwartet wird.

Muster 5: Jitter und Grace-Fenster

Reale Pläne driften. Eine auf 02:00 gesetzte Aufgabe kann wegen Last um 02:00:04 starten, und die Laufzeit einer täglichen Aufgabe schwankt. Erwartet der Monitor den Ping exakt im Intervall, schreckt normaler Jitter Sie unnötig auf.

Die Lösung ist eine Grace-Periode: Sagen Sie dem Monitor, nach der erwarteten Zeit noch eine gewisse Reserve zu warten, bevor er alarmiert. Ein tägliches Backup, das normalerweise 8 Minuten dauert, kann ein 20-Minuten-Grace-Fenster nutzen. Außerdem wollen Sie etwas Jitter in der Planung selbst, wenn Sie viele Aufgaben haben, damit sie nicht in derselben Sekunde dieselbe Ressource belasten:

# Kleine zufällige Verzögerung (0-59s), damit sich Aufgaben um 02:00 verteilen
0 2 * * * sleep $((RANDOM % 60)) && /usr/local/bin/backup.sh && curl -fsS https://ihr-monitor/ping/abc123

Grace-Fenster sind der Unterschied zwischen einem Monitor, dem Sie vertrauen, und einem, den Sie nach dem dritten Fehlalarm stummschalten. Setzen Sie Grace so, dass es die schlimmste reale Laufzeit der Aufgabe bequem überschreitet, nicht ihren Durchschnitt.

Schneller Überblick

Wie Sie es in die Praxis bringen

Beginnen Sie noch heute mit Muster 1 bei der wichtigsten Aufgabe (Backup, Abrechnungslauf, Datensynchronisation). Fügen Sie Verifikation (Muster 2) und ein Grace-Fenster (Muster 5) hinzu, bevor Sie sich darauf verlassen. Eine ausführlichere Anleitung zur Heartbeat-Konfiguration finden Sie in unserem Leitfaden Monitoring von Cron-Jobs via Heartbeat.

Wenn Ihre Aufgabe über einen bestimmten Port mit einem Dienst kommuniziert, prüfen Sie die Erreichbarkeit zuerst mit dem kostenlosen Port-Checker. Und wenn Sie bereit sind, geplante Aufgaben zusammen mit Websites und APIs an einem Ort zu überwachen, sehen Sie sich an, wie das Uptime-Monitoring von ePulz.io funktioniert - die 7-tägige Testphase ist kostenlos, ohne Karte.