Aller au contenu
use-cases / heartbeat-for-silent-jobs / hero
CRON · NOTIFICATIONS · ALARME-SILENCE

Un battement de cœur pour les jobs silencieux

La plupart des outils de monitoring surveillent ce qui s'est passé. Vous aviez besoin de quelque chose qui surveille ce qui ne s'est pas passé. Deux entrées cron — l'une bat, l'autre écoute l'absence de battement — et la page qui vous trouve sur la plage.

Lire la doc cron
use-cases / heartbeat-for-silent-jobs / mechanism

Deux entrées cron. L'une dit « je suis en vie ». L'autre écoute le néant.

Le job que vous aviez déjà continue son travail. Une fois terminé, il ajoute un curl : une ligne de battement de cœur vers un endpoint de notifications. Une seconde entrée cron tourne à sa propre cadence et vérifie le silence — s'il n'y a pas de battement frais, elle alerte votre téléphone. Le succès du job est silencieux. Son absence est bruyante.

worker.cron · le job
POST · heartbeat
schedule0 2 * * *
# Une fois l'export nocturne terminé,# le job envoie son propre battement de cœur.0 2 * * * /usr/local/bin/export.sh \ && curl -fsS -X POST \ https://notify.containers.hoody.com/heartbeats/backup-prod-db
l'absence est le signal
watcher.cron · l'écouteur
GET · silence-check
schedule*/15 * * * *
# Toutes les 15 minutes, demande : y a-t-il eu un battement ?# Si silence > 1h, l'API alerte tous les canaux.*/15 * * * * curl -fsS \ https://notify.containers.hoody.com/silence-check?\ job=backup-prod-db&max_age=1h

Deux POSTs vers /users/root/entries avec des expressions à cinq champs. Le premier tourne après chaque job planifié et envoie son battement de cœur. Le second tourne à sa propre cadence, demande à l'endpoint de notifications si le dernier battement est suffisamment frais, et déclenche l'alerte sinon. Pas de file d'attente, pas d'agent, pas de daemon — juste deux lignes crontab qui devaient déjà exister.

use-cases / heartbeat-for-silent-jobs / powers

Pourquoi surveiller l'absence est différent

La plupart des outils de monitoring surveillent le chemin du succès : ils alertent quand quelque chose se produit. Cette forme alerte quand rien ne se produit — et c'est le cas que les jobs silencieux perdent toujours.

MODES DE DÉFAILLANCE

Attrape le crash silencieux

Si le processus worker ne démarre jamais — la machine a redémarré, le script a été supprimé, un quota a expiré — il n'y a rien à logger et rien à alerter. Le cron veilleur tourne quand même et remarque que la ligne de battement est périmée. Ce qui attrape le crash silencieux est précisément ce qui ne dépend pas de la chose silencieuse.

SURFACE ZÉRO

Aucun nouveau service à materner

Le moniteur, c'est une ligne crontab supplémentaire, pas un compte Healthchecks.io ni une alarme CloudWatch. Elle est rattachée au même conteneur que le travail, expire avec `expires_at` si vous le souhaitez, et lit depuis la même API de notifications que le reste de votre stack utilise déjà.

VOUS REJOINT

Bruyant quand ça compte

L'endpoint de notifications diffuse l'alerte à travers push, SMS et email — les canaux auxquels vous faites déjà confiance. Vous ne surveillez pas le tableau de bord. Le tableau de bord se surveille lui-même, et vous trouve sur la plage de Bali uniquement quand le silence a trop duré.

use-cases / heartbeat-for-silent-jobs / capacity

Du vrai cron, de vraies notifications

Le mécanisme, c'est du Hoody Cron et du Hoody Notifications standards. Les chiffres viennent de la surface API documentée, pas d'un runtime de démo.

  1. TOUTE LA SYNTAXE CRON@daily

    Expressions standard à 5 champs plus macros — `@hourly`, `@daily`, `@weekly`, `@monthly`, `@yearly`. Le veilleur et le worker peuvent avoir des cadences complètement différentes.

  2. EXPIRATION AUTOexpires_at

    Les entrées managées prennent en charge `expires_at`, donc un battement de cœur temporaire (une fenêtre de migration d'une semaine, par exemple) se nettoie tout seul. Le veilleur disparaît avec le travail.

  3. ISOLATIONpar-utilisateur

    Chaque conteneur a sa propre crontab. Le battement de cœur d'un tenant ne peut pas faire taire le veilleur d'un autre, et désactiver un job se fait via un seul PATCH `enabled: false`.

Limites selon l'API Hoody Cron : expressions à 5 champs plus les macros `@hourly`/`@daily`/`@weekly`/`@monthly`/`@yearly`, `expires_at` optionnel sur les entrées managées, isolation crontab par utilisateur, activation/désactivation via PATCH.

use-cases / heartbeat-for-silent-jobs / punchline

Le silence est désormais une alerte.

AVANT · SURVEILLER LE LOGouvrir le tableau de bord · chercher le dernier export · soupirer · oubliervous ne remarquez le job manquant que le lundi
APRÈS · SURVEILLER LE CALME*/15 * * * * curl /silence-check?job=backup-prod-dbl'alerte vous rejoint pendant que le silence est encore court
Lire la doc cron
use-cases / heartbeat-for-silent-jobs / replaces

Ce que cela remplace

Les outils standards vers lesquels vous vous tournez quand vous voulez un moniteur cron avec alerte. Chacun est un compte séparé, une facture séparée, une API séparée. Deux lignes crontab et l'endpoint de notifications font le même travail.

  • orchestrateurs sur mesureDes services d'orchestration entiers pour ce qui tient en deux lignes crontab
  • Healthchecks.ioUn compte SaaS rien que pour recevoir un battement de cœur HTTP
  • CronitorTarification au moniteur pour quelque chose que votre conteneur fait déjà
  • Dead Man's SnitchLe pattern exact, vendu en abonnement
  • alarmes AWS CloudWatch pour cronLambda + alarmes + politiques IAM pour une ligne périmée
  • scripts custom de collecte de battementsUn microservice pour logger une valeur que le cron pourrait simplement POSTer
use-cases / heartbeat-for-silent-jobs / cta

Arrêtez de surveiller le chemin du succès. Surveillez l'absence de succès — c'est le seul endroit où vivent les défaillances silencieuses.

Lire la doc cron
use-cases / heartbeat-for-silent-jobs / related

Découvrez les autres