1 つのサーバーで 60 のコンテナ
1 つのベアメタルボックスで数十から数百の Hoody コンテナを実行。KSM と BTRFS のデデュプでマージナルコストはほぼゼロ。
コンテナ·スナップショット
use-cases / heartbeat-for-silent-jobs / hero
CRON · NOTIFICATIONS · SILENCE-ALARM
静かなジョブのためのハートビート
ほとんどの監視は「起きたこと」を見ます。あなたが必要としていたのは「起きなかったこと」を見るものでした。2 つの cron エントリ、片方は鼓動し、もう片方は鼓動の不在に耳をすませます。そして、ビーチにいるあなたを見つけ出すページです。
ops · heartbeats
https://ops.containers.hoody.com/heartbeatslive
監視中のジョブ · 直近 24 ビート
6 / 6- backup-prod-db2h 06m ago@daily · 02:00
- rotate-api-keys6m ago0 4 * * 0 · weekly
- cleanup-stale-snapshots3m ago0 * * * * · hourly
- export-stripe-ledger11h 04m ago@daily · 03:30
- renew-letsencrypt1h 12m ago0 1 * * * · daily
- vacuum-postgres2m ago*/15 * * * *
サイレンスウォッチャー
# ビート不在で通知*/15 * * * *curl /silence-check
チャネル
- push · ios
- sms · twilio
- email · ops@
正常 遅延 欠落ウィンドウ: 24 ビート
2 つの cron エントリ · 新規サービスなし · 何も起きないときアラートがあなたを見つけます
use-cases / heartbeat-for-silent-jobs / mechanism
2 つの cron エントリ。一方は「生きている」と告げ、もう一方は「無音」を聴きます。
既存のジョブはそのまま動き続けます。完了後に curl を 1 行追加し、通知エンドポイントへハートビート行を送信します。2 つ目の cron エントリは独自の間隔で動き、無音を確認します。新しいビートがなければ、あなたのスマホへページします。ジョブの成功は静かです。その不在は大音量です。
worker.cron · ジョブ本体
POST · heartbeatschedule0 2 * * *
# 夜間エクスポートの完了後、# ジョブ自身がハートビートを送信。0 2 * * * /usr/local/bin/export.sh \ && curl -fsS -X POST \ https://notify.containers.hoody.com/heartbeats/backup-prod-db
不在こそがシグナルです
watcher.cron · 監視側
GET · silence-checkschedule*/15 * * * *
# 15 分ごとに問い合わせ: ビートはあったか?# 1 時間以上静かなら API が全チャネルへページ。*/15 * * * * curl -fsS \ https://notify.containers.hoody.com/silence-check?\ job=backup-prod-db&max_age=1h
/users/root/entries への POST が 2 件、いずれも 5 フィールドの式です。1 つ目は各スケジュールジョブの後にハートビートを送信。2 つ目は独自の間隔で動き、通知エンドポイントに最後のビートが新鮮かを問い合わせ、必要ならページを発火させます。キューもエージェントもデーモンも不要、もとから存在すべき crontab 行が 2 つあるだけです。
use-cases / heartbeat-for-silent-jobs / powers
不在を監視することはなぜ違うのか
ほとんどの監視ツールは成功経路を見ています。何かが起きたときに知らせてくれます。この形は、何も起きないときにアラートを発します。それこそ、静かなジョブが常に取り逃がすケースです。
FAILURE MODES
静かなクラッシュを捕まえます
ワーカープロセスが起動しなかった場合、再起動された、スクリプトが消えた、クォータが切れたといった状況では、ログも残らずアラートのきっかけもありません。監視 cron はそれでも動き続け、ハートビート行が古くなっていることに気づきます。静かなクラッシュを捕まえる仕掛けは、まさに「静かなもの」に依存しない仕掛けです。
ZERO SURFACE
面倒を見るべき新しいサービスはありません
監視は crontab に 1 行追加するだけで、Healthchecks.io アカウントや CloudWatch アラームではありません。作業と同じコンテナに紐付き、必要なら `expires_at` で消滅し、スタックの他の部分が既に使っている同じ通知 API から読み取ります。
REACHES YOU
重要な瞬間に大音量で
通知エンドポイントは、プッシュ、SMS、メールへページを展開します。すでに信頼しているチャネル群です。ダッシュボードは見守らなくてかまいません。ダッシュボードが自分自身を見守り、沈黙が長く続いたときだけバリ島のビーチにいるあなたを見つけます。
use-cases / heartbeat-for-silent-jobs / capacity
本物の cron、本物の通知
仕組みはそのままの Hoody Cron と Hoody Notifications です。数字はデモランタイムからではなく、ドキュメント化された API 表面に基づきます。
- ALL CRON SYNTAX@daily
標準の 5 フィールド式に加えてマクロ `@hourly`、`@daily`、`@weekly`、`@monthly`、`@yearly` をサポートします。監視側とワーカー側はまったく異なる間隔を持てます。
- AUTO-EXPIRYexpires_at
管理エントリは `expires_at` をサポートしているので、たとえば 1 週間限定の移行ウィンドウのような一時的なハートビートは自動で片付きます。作業と一緒に監視も消えます。
- ISOLATIONper-user
各コンテナは独自の crontab を持ちます。あるテナントのハートビートが別テナントの監視を黙らせることはなく、ジョブを無効化するのは PATCH `enabled: false` の 1 回だけです。
Hoody Cron API の仕様: 5 フィールド式に加えて `@hourly`/`@daily`/`@weekly`/`@monthly`/`@yearly` マクロ、管理エントリにオプションの `expires_at`、ユーザーごとの crontab 分離、PATCH での有効/無効切替に対応しています。
use-cases / heartbeat-for-silent-jobs / punchline
沈黙がアラートになります。
BEFORE · WATCHING THE LOGダッシュボードを開く · 直近のエクスポートを検索する · ため息をつく · 忘れるジョブが落ちたことに気づくのは月曜日になってから
AFTER · WATCHING THE QUIET*/15 * * * * curl /silence-check?job=backup-prod-db沈黙がまだ短いうちに、ページがあなたへ届きます
use-cases / heartbeat-for-silent-jobs / replaces
これが置き換えるもの
ページング付きの cron 監視を求めたときに、つい手を伸ばしてしまう定番ツール群です。それぞれ別アカウント、別請求、別 API です。crontab 2 行と通知エンドポイントが、同じ仕事をします。
- カスタムオーケストレーターcrontab 2 行のために、丸ごとオーケストレーションサービス
- Healthchecks.ioHTTP ハートビートを受けるためだけの SaaS アカウント
- Cronitorコンテナがすでに行えることに対するモニター単位の課金
- Dead Man's Snitchまったく同じパターンが、サブスクリプションとして売られています
- AWS CloudWatch alarms for cron古い 1 行のために Lambda + アラーム + IAM ポリシー
- カスタムハートビート収集スクリプトcron が POST するだけで済む値を記録するための、専用マイクロサービス
use-cases / heartbeat-for-silent-jobs / cta
成功経路を見るのはやめましょう。成功の不在を見るのです。静かな失敗が住んでいるのは、そこだけです。
use-cases / heartbeat-for-silent-jobs / related
他のユースケースを読む
