ハートビート監視とは?cron・バッチ処理の死活監視を設定する方法
ハートビート監視とは
ハートビート監視(heartbeat monitoring)とは、監視したい処理の側から定期的に「生存信号(ハートビート)」を送ってもらい、その信号が届かなくなったことをもって異常と判断する監視手法です。心臓の鼓動(heartbeat)が止まったら異常、というイメージそのままの仕組みです。
通常のWebサイト監視は、監視サービス側から対象へアクセスして応答を確認します。しかしcronジョブや夜間バッチのように「外からアクセスできない処理」は、この方法では監視できません。ハートビート監視は、処理が成功したときだけ信号を送らせることで、処理が動かなかった・失敗したことを検知します。
能動型監視と受動型監視の違い
監視には大きく2つの方向があります。
| 能動型監視(Active / Pull) | 受動型監視(Passive / Push) | |
|---|---|---|
| 信号の向き | 監視サービス → 対象へアクセス | 対象 → 監視サービスへ送信 |
| 代表的な対象 | Webサイト、API、サーバー | cronジョブ、バッチ、定期処理 |
| 検知できる異常 | サイトダウン、応答遅延、SSL期限切れ | 処理の不実行、処理の失敗、停止 |
| 別名 | 外形監視・死活監視 | ハートビート監視・dead man's switch |
HTTP監視やPing監視のような外形監視は能動型です。一方ハートビート監視は受動型で、「来るはずの信号が来ない」ことを異常と見なす点が決定的に違います。両者は対立するものではなく、用途に応じて使い分けます。
なぜcron・バッチ処理にハートビート監視が必要か
定期実行されるバッチ処理は、止まっても誰も気づかないまま放置されがちです。たとえば次のようなケースです。
- 毎晩のデータベースバックアップcronがサーバー再起動以降ずっと止まっていた
- 在庫同期バッチがエラーで落ちていたが、エラーメールも届かず数日気づかなかった
- crontabの記述ミスでジョブが一度も実行されていなかった
これらは「何かが起きた」のではなく「起きるべきことが起きなかった」障害です。能動型監視では検知できません。ハートビート監視なら、処理が正常完了したときだけ信号を送らせ、一定時間その信号が途絶えたらアラートを出せます。
cron・バッチ処理での設定例
ハートビート監視の基本は、処理が成功したときだけ信号URL(ping URL)にアクセスすることです。シェルの && を使えば、前のコマンドが成功した場合のみpingが送られます。
# 毎日3:00にバックアップを実行し、成功時だけハートビートを送信
# バックアップが失敗(非ゼロ終了)するとpingは送られず、間隔超過でDown検知される
0 3 * * * /usr/local/bin/backup.sh && curl -fsS https://miterl.com/heartbeat/YOUR_TOKEN
バッチスクリプトの内部から送信することもできます。処理全体が完走した最後に1行追加するだけです。
import subprocess
import urllib.request
HEARTBEAT_URL = "https://miterl.com/heartbeat/YOUR_TOKEN"
def main():
run_inventory_sync() # 本来の処理
run_report_export()
# ここまで例外なく到達できたときだけ生存信号を送る
urllib.request.urlopen(HEARTBEAT_URL, timeout=10)
if __name__ == "__main__":
main()
処理の途中で例外が発生すれば最後の行に到達せず、pingは送られません。結果として「処理が途中で失敗した」ことも検知できます。
Miterlのハートビートモニター設定手順
Miterlでは、監視種別に「ハートビート」を選ぶだけで専用のping URLが発行されます。
- ダッシュボードで新しいモニターを作成し、種別に ハートビート を選択する
- 想定する実行間隔(例: 1日に1回なら24時間+余裕)を設定する
- モニター詳細ページに表示される ping URL をコピーする
- cronやバッチの末尾に、成功時だけそのURLを叩く処理を追加する
発行されるURLは次の形式です。トークンは推測困難なランダム値なので、URLを知っている処理だけが信号を送れます。
# Miterlが発行するハートビートURL(GETでアクセスするだけ)
# 受信すると monitor は Up 状態になり、最終受信時刻が更新される
curl -fsS https://miterl.com/heartbeat/abc123def456...
# レスポンス: {"ok":true}
信号が届くたびにモニターはUp状態となり、最終受信時刻が記録されます。設定した間隔を過ぎても次の信号が届かなければ、自動的にDown状態へ切り替わり、インシデントが作成されてSlackやメールへアラートが配信されます。
監視間隔のベストプラクティス
ハートビート監視で最も重要なのが間隔(タイムアウト)の設計です。短すぎると正常な遅延で誤検知し、長すぎると障害に気づくのが遅れます。
| 処理の種類 | 実行頻度 | 推奨する監視間隔 |
|---|---|---|
| 1分ごとのキュー処理 | 毎分 | 5〜10分 |
| 1時間ごとの同期バッチ | 毎時 | 90分〜2時間 |
| 日次バックアップ | 1日1回 | 25〜26時間 |
| 週次レポート生成 | 週1回 | 8日前後 |
ポイントは、実行頻度よりも少し長めに設定することです。処理時間のばらつきやサーバー負荷による遅延を吸収できるよう、余裕を持たせます。Miterlは日次・週次のような長い間隔にも対応しているため、低頻度のバッチでも適切なタイムアウトを設定できます。
まとめ
ハートビート監視は、「動いていること」ではなく「動かなかったこと」を検知するための監視手法です。外からアクセスできないcronジョブやバッチ処理の死活監視に欠かせません。
- ハートビート監視は受動型(push型)で、信号の途絶を異常と見なす
- cron・バッチの成功時だけ ping URL を叩くのが基本パターン
- Miterlは種別「ハートビート」を選ぶだけで専用のping URLを発行する
- 監視間隔は実行頻度より少し長めに設定して誤検知を防ぐ
外からアクセスできるWebサイトの監視には外形監視を、障害発生時の初動にはインシデント対応の手順もあわせてご覧ください。設定の詳細はドキュメントを参照し、無料プランでそのまま試せます。