【ITニュース解説】Healthchecks: Monitor Cron Jobs & Backups (Dead Man's Switch)

システム運用において最も危険な事態の一つは、サイレント障害と呼ばれる「問題が起きているにもかかわらず、誰もそれに気づかない」状態である。例えば、重要なデータのバックアップが何週間も停止しているのに、実際にデータが必要になるまで誰もその事実に気づかないといったケースがこれにあたる。このような状況は、取り返しのつかないデータ損失につながりかねない。今回解説する「Healthchecks」は、このようなサイレント障害を防ぐための強力なツールであり、特にシステムエンジニアを目指す人にとって、その概念と導入方法は非常に価値のある知識となる。

従来のシステム監視ツール「Uptime Kuma」などがサービスの稼働状態（サービスが「起動しているか」）を監視するのに対し、Healthchecksはジョブの実行状態（ジョブが「適切に実行されたか」）を監視するという点で根本的に異なる。Healthchecksの核となる考え方は「デッドマンズスイッチ」と呼ばれるものだ。これは、列車などで運転士に異常があった場合に自動的に列車を停止させる装置から来ている。通常は信号の「存在」で稼働を確認するが、デッドマンズスイッチは信号の「停止」や「不在」を異常と判断して警報を出す。Healthchecksも同様に、監視対象のジョブが「正常に完了した」という信号を定期的に送ってこない場合に、異常を検知してアラートを発する仕組みなのである。つまり、ジョブがクラッシュしたり、サーバーが停止したり、あるいはcronジョブの設定自体がなくなったりして、所定の時間内に信号が届かなければ、Healthchecksが問題を教えてくれるのだ。

このHealthchecksサーバーを自分で構築し、運用することで、日々のResticバックアップ、データベースのダンプ、その他の繰り返し実行される重要なタスクが確実に動作しているかを確認できるようになる。具体的には、Docker ComposeとリバースプロキシのTraefikが動作しているサーバーと、そのサーバーを指すサブドメインがあれば、すぐにでも構築を始められる。

構築はいくつかのステップに分かれる。まず、Healthchecksサーバーを動かすための設定ファイル「compose.yaml」を作成する。これはDockerコンテナと呼ばれる仮想的な環境でアプリケーションを動かすための設定を記述するファイルだ。このファイルの中で、HealthchecksのDockerイメージ（healthchecks/healthchecks:v4.4）を指定し、アプリケーションがデータを保存する場所（./data:/data）や、WebサイトのURL（SITE_ROOT: https://YOUR_DOMAIN）、秘密鍵（SECRET_KEY）などの環境変数を設定する。特に重要な注意点として、データベースにSQLiteを使う場合、DB_NAME: /data/hc.sqliteという設定が必須であり、これがないとデータベースファイルを開けずにコンテナが起動しない。また、SITE_NAMEなどの設定値には、日本語のような非ASCII文字を使用するとエラーが発生する可能性があるため、英数字のみを使うように気をつけるべきだ。Traefikとの連携のためには、Dockerネットワークの設定や、TraefikがHealthchecksのサービスを認識するためのラベルを正確に記述する必要がある。

compose.yamlの準備ができたら、docker compose up -dコマンドでHealthchecksサーバーを起動する。コンテナが正常に起動し、サービスが利用可能になるまでには少し時間がかかる。その後、初めてHealthchecksにアクセスするために管理者アカウントを作成する必要がある。これはWebインターフェースからは行えず、docker compose exec healthchecks python manage.py createsuperuserというコマンドをサーバー上で実行し、メールアドレスとパスワードを設定して作成する。既存の公式ドキュメントの中には環境変数で管理者アカウントを設定できると誤って説明されているものもあるが、このコマンドによる作成が確実な方法となる。

管理者アカウントでログインすると、Webインターフェースから「プロジェクト」を作成し、その中に監視したい「チェック」を登録する。チェックには「毎日バックアップを実行する」といった具体的な名前を付け、そのジョブが実行されるべき間隔（期間、例えば「1日」）と、その期間を過ぎてからどれくらいの猶予時間（例えば「1時間」）を設けてからアラートを出すかを設定する。それぞれのチェックには固有の「ping URL」が割り当てられる。

いよいよ監視の本質となる部分だが、監視したいジョブのスクリプトの最後に、このping URLを呼び出すコマンドを追加する。最も簡単な方法は、curl -fsS -m 10 --retry 5 https://YOUR_DOMAIN/ping/YOUR_CHECK_UUIDのようなコマンドを追記することだ。これにより、ジョブが正常に完了した後にHealthchecksに「私は無事に終わりました」という信号を送る。さらに高度な使い方として、ジョブの終了コード（正常終了なら0、エラーならそれ以外の数値）をHealthchecksに伝えることで、ジョブがエラーで終わった場合も即座に通知を受け取れるようになる。ジョブの開始時と終了時にそれぞれ異なるURLへpingを送ることで、ジョブの実行時間も計測でき、バックアップが遅くなっているといった傾向も把握できる。

アラートは通知されて初めて意味がある。Healthchecksはメール、ntfy、Telegram、Webhooksなど、様々な通知チャネルに対応している。これらの「統合」を設定し、作成したチェックに割り当てることで、ジョブが予定通りに実行されなかった場合に、設定した方法で通知を受け取れるようになる。特に、自分でサーバーを運用している場合、ntfyのようなプッシュ通知サービスは手軽で便利だ。

運用中に問題が発生した場合の対処法も覚えておくと良い。例えば、コンテナが「データベースファイルを開けない」というエラーで起動しない場合は、compose.yamlのDB_NAMEパスが正しく指定されているか、またはデータディレクトリの権限が適切かを確認する必要がある。WebページがHTTP 500エラーを返す場合は、SITE_NAMEなどの環境変数に非ASCII文字が含まれていないかを確認し、デバッグモードを一時的に有効にして原因を特定することも可能だ。ログインやフォーム送信時にCSRFエラーが発生する場合は、CSRF_TRUSTED_ORIGINSとALLOWED_HOSTSの設定がサブドメインと正確に一致しているか確認する。ジョブが実行されているのにHealthchecksのチェックが「緑色」にならない場合は、curlコマンドが実際に実行されているか、または正しいUUIDのURLにpingを送っているかを確認し、Healthchecksの詳細ページでpingの履歴を確認する。通知が届かない場合は、通知チャネルが設定され、チェックに割り当てられているか、または（メールの場合）SMTP設定が正しく行われているかを確認する。

Healthchecksサーバー自体のメンテナンスも重要だ。定期的にDockerイメージのバージョンを最新に更新し、データベースは自動でマイグレーションされるため手間はかからない。Healthchecksのすべての状態はdata/ディレクトリ内のSQLiteファイルに保存されるため、このファイルを定期的にバックアップに含めることが肝心だ。また、Healthchecks自身が停止してしまうと、他のジョブの監視もできなくなるため、Healthchecksサーバーが稼働しているかを「Uptime Kuma」のような別の監視ツールで確認する「監視の監視」を行うことで、より堅牢なシステム運用が実現できる。

このように、Healthchecksはサイレント障害という見えない脅威からシステムを守り、安定した運用を支えるための必須ツールだ。システムエンジニアを目指す上で、このような監視の概念と具体的な実装方法を理解することは、非常に重要なスキルとなるだろう。