Cron-Monitoring, das Ihren Zeitplan versteht

Der Ausfall, den niemand bemerkt

Ein Cronjob, der laut abstürzt, fällt auf. Ein Cronjob, der nicht mehr eingeplant wird — der Crontab-Eintrag, der bei einer Servermigration verloren ging, der Container, der nicht mehr startet, der Queue-Worker, den der OOM-Killer geholt hat — erzeugt keinen Fehler, keine E-Mail und keine Logzeile. Er läuft einfach nie wieder, und Sie erfahren es, wenn jemand fragt, warum die Rechnungen nicht rausgegangen sind.

Heartbeat-Monitoring dreht einen HTTP-Check um. Statt dass okokumo Ihren Dienst abfragt, ruft Ihr Job nach jedem erfolgreichen Lauf eine eindeutige Ping-URL auf. Verstreicht das Fenster, schlägt okokumo Alarm — denn das Ausbleiben des Signals ist das Signal.

Ein Zeitraum, oder die Crontab-Zeile selbst

Die einfache Form ist ein Zeitraum plus Kulanzzeit: „erwarte jede Stunde einen Ping, erlaube zehn Minuten Spielraum“. Das funktioniert, bis der Zeitplan nicht mehr gleichmäßig ist.

0 3 * * 1-5 — 3 Uhr an Werktagen — sind 24 Stunden zwischen Montag und Dienstag und 72 Stunden zwischen Freitag und Montag. Ein starres Intervall kann das nicht beschreiben. Setzen Sie es auf 24 Stunden, weckt es Sie jeden Samstagmorgen; setzen Sie es auf 72, bleibt ein Job, der am Dienstag leise aufgehört hat, bis Freitag unbemerkt.

Ein Cron-Check kann deshalb den Crontab-Ausdruck selbst nehmen, plus die IANA-Zeitzone, in der die Crontab Ihres Servers läuft. Die Frist wird der nächste geplante Lauf plus die Kulanzzeit, nach jedem Ping neu berechnet. Ein Job nur an Werktagen bleibt das ganze Wochenende ruhig, und ein ausgefallener Dienstagslauf wird innerhalb seines eigenen Kulanzfensters erkannt.

Warum die Zeitzone pro Check gilt

Eine Crontab feuert in der Ortszeit ihres Hosts. Ein fester UTC-Offset verschiebt sich bei jeder Zeitumstellung um eine Stunde, und zwar in Richtung Fehlalarm — 03:00 in Paris ist im Winter 01:00 UTC und im Sommer 02:00 UTC. Jeder Check trägt seine eigene Zone, damit Server in verschiedenen Regionen sich nicht einigen müssen.

Den Zeitplan sehen, bevor Sie sich darauf verlassen

Das Formular listet die nächsten Läufe schon beim Tippen, jeweils mit Offset. Ein Cron-Ausdruck lässt sich leicht auf subtile Weise falsch schreiben — die Felder Tag-des-Monats und Tag-der-Woche werden mit ODER verknüpft, nicht mit UND, was fast jeden einmal überrascht — und ein falscher Zeitplan bedeutet hier einen verpassten Alarm, nicht einen Schönheitsfehler.

So funktioniert der Scheduler →

Die Ping-URL aufrufen

Eine HTTP-Anfrage am Ende Ihres Jobs, aus allem, was eine stellen kann:

• curl am Ende eines Shell-Skripts oder eines Docker-Entrypoints.
• Ein letzter Schritt in einer CI-Pipeline, damit ein fehlgeschlagener Deploy den Heartbeat stoppt.
• Eine Anfrage aus dem Job selbst, nachdem die Arbeit geschrieben ist, nicht bevor sie beginnt.

Pingen Sie, nachdem die Arbeit erfolgreich war, nicht am Anfang des Skripts. Ein Job, der startet, scheitert und trotzdem pingt, ist ein Job, der Gesundheit meldet, während er nichts tut.

Tarifgrenzen gelten für den echten Zeitplan

Das Mindestintervall Ihres Tarifs wird gegen den engsten Abstand geprüft, den der Ausdruck tatsächlich erzeugt, ermittelt über seine nächsten fünfzig Vorkommen statt hergeleitet. So wird * * * * * bei Free genauso abgelehnt wie ein 60-Sekunden-Intervall, und ein unregelmäßiger Zeitplan braucht keinen Sonderfall.

Dieselbe Alarmierung wie überall

E-Mail, Telegram, Slack, Discord oder ein signierter Webhook; Routing pro Check oder ein Organisations-Standard; ein Zustellprotokoll, das zeigt, was gesendet und was übersprungen wurde. So funktioniert die Alarmierung →