ウォッチドッグ (watchdog) は英語で 番犬 の意味で、IT では 定期的に生存確認を受け、応答が止まったら相手を強制リセットする仕組み 全般を指します。
ハードウェアの専用回路から OS、コンテナオーケストレータまで、レイヤを問わず同じ思想で実装されています。
まず押さえたいポイント
- 主人 (監視される側) が定期的に
kick/heartbeatを送り、番犬 (watchdog) が受信を確認する - 一定時間 kick が来ないと、番犬がシステムを強制リセットする
- ハードウェア / OS / サービス / コンテナ / アプリケーションなど、いろいろなレイヤに別々の watchdog がいる
- 自分自身が固まると検知できないため、
独立した監視主体を置くことが本質
主な種類
ウォッチドッグは大きく分けて 4 系統あります。
ハードウェアウォッチドッグタイマー(WDT) — マイコンや BMC / IPMI に組み込まれた専用回路。CPU が完全にハングしてもリセットを発火できるOS デーモン— Linux の/dev/watchdogとwatchdogパッケージ、systemd のWatchdogSec設定コンテナ / オーケストレータ— Kubernetes のliveness probe、ECS のヘルスチェックライブラリ— Python のwatchdogパッケージなど (ただしこちらはファイルシステム監視で、上記とは別物)
下に行くほど細かい粒度で観察できる反面、自分が固まると検知できない 弱点があります。本番では複数レイヤで重ねるのが鉄則です。
なぜ「番犬」と呼ぶのか
留守宅に番犬を置いておくと、主人の代わりに不審者に反応してくれます。
同じように、ウォッチドッグは 主人 (プロセス / OS) が倒れたときに代わりに動いて復旧アクションを取る役割を担います。
よくある誤解
ウォッチドッグを入れれば安心、というのは誤りです。再起動で直らない種類の障害 (設定ファイル破損 / ディスクフル / 依存サービスの停止など) では、ウォッチドッグが無限ループの再起動を生むだけで、本質的な復旧にはなりません。
そのため、systemd の StartLimitBurst や Kubernetes の CrashLoopBackOff のように 再起動回数の上限 を設定し、必ずアラート通知とセットで運用するのが定石です。
似た用語との違い
heartbeat— 生存信号そのもの。ウォッチドッグはそれを受ける側health check— 状態確認のための API / 仕組み。ウォッチドッグの判定材料liveness probe— Kubernetes 用語のアプリ層ウォッチドッグkeepalive— TCP やアプリ層で接続を維持するための信号。ウォッチドッグとは別概念だが意図は近い
詳しくは ウォッチドッグとは — 止まったプロセスを検知して再起動させる「番犬」の仕組み で、4 系統それぞれの具体的な動作と、運用上の落とし穴を整理しています。