Warum Ihre Cron-Jobs unbemerkt fehlschlagen (und wie Sie es bemerken)

Das Problem mit Cron

Cron ist auf eine Weise zuverlässig: Es führt Ihren Befehl planmäßig aus. Auf eine andere, wichtigere Weise ist es unzuverlässig: Es sagt Ihnen nicht, wenn Ihr Befehl fehlschlägt.

Ihr Server läuft. Der Cron-Daemon funktioniert. Der Zeitplan wird pünktlich ausgelöst. Aber das Skript, auf das Sie verwiesen haben, beendet sich mit einem Nicht-Null-Status, läuft in einen Timeout oder geht der Speicher aus. Niemand weiß es. Crons Aufgabe ist es, den Prozess zu starten, nicht zu überprüfen, ob er erfolgreich war.

Das ist kein Cron-Fehler. So wurde Cron konzipiert. Cron stammt aus der Zeit vor dem Web. Es wurde in einer Ära entwickelt, in der Aufgaben in Logdateien schrieben und ein Mensch sie regelmäßig überprüfte. Dieses Modell skaliert nicht für moderne Infrastrukturen, in denen ein Entwickler Dutzende geplanter Aufgaben auf mehreren Servern verwaltet.

Was stille Cron-Ausfälle Sie kosten

Ein stiller Backup-Fehler bedeutet, dass Sie ihn entdecken, wenn Sie das Backup brauchen. Vielleicht drei Wochen später, nach einem Datenbank-Korruptionsvorfall. Die Lücke zwischen dem Moment, in dem das Backup nicht mehr funktionierte, und dem Moment, in dem Sie es brauchten, sind Daten, die Sie nicht wiederherstellen können.

Ein stiller E-Mail-Warteschlangen-Fehler bedeutet, dass Kunden keine Benachrichtigungen mehr erhalten. Passwort-Zurücksetzungen, Bestellbestätigungen, Rechnungsbelege. Zunächst beschwert sich niemand, weil niemand weiß, was fehlt. Wenn Sie es bemerken, haben Sie Tausende unzustellbarer E-Mails und verwirrte Nutzer.

Ein stiller Datenexport-Fehler bedeutet, dass Ihre Analysen falsch sind. Ihre Dashboards zeigen Trends basierend auf veralteten Daten. Sie treffen Entscheidungen auf unvollständiger Basis. Der Fehler verschlimmert sich, je länger er unentdeckt bleibt.

Warum Uptime-Überwachung dies nicht erfasst

Ihr Uptime-Monitor sagt, Ihr Server sei erreichbar. Ihre API liefert 200 zurück. Ihr Dashboard lädt. Laut Ihrem Überwachungs-Dashboard ist alles in Ordnung.

Aber keine dieser Prüfungen sagt Ihnen, ob das Backup von letzter Nacht abgeschlossen wurde. Sie wissen nicht, ob Ihre Rechnungsabstimmung gelaufen ist. Sie wissen nicht, ob die Datenpipeline, die Ihre Analysen befüllt, fertiggestellt wurde.

Uptime-Überwachung beantwortet die Frage: „Kann ich diesen Endpunkt erreichen?” Heartbeat-Überwachung beantwortet: „Wurde diese Aufgabe ausgeführt?” Es sind komplementäre Fragen. Sie brauchen beide.

Wie Heartbeat-Überwachung funktioniert

Heartbeat-Überwachung ist einfach. Jede geplante Aufgabe erhält eine eindeutige URL mit einem geheimen Token. Fügen Sie am Ende Ihrer Aufgabe eine einzige Zeile hinzu, die diese URL anpingt:

curl -s https://pingwatchdog.com/api/v1/heartbeat/hw_YOURTOKEN

Wenn der Ping innerhalb des erwarteten Zeitfensters eintrifft, gilt die Heartbeat-Prüfung als bestanden. Wenn das Fenster ohne Ping schließt, löst der Monitor einen Alarm aus.

Sie konfigurieren das erwartete Intervall. Wenn Ihr Backup alle 6 Stunden läuft, setzen Sie das Intervall auf 6 Stunden. Fügen Sie eine Karenzzeit hinzu, wenn die Aufgabendauer variiert. Eine 10-minütige Karenzzeit bedeutet, dass der Monitor erst alarmiert, wenn der Ping 10 Minuten verspätet ist.

Das ist die gesamte Einrichtung. Eine URL. Ein curl-Befehl. Keine Konfigurationsdateien.

Einrichtung in der Praxis

Hier ist ein Cron-Eintrag für ein nächtliches Datenbank-Backup:

0 2 * * * /usr/local/bin/backup-db.sh && curl -s https://pingwatchdog.com/api/v1/heartbeat/hw_YOURTOKEN

Das && ist entscheidend. Es bedeutet: „Führe curl nur aus, wenn das Backup-Skript mit Status 0 (Erfolg) beendet wird.” Wenn das Backup fehlschlägt, wird curl nie ausgeführt. Kein Ping trifft ein. Sie erhalten einen Alarm.

Wenn Sie überwachen möchten, ob das Skript überhaupt ausgeführt wurde (auch bei Fehler), verwenden Sie ; anstelle von && und fügen Sie eine Fehlerbehandlung im Skript hinzu, um den Status zu melden. Aber für die meisten Anwendungsfälle ist && das, was Sie wollen. Sie interessieren sich für Erfolg, nicht nur für Ausführung.

Was Sie mit Heartbeats überwachen sollten

Beginnen Sie mit den Jobs, die am meisten schmerzen würden, wenn sie unbemerkt fehlschlagen:

Datenbank-Backups: Dies ist der häufigste Anwendungsfall und der mit den höchsten Fehlerkosten. Ein Backup, von dem Sie nicht wissen, dass es fehlt, ist schlimmer als gar kein Backup.

E-Mail-Zustellwarteschlangen: Wenn Ihre Transaktions-E-Mails oder Marketing-E-Mails nicht mehr gesendet werden, wollen Sie es innerhalb von Minuten wissen, nicht Stunden.

Abrechnung und Rechnungserstellung: Fehlgeschlagene Abrechnung bedeutet Umsatzverlust. Ein Heartbeat für Ihren Abrechnungsjob erkennt dies vor Monatsende.

Datensynchronisation und Exporte: Wenn Ihre Analyse-Pipeline oder Data-Warehouse-Synchronisation fehlschlägt, sind Ihre Berichte falsch. Ein Heartbeat informiert Sie innerhalb des erwarteten Intervalls.

Zertifikatserneuerung: Wenn Sie certbot oder ähnliche Tools mit automatischer Erneuerung verwenden, fügen Sie einen Heartbeat hinzu. Zertifikatsablauf ist eine der vermeidbarsten Ursachen für Ausfallzeiten.

Log-Rotation und Bereinigung: Wenn die Log-Rotation fehlschlägt, läuft Ihre Festplatte voll. Ihr Server geht offline. Ein Heartbeat erkennt den Rotationsfehler, bevor die Festplatte voll ist.

Heartbeat-Überwachung vs. Cron-Überwachungsdienste

Tools wie Healthchecks.io und Cronitor konzentrieren sich ausschließlich auf Cron- und geplante Aufgabenüberwachung. Das machen sie gut. Einige fügen Funktionen wie Aufgabendauer-Tracking und Leistungstrends hinzu.

PingWatchdog bietet Heartbeat-Überwachung zusammen mit Uptime-Überwachung und SSL-Überwachung auf einer einzigen Plattform. Sie benötigen kein separates Tool für Cron-Jobs. Sie überwachen Ihre Websites, APIs, SSL-Zertifikate und geplanten Aufgaben von einem Dashboard mit einer Alarmierungspipeline.

Das ist wichtig, weil dasselbe Team, das die Uptime überwacht, normalerweise auch die Cron-Jobs betreut. Die Konsolidierung von Tools bedeutet weniger Dashboards zum Überprüfen, weniger Alarmkanäle zum Konfigurieren und weniger Abonnements zum Verwalten.

Vergleichen Sie PingWatchdog mit Healthchecks.io, um zu sehen, wie unsere Heartbeat-Überwachung im Vergleich zu Uptime-Überwachung und Statusseiten abschneidet.

Cron-Überwachung in Containern und Kubernetes

Wenn Sie Cron-Jobs in Docker-Containern oder Kubernetes CronJobs ausführen, funktioniert dasselbe Heartbeat-Muster. Fügen Sie einen curl-Befehl am Ende des Entrypoints Ihres Containers oder des Befehls Ihres CronJobs hinzu.

Für Kubernetes:

apiVersion: batch/v1
kind: CronJob
metadata:
  name: db-backup
spec:
  schedule: "0 2 * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: backup
            image: your-backup-image
            command:
            - /bin/sh
            - -c
            - "/backup.sh && curl -s https://pingwatchdog.com/api/v1/heartbeat/hw_YOURTOKEN"
          restartPolicy: OnFailure

Dasselbe Prinzip gilt für AWS Lambda Scheduled Events, Google Cloud Scheduler, systemd-Timer oder jeden anderen Scheduler. Wenn Ihre Aufgabe eine HTTP-Anfrage stellen kann, kann sie einen Heartbeat senden.

Loslegen

PingWatchdog bietet Heartbeat-Überwachung in jedem Tarif. Der kostenlose Tarif enthält 3 Heartbeat-Monitore. Kostenpflichtige Tarife gehen bis zu 25.

Erfahren Sie mehr über Heartbeat-Überwachungsfunktionen oder richten Sie Ihren ersten Monitor ein.