この記事は Zenn にも投稿しています。内容は同じです。

結論

「その瞬間、生きているか」を見る監視だけでは、定期ジョブの死を検知できません。

HTTPで叩いて200が返るか、ポートが開いているか、pingが返るか。これらは全部「今」しか見ていません。

そして、バックアップが取れていないことは、失われて初めて気づきます。 その「初めて」は最悪のタイミングで来ます。復元が必要になったときです。

対処は Push型のデッドマンスイッチ です。

# ジョブが成功したときだけ、ハートビートを送る
30 4 * * * root /opt/job.py >> /var/log/job.log 2>&1 \
  && curl -fsS https://uptime.example.com/api/push/aBcD1234EfGh

以下は、そこに至った経緯と、実装するときに踏んだ罠の記録です。

何が起きたか

自宅サーバーで、台帳（NetBox）とその自動化が 7時間停止していました。

私は監視を25件入れていました。それでも気づけませんでした。

原因は、Docker Compose に restart ポリシーが書かれていなかったことです。ホストを再起動したとき、コンテナが Exited (255) のまま復帰しませんでした。

厄介なのは、Dockerサービス自体は enabled かつ active だったことです。一見すると正常に見えます。

これ自体も罠なのですが、本題はここではありません。「もし鳴らないタイプの死に方だったら、永久に気づけなかった」 という点です。

25件すべてが「今」しか見ていなかった

自分の監視設定を見直して、気づきました。

HTTPで叩いて200が返るか
TCPポートが開いているか
pingが返るか

全部「今この瞬間、生きているか」です。

これで検知できないものがあります。

死に方	検知できるか
サービスが落ちた	✅ できる
ホストが落ちた	✅ できる
定期ジョブが失敗し続けている	❌ できない
バックアップが取れていない	❌ できない

定期ジョブは、動いていなくても何も落ちません。

Webサービスは元気にHTTP 200を返し続けます。監視は全部グリーンです。ただ、バックアップだけが取られていない。

そして次にバックアップが必要になったとき——ディスクが飛んだとき、操作を間違えたとき——そこで初めて気づきます。

デッドマンスイッチ

考え方を逆転させます。

Pull型（従来）: 監視側が「生きてるか？」と聞きに行く
Push型        : 監視される側が「生きてます」と定期的に報告する
                → 一定時間報告が来なければ異常と判断する

デッドマンスイッチは、鉄道の運転士が握り続けていないと自動的にブレーキがかかる装置のことです。「何もしない」ことが異常の合図になります。

監視に置き換えると、ジョブが成功したときだけハートビートを送り、途絶えたら鳴らすという形になります。

実装

Uptime Kuma には Push型のモニターがあります。指定されたURLを叩くとハートビートとして記録され、一定時間来なければDOWN判定になります。

cronの末尾に足すだけです。

# /etc/cron.d/example
30 4 * * * root /opt/nb2kuma/sync.py >> /var/log/sync.log 2>&1 && /opt/push.sh nb2kuma-sync

ポイントは && です。

成功 → ハートビート送信 → 監視側は正常と判断
失敗 → ハートビート無し → 一定時間後にDOWN判定 → 通知

コマンドが失敗すれば、ハートビートは飛びません。「失敗を検知する」のではなく 成功が報告されないことを検知する という設計です。

⚠️ `curl` はHTTPエラーでも成功を返す

ここで踏みました。

# ❌ これだと失敗しても && が成立する
... && curl -sS https://uptime.example.com/api/push/aBcD1234EfGh

デフォルトの curl は、HTTPが500を返しても終了コード0（成功）を返します。

つまり、Uptime Kuma 側が落ちていても、ハートビートを送ったつもりになります。 さらに悪いことに、ジョブ本体が成功していれば && は成立するので、壊れていることに気づけません。

# ✅ -f を付けるとHTTPエラーを失敗として扱う
... && curl -fsS https://uptime.example.com/api/push/aBcD1234EfGh

監視の仕組み自体が壊れていても気づけない、というのが最も危険な状態です。
デッドマンスイッチを入れるときは、その通知経路が本当に生きているかを一度は確かめてください。私は意図的にジョブを失敗させて、通知が来ることを確認しました。

許容時間は「周期の2倍強」にする

「何秒ハートビートが来なければ鳴らすか」の設定が重要です。

ジョブ	周期	許容時間
新規端末の検知	30分	4,200秒（1.2時間）
ログの書き出し	3時間	23,400秒（6.5時間）
DBダンプ	24時間	100,800秒（28時間）

1回コケた程度では鳴らさず、2回連続で落ちたら鳴るという設計です。

理由は単純で、ネットワークの一時的な不調で毎回鳴ると、通知そのものを無視するようになるからです。

鳴ったら必ず何かある、という状態を保つこと。

これが監視で一番大事だと思っています。オオカミ少年になった監視は、無いのと同じです。

「バックアップがある」と「使える」は違う

デッドマンスイッチを入れると、ジョブが走ったことは保証されます。しかし成果物が正しいことは保証されません。

実際に踏みました。DBダンプのスクリプトが、失敗して0バイトのファイルを作り、それが前回の正常なダンプを上書きしていました。

pg_dump -Fc ... > "$DUMP"     # 失敗しても空ファイルはできる
cp "$DUMP" "$NAS/"            # 空ファイルで上書き

バックアップは存在します。中身がないだけです。

対処

pg_dump -Fc ... > "$DUMP"

# サイズが小さすぎたら破棄して、ジョブごと失敗させる
if [ "$(stat -c%s "$DUMP")" -lt 10000 ]; then
    rm -f "$DUMP"
    exit 1        # ← ハートビートも送られない
fi

cp "$DUMP" "$NAS/"

失敗したときに、前の成果物を壊さない。 これがバックアップスクリプトの最低条件です。

そして exit 1 にすることで、デッドマンスイッチが検知してくれます。成果物の検証とハートビートを繋げるのがポイントです。

運用ルールにした

この仕組みを作ったあと、ルールを決めました。

cronを1つ足したら、必ず3点セットで用意する。

ジョブ本体（失敗時に前の成果物を壊さない作り）

Push型の監視（&& push.sh <名前>）

logrotate（新しくログを吐くなら）

3つ目も実際に必要でした。放置すると、気づいたときにはディスクが埋まっています。しかもログでディスクフルになると、他のサービスまで巻き込みます。

ジョブを追加した日に設定するのが一番安いタイミングです。後から「そういえばログが」となる頃には、既に肥大化しています。

実際に何を監視対象にしたか

新規端末の検知           30分ごと
攻撃アラートの差分通知    30分ごと
ルーターログの書き出し    3時間ごと
台帳のDBダンプ           1日1回
台帳→監視の同期          1日1回
台帳の乖離検出           1日1回
syslogのNAS転送          1日1回

バックアップと攻撃検知を最優先で入れました。 どちらも「失われて初めて気づく」類だからです。

逆に、Webサービスの死活は従来のPull型のままです。落ちれば即座に分かるので、Push型にする必要がありません。

すべてをPush型にする必要はありません。
「落ちたら分かるもの」はPull型のまま、「黙って死ぬもの」だけPush型にする、という使い分けです。

監視ツールを2つ入れるなら、役割を分ける

余談ですが、関連するので書いておきます。

Uptime Kuma のあとに Prometheus + Grafana も入れました。リソースの傾向を見たかったからです。

ここで問題になるのが、両方ともアラート機能を持っていることです。

ツール	役割
Uptime Kuma	通知専任。すべてのアラートはここから出す
Grafana	可視化専任。アラートは一切持たせない

両方にアラートを持たせると、こうなります。

同じ障害で通知が2回来る
どちらの設定を直せばいいか分からなくなる
片方だけ設定して、もう片方を忘れる

通知の入口は1つにする。 規模が小さいうちに決めておかないと、後から統合するのが非常に面倒です。

Grafanaのアラート機能は強力ですが、強力だから使うという判断は危険です。「この機能が無いと困るか？」を先に問うと、私の場合は「Kumaで足りている」でした。

まとめ


問題	「その瞬間の生死」を見る監視では、定期ジョブの死を検知できない
対処	Push型のデッドマンスイッチ。成功時だけハートビートを送り、途絶えたら鳴らす
注意①	`curl` に `-f` を付ける（HTTPエラーで成功を返してしまう）
注意②	許容時間は周期の2倍強（オオカミ少年にしない）
注意③	成果物の検証と `exit 1` を繋げる（「ある」と「使える」は別）
注意④	全部をPush型にしない。黙って死ぬものだけ

「監視を入れている」ことと「異常に気づける」ことは、別の話でした。

同じような失敗を57件ぶん書きました

この件も含めて、自宅ラボを組むなかで踏んだ地雷を57件、症状から逆引きできる形で本にまとめました。

📕 自宅ラボ 0→100 ── Proxmoxで作る、止まらない自宅インフラ

この記事の話は、本の付録では 型②「エラーにならないのに動いていない」 に分類しています。他にも「型①設定済みに見えるのに機能しない」「型③半分だけ動く」「型⑥検証方法そのものが間違っていた」といった分け方で整理しました。

第0章（設計の5原則）と更新履歴は無料で読めます。