「Cron Job의静かな死」という恐怖
システム運用において、エンジニアなら誰でもいくつかのCron Jobを設定しているはずです。午前2時のデータベースバックアップから、古いログの削除、サーバー間のデータ同期まで。通常、すべては非常に穏やかに動作しているように見えます。しかし、ある日突然、上司から「先週 Percents のデータを復旧してくれ」と頼まれ、そこで初めて愕然とするのです。スクリプトがエラーを起こし、3ヶ月前から停止していたことに…。
Cron Jobの最大の問題は、エラーが「静かに」発生すること(サイレント・フェイailure)です。スクリプトが失敗しても、人目に付かない場所にログを書き込んだり、誰も読まないroot宛てのメールボックスに通知を送ったりするだけで、気づくのが遅れがちです。たまにSSHでサーバーに入って手動でチェックする代わりに、より能動的な監視ソリューションが必要です。
仕組みの違い:なぜPrometheusではないのか?
PrometheusやZabbixのようなツールは、通常 Push または Pull 方式でメトリクスを取得します。しかし、数秒間だけ実行されて終了するCron Jobのようなタスクの場合、従来の監視設定は煩雑になりがちで、情報の取りこぼしも発生しやすくなります。
Healthchecks.ioは Dead Man’s Snitch(デッドマンズ・スニッチ:死者の密告)というアプローチを取ります。監視ツール側がサーバーに「大丈夫か?」と尋ねるのではなく、スクリプト側から「実行完了。異常なし」と報告させる仕組みです。予定時間を過ぎてもHealthchecks.ioが「ping」信号を受け取らなかった場合、異常が発生したと判断し、即座にアラートを鳴らします。
このツールの無料プランでは最大20個のチェックが可能で、個人利用や小規模なスタートアップには十分な内容です。Bashスクリプト、Python、Node.jsなどに、わずか数行のコードで統合できます。
5分でできる実践的な導入
まずは healthchecks.io でアカウントを作成します。新しい「Check」を作成すると、https://hc-ping.com/your-unique-uuid のような一意のURLが発行されます。
1. 基本的なcurlコマンドの使用
最も簡単な方法は、Bashスクリプトの最後に curl コマンドを挿入することです。例えば、以下のようなバックアップスクリプトがあるとします。
#!/bin/bash
# データベースのバックアップを実行
tar -czf /backups/db_$(date +%F).tar.gz /var/lib/mysql
# バックアップが成功した場合($? == 0)、ping信号を送信
if [ $? -eq 0 ]; then
curl -fsS --retry 3 https://hc-ping.com/your-unique-uuid > /dev/null
fi
--retry 3 パラメータを忘れないでください。これは、サーバーのネットワークが一瞬不安定になった際の誤報を防ぐのに役立ちます。
2. 成功と失敗のステータスを区別する
良い知らせだけを報告するのではなく、Healthchecks.ioではURLの末尾に /fail を付けることでエラーを報告できます。これにより、タイムアウトを待たずにスクリプトのクラッシュを即座に把握できます。
#!/bin/bash
/usr/bin/python3 /home/user/sync_data.py
if [ $? -eq 0 ]; then
# 成功を報告
curl -fsS --retry 3 https://hc-ping.com/your-unique-uuid
else
# 失敗を報告
curl -fsS --retry 3 https://hc-ping.com/your-unique-uuid/fail
fi
3. 実行時間の測定 (Execution Time)
スクリプトファイルを修正したくない場合は、crontab内で直接コマンドをラップすることもできます。これは、ジョブの実行時間も監視したい時によく使う方法です。
# crontab -e での設定
0 2 * * * curl -fsS --retry 3 https://hc-ping.com/your-unique-uuid/start && /path/to/script.sh && curl -fsS --retry 3 https://hc-ping.com/your-unique-uuid
/start 信号を送信することで、システムはジョブが現在実行中であることを認識します。通常は5分で終わるスクリプトが今日は2時間かかっているといった場合、サーバーの過負荷やフリーズの兆候として捉えることができます。
誤報を防ぐためのスケジュール設定
通知の嵐(アラート疲れ)に陥らないよう、ダッシュボードで2つのパラメータを調整する必要があります。
- Period: 実行頻度(例:1 day)。
- Grace Period: 猶予期間(例:30 minutes)。
私のこれまでの経験から言うと、Grace Periodは余裕を持って設定することをお勧めします。バックアップスクリプトが10分で終わる予定なら、猶予は30〜40分に設定しましょう。サーバーが高負荷の時にスクリプトの完了が少し遅れるのはよくあることです。設定を詰めすぎて、深夜に叩き起こされるような事態は避けましょう。
Telegramでアラートを受け取る
Healthchecks.ioは、Slack、Discord、Webhookなど非常に多くのチャンネルをサポートしています。個人的には、メッセージの配信速度が非常に速く、完全に無料であるTelegramを優先して使用しています。
Integrations セクションからTelegramを選択し、ガイドに従ってボットとチャットするだけです。これで、スクリプトに異変があれば、詳細な情報とともにスマホが震えて知らせてくれます。システムを完全にコントロールできているという感覚は、大きな安心感に繋がります。
運用におけるいくつかの注意点
数年間の使用を経て得られた、3つの小さな教訓を共有します:
- エラーログを送信する: POSTメソッドを使用して、ログ出力をHealthchecks.ioに送信できます。ウェブ上でチェックすれば、SSHでログインしなくてもスクリプトが失敗した理由がすぐに分かります。
- 自前でサーバーを構築する: 銀行や高いセキュリティが求められるプロジェクトの場合は、Dockerを使用してHealthchecks.ioをセルフホストしましょう。ソースコードはすべてオープンソースとして公開されています。
- 監視するジョブを厳選する: 何でもかんでもアラートを設定するのはやめましょう。バックアップ、セキュリティスキャン、データ同期など、重要なものに集中することで、通知への慣れを防ぐことができます。
Cron Jobの監視に、必ずしも巨大なシステムは必要ありません。シンプルなcurlコマンドと鋭い「密告者」がいれば、毎晩安心して眠りにつくことができるのです。

