Zum Hauptinhalt springen

Heartbeat-Checks

Erfahren Sie, wenn ein geplanter Job nicht mehr läuft

Ein Cronjob, der nicht mehr läuft, erzeugt keinen Fehler und hinterlässt nichts, was sich abfragen ließe, denn was Sie prüfen wollen, ist ein Job, der gar nicht da ist. Ein Heartbeat kehrt die Richtung um: Ihr Job ruft eine URL auf, die wir ihm geben, und wir sagen Ihnen Bescheid, wenn die Aufrufe ausbleiben.

Kostenlos starten

Der Ausfall, den nichts meldet

Ein Job, der laut scheitert, ist der einfache Fall. Er endet mit einem Exit-Code ungleich null, irgendetwas fängt das ab, jemand wird alarmiert. Teuer wird es, wenn der Job gar nicht mehr ausgeführt wird, weil sein Eintrag beim Bearbeiten der Crontab verloren ging oder der Container, in dem er lief, nicht mehr startet. Dann gibt es keinen Prozess mehr, der scheitern könnte, also wird nichts gemeldet, und das Dashboard bleibt so grün wie zu der Zeit, als der Job noch funktionierte. GitLab hat das bei seinem nächtlichen Backup genau so erlebt und es erst Monate später bemerkt.

Periode und Kulanzzeit, passend zu dem, was der Job wirklich tut

Sie legen fest, wie oft Sie den Ping erwarten und wie viel Verspätung er haben darf, bevor er als fehlgeschlagen gilt. Ein stündlicher Job mit zehn Minuten Kulanzzeit gilt zehn Minuten nach dem verpassten Lauf als ausgefallen, und der Alarm folgt, sobald die eingestellte Zahl an Bestätigungen erreicht ist. Setzen Sie die Periode darauf, wie oft der Job tatsächlich läuft, nicht wie oft Sie es sich wünschen: Ist die Periode kürzer als der echte Takt, ist jeder Lauf schon verspätet, wenn der nächste beginnt, und der Monitor springt die ganze Nacht zwischen Ausfall und Erholung hin und her, bei einem Job, dem nichts fehlt.

Die Periode muss nicht auf Anhieb stimmen

Sobald fünf Abstände zwischen erfolgreichen Pings erfasst sind, vergleicht der Monitor, was Sie angegeben haben, mit dem, was der Job wirklich tut, und meldet sich, wenn beides nicht zusammenpasst, in beide Richtungen. Ein stündlicher Job bekommt diese Einschätzung noch am selben Tag, ein nächtlicher nach etwa fünf Tagen. Eine zu knappe Periode alarmiert Sie grundlos. Eine zu großzügige lässt einen toten Job länger unbemerkt, als nötig wäre.

Mehr sagen als „lebt noch“

Die bloße URL sagt, dass der Job das Ende erreicht hat. Ein Pfadsegment dahinter sagt, was der Ping bedeutet. Ein Aufruf von /start vor der Arbeit sorgt dafür, dass der Lauf gemessen wird. Übergeben Sie stattdessen den Exit-Code, lässt ein Wert ungleich null den Monitor sofort ausfallen, statt das Ende der Periode abzuwarten, und das ist der Unterschied, ob Sie um 03:05 oder um 04:15 davon erfahren. Die ersten 4 KB eines POST-Bodys werden als Ausgabe dieses Laufs gespeichert. Leiten Sie also das Ende des Logs hinein, stehen der Exit-Code und die Zeilen rund um den Fehler beieinander, statt auf einer Maschine, die Sie erst suchen müssen.

Der Job, der startete und hängen blieb

Ein einfacher Heartbeat sieht diesen Fall nicht. Der Job hat begonnen, hängt und wird nie wieder pingen. Kombinieren Sie /start mit einem Abschluss-Ping, erhält der Lauf eine Dauer, und eine maximale Laufzeit fängt ihn dann ab, während er noch hängt. Ohne das warten Sie die ganze Periode ab, bevor sich etwas meldet, und bei einem nächtlichen Job ist das ein Tag.

Die Ping-URL ist ein Zugangsschlüssel

Wer sie kennt, kann den Job als gesund markieren, und damit kann jeder, der sie kennt, einen echten Ausfall unsichtbar halten. Ihrem Zweck nach landet sie in Crontabs, CI-Konfigurationen und Runbooks, deshalb muss sie rotiert werden, wenn sie durchsickert oder wenn jemand geht, der sie kannte. Rotieren Sie sie auf der Monitorseite oder über die API, und der Monitor behält seine Störungen, seinen Verlauf, seine Freigabelinks und seinen Platz auf der Statusseite. Die alte URL funktioniert standardmäßig noch 24 Stunden weiter, denn eine URL, die sofort abgeschaltet wird, schlägt keinen Alarm, sie verstummt nur. Behalten Sie im Blick, wann die alte zuletzt genutzt wurde, und beenden Sie die Überlappung früher. Ist sie wirklich durchgesickert, beenden Sie sie sofort.

Neben den Checks, die Ihre Eingangstür bewachen

Ein Heartbeat weiß genau eines: ob sich Ihr Job gemeldet hat. Dass Ihre Website ausgefallen ist, kann er Ihnen nie sagen. Er steht in derselben Monitorliste wie die HTTP-, TLS- und Domain-Checks, die die Eingangstür bewachen, und er erreicht dieselbe Statusseite und dieselben Alarmkanäle. Heartbeat ist hier eine der neun Prüfarten, kein separates Tool, das Sie zusätzlich betreiben müssen.

Ein nächtliches Backup, das sich selbst meldet

curl -fsS $URL/start          # vor der Arbeit

./nightly-backup.sh > backup.log 2>&1
code=$?

tail -c 4000 backup.log | curl -fsS --data-binary @- "$URL/$code"

Häufige Fragen

Wie überwache ich einen Cronjob?
Legen Sie einen Heartbeat-Monitor an, der eine Ping-URL erzeugt, und rufen Sie diese URL am Ende jedes erfolgreichen Laufs auf. Meist ist curl -fsS $URL am Ende des Jobs schon die ganze Änderung. Sie legen fest, wie oft Sie den Ping erwarten und wie viel Verspätung er haben darf, und der Monitor alarmiert, wenn die Aufrufe ausbleiben.
Warum scheitern Cronjobs, ohne dass jemand alarmiert wird?
Weil ein Job, der nie ausgeführt wird, nichts erzeugt, was sich abfangen ließe. Fehleralarme lösen bei einem Job aus, der läuft und scheitert. Sie können nicht auslösen, wenn ein Eintrag beim Bearbeiten der Crontab verloren ging oder ein Container nicht mehr startet. Es gibt keine Anfrage, die man beobachten, und keinen Exit-Code, den man auslesen könnte, also muss der Heartbeat vom Job selbst kommen.
Welche Periode und Kulanzzeit sollte ich wählen?
Die Periode ist, wie oft der Job tatsächlich läuft, nicht wie oft Sie es gern hätten. Ist sie kürzer als der echte Takt, ist jeder Lauf schon verspätet, wenn der nächste beginnt, und der Monitor springt bei einem gesunden Job die ganze Nacht hin und her. Sobald fünf Abstände zwischen erfolgreichen Pings erfasst sind, vergleicht der Monitor Ihre angegebene Periode mit der echten und sagt Ihnen, wenn beide nicht zusammenpassen; bei einem stündlichen Job ist das noch am selben Tag.
Erkennt es einen Job, der startet und dann hängen bleibt?
Ja, mit einem Startsignal und einer maximalen Laufzeit. Rufen Sie /start vor der Arbeit auf, schließen Sie mit dem Exit-Code ab, und der Lauf wird gemessen. Ein Job, der gestartet ist und nie fertig wird, fällt auf, während er noch hängt, nicht erst eine ganze Periode später.
Kann ich sehen, warum der Job gescheitert ist?
Ja. Übergeben Sie beim Abschluss-Ping den Exit-Code und senden Sie das Log per POST mit. Der Monitor speichert die ersten 4 KB dieses Bodys. Leiten Sie also das Ende des Logs hinein, dann steht beim letzten Fehlschlag der Exit-Code neben den Zeilen rund um den Fehler, lesbar auf der Monitorseite statt auf der Maschine, auf der der Job lief.
Was passiert, wenn die Ping-URL durchsickert?
Rotieren Sie sie auf der Monitorseite oder über die API. Wer die URL kennt, kann den Job als gesund markieren und damit einen echten Ausfall unsichtbar halten. Bei der Rotation behält der Monitor seine Störungen, seinen Verlauf, seine Freigabelinks und seinen Platz auf der Statusseite. Die alte URL funktioniert standardmäßig noch 24 Stunden weiter, damit nichts unbemerkt verstummt, und Sie können diese Überlappung sofort beenden, wenn die URL wirklich durchgesickert ist.

Auf einen Blick

  • Richtung Ihr Job ruft uns auf
  • Signale Start, Erfolg, Fehlschlag, Exit-Code
  • Ausgabe des Laufs POST-Body wird pro Lauf gespeichert
  • Verspäteter Job Periode plus Kulanzzeit
  • Ping-URL rotierbar, 24 Std. Überlappung
  • Einstiegspreis kostenlos, ohne Karte

Links

In unter 5 Minuten startklar.

Kostenlos starten

Funktionen · Preise · Notizen