
Soixante conteneurs sur un seul serveur
Une machine bare-metal exécute des dizaines à des centaines de conteneurs Hoody. La dédupplication KSM et BTRFS rend le coût marginal quasi nul.
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.
deux entrées cron · zéro nouveau service · l'alerte vous trouve quand rien ne se passe
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.
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.
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.
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.
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à.
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é.
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.
Expressions standard à 5 champs plus macros — `@hourly`, `@daily`, `@weekly`, `@monthly`, `@yearly`. Le veilleur et le worker peuvent avoir des cadences complètement différentes.
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.
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.
Le silence est désormais une alerte.
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.
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.