Uptime Kumaで自宅サーバーの死活監視を作る：監視対象の決め方とスマホ通知まで

自宅サーバーが落ちたことに気づくきっかけが、家族からの「ネット繋がらないんだけど」になっている——これは自宅インフラを一通り組んだ人がだいたい通る道です。とくに AdGuard Home のような DNS を自宅で受けていると、サーバー 1 台の停止が家中の停止になります。

そこで入れるのが死活監視です。今回は Docker で 1 コンテナ、設定もブラウザで完結する Uptime Kuma を使います。先に結論を 3 つ書きます。

• 監視ツールは、監視対象と同じ機械に置かない（ここを間違えると監視が無意味になります）
• 監視対象は 「ホスト → サービス → 外から」の 3 層で決める
• 通知は スマホに確実に届く経路を 1 本作る。増やすほど無視するようになる

なぜ Uptime Kuma なのか

「自宅サーバーの監視」で並んで名前が挙がるのが Prometheus + Grafana ですが、あちらは CPU・温度・ディスクの推移を可視化するのが主役です。構成要素も多くなります。

対して Uptime Kuma は「落ちたら鳴らす」に振り切ったツールです。データは SQLite に持つので外部 DB も要らず、監視の追加はブラウザのフォームで完結します。まずは落ちたことに気づける状態を作り、グラフが欲しくなったら後から Grafana を足す、という順番が現実的です。

ステップ1：どこに置くかを先に決める

構築より先にこれを決めます。Proxmox のミニPC 1 台に全部を載せている構成で、その上の VM に監視を置くと、ミニPC ごと落ちたときに誰も通知を出しません。 監視対象と運命を共にするからです。

現実的な置き場所は次のどちらかです。

• 別の小さい機械に置く：ラズパイ 1 台で十分です。監視だけなら消費電力は数 W で済みます。余っている Pi 4があれば、それが一番手軽な監視専用機になります
• 家の外に置く：VPS に立て、Tailscale 経由で自宅の機器を見る形です。回線ごと落ちたときも検知できるのが利点です

なお、停電で家全体が落ちればどちらにせよ自宅側からは通知できません。停電を含めて守りたいなら、UPSでサーバーとルーター・ONU も一緒に延命する必要があります。監視だけで解ける話ではない、と割り切ったほうが構成がすっきりします。

ステップ2：Docker Compose で立てる

置き場所が決まったら、構築は数分です。

services:
  uptime-kuma:
    image: louislam/uptime-kuma:1
    container_name: uptime-kuma
    restart: unless-stopped
    ports:
      - "3001:3001"
    volumes:
      - ./data:/app/data

docker compose up -d のあと、http://<ホストのIP>:3001 を開くと初回に管理者アカウントを作る画面が出ます。ここで作ったアカウントがそのまま管理者なので、先に誰かに開かれないよう、立ち上げたらすぐ作成まで済ませてください。

外部公開は基本的に不要です。外から見たいなら Tailscale か、逆プロキシ経由にします。

ステップ3：監視対象を 3 層で決める

監視は「入れられるだけ入れる」と必ず破綻します。判断基準はひとつ、落ちたときに自分が何か対応するものだけです。対応しないものは監視しません。

そのうえで、次の 3 層で拾うと漏れが減ります。

ホストだけ見て満足しないのがコツです。Ping が返るのにコンテナだけ死んでいる、という状態は普通に起きます。

逆に、サービスの HTTP 監視も万能ではありません。200 が返っていても中身がエラー画面ということがあるので、ログイン画面に必ず出る文字列を指定する 「HTTP(s) - Keyword」 を使うと精度が上がります。

DNS 監視も自宅では効きます。AdGuard Home や Pi-hole を使っているなら、「自分の DNS サーバーに特定のドメインを問い合わせて答えが返るか」を監視対象にしておくと、家庭内で一番影響の大きい故障を直接見られます。

ステップ4：通知疲れしない設定にする

初期値のまま使うと、回線の瞬断や Wi-Fi のゆらぎで夜中に鳴ります。数回それが続くと、人は通知を見なくなります。鳴らない監視より、無視される監視のほうが危険です。

自宅用なら次のあたりが落としどころです。

• Heartbeat Interval：60 秒 → 120〜300 秒。家庭のサービスに秒単位の検知は要りません
• Retries：1 → 3。連続で失敗したときだけダウンと判定します
• Heartbeat Retry Interval：失敗後の再確認間隔。60 秒前後で十分です
• Resend Notification if Down X times：復旧まで鳴り続けるのを防ぐため、控えめに設定します
• 証明書期限の通知：公開サービスがあるならオンに。期限切れは静かに来ます

計画的な再起動やアップデートの前には、メンテナンスモードで対象を止めておくと通知が飛びません。これを使い始めると監視が生活に馴染みます。

ステップ5：スマホに届く経路を 1 本作る

通知先は多数の方式に対応していますが、まず 1 本だけ作ります。自宅サーバー用途で扱いやすいのはこのあたりです。

• ntfy：アプリを入れてトピック名を決めるだけで届きます。セルフホストも可能です。ただしトピック名を知っている人は誰でも購読・送信できる仕組みなので、推測されにくい長い名前にしてください
• Discord / Telegram：Webhook を貼るだけで、履歴も残ります。家族と共有したい場合にも向きます
• メール：確実ですが、気づくのが遅れます。単独では使いません

設定したら、必ず Test ボタンで実際に鳴らして終わりにします。いちばん多い失敗は、本当に落ちた日に「通知が来なかった」と気づくパターンです。

詰まりやすいところ

• 逆プロキシの背後で画面が固まる → Uptime Kuma は WebSocket を使います。Nginx Proxy Manager なら Websockets Support をオンにします
• Docker コンテナを直接監視したい → ソケットの受け渡しが必要です。渡すなら /var/run/docker.sock:/var/run/docker.sock:ro と読み取り専用にします
• 監視サーバー自身が落ちたら誰が気づくのか → ここは監視の構造上どうしても残ります。外部の Push 型サービスを 1 つ併用するか、2 台に立てて相互に Ping させるのが現実的です

おまけ：Push 監視でバックアップの成功を見る

Uptime Kuma には、こちらから叩きに行くのではなく、決まった間隔で連絡が来なければダウンと見なす「Push」タイプがあります。これが自宅サーバーではかなり効きます。

0 3 * * * /usr/local/bin/backup.sh && curl -fsS https://kuma.example/api/push/XXXXXXXX

バックアップが成功したときだけ URL を叩く形にしておけば、失敗した日だけ通知が来ます。バックアップは黙って失敗し、必要になった日に気づく——という壊れ方をするので、サービスの死活監視よりこちらのほうが効果が大きい場合もあります。

まとめ

• 監視ツールは監視対象と同じ機械に置かない。ラズパイ 1 台か家の外に逃がします
• 構築は Docker Compose 1 ファイル。立てたらすぐ管理者アカウントを作ること
• 監視対象は ホスト（Ping）→ サービス（HTTP・キーワード）→ 依存と外形（DNS・ポート・証明書） の 3 層で決めます
• Retries を 3、間隔を 120〜300 秒にして、瞬断で鳴らない設定にします
• 通知は ntfy か Discord を 1 本。設定後に必ず Test で鳴らして確認します
• Push 監視でバックアップジョブの成功を見ると、静かな失敗に気づけます

「落ちたら家族より先に自分が知っている」状態になると、自宅サーバーの運用はかなり気楽になります。

運営者が作った Excel テンプレートを BOOTH で配布しています。IT 資産管理台帳（無料 Lite 版あり） / IT 資格の学習管理シート