Uptime Kuma でサイトを監視する：デプロイから最初の障害通知を受け取るまで

Web サイトや API を公開したあと、「開けなくなっている」とユーザーから言われて気づくのは避けたいところです。証明書の期限切れやサービスの停止が起きたら、最初に通知が届くようにしておきましょう。

Uptime Kuma は軽量なオープンソースのセルフホスト型監視ツールです。HTTP(s)、キーワード、TCP ポート、DNS、証明書の有効期限などのチェックに対応し、ステータスページや多数の通知チャネル（Telegram、Slack、Discord、メール、Webhook など）を備えています。この記事では、Zenavo の Uptime Kuma テンプレートを使ってデプロイから実際のアラート受信までを進めます。

どのサーバーに置くか

始める前に、Uptime Kuma をどのサーバーで動かすかを決めておきます。

• 監視対象のアプリと同じサーバー：まずは試したいときに手軽です。個別のコンテナが落ちたときや証明書の期限が迫ったときは通知できますが、サーバー自体が停止したりネットワークが切れたりすると、監視ごと止まります。
• 別の小さなサーバー：本番環境におすすめです。Uptime Kuma のメモリ使用量はわずかなので、本番サーバーとは別のサーバーに置いておけば、本番サーバーごと落ちたときにも確実に通知が届きます。

テンプレートからデプロイする

まず Zenavo に Linux サーバーを接続し、Uptime Kuma テンプレートを開いて、サーバーを選んでデプロイします。

現在のテンプレートの設定は次のとおりです。

設定	値・用途
イメージ	louislam/uptime-kuma:1
HTTP ポート	3001
永続ボリューム	/app/data。SQLite データベース、監視項目、履歴、通知の認証情報がここに保存されます

uptime-kuma サービスの ネットワーク タブでポート 3001 にドメイン（例：status.example.com）を割り当て、DNS にサーバーを指す A レコードを追加して HTTPS が有効になるのを待ちます。手順はドメインと HTTPS をご覧ください。

ドメインが有効になったら、すぐにサイトを開いて管理者アカウントを作成してください。 最初にページを開いた人が管理者のユーザー名とパスワードを設定できるため、すぐに済ませておきます。

最初の監視項目を追加する

ログインしたら、左上の 監視項目を追加（Add New Monitor） をクリックします。おすすめの基本設定は次のとおりです。

項目	おすすめの設定
監視タイプ	通常のページや API は HTTP(s)。レスポンスに特定の文字列が含まれるか確認するなら HTTP(s) - キーワード
表示名	環境と対象が分かる名前（例：本番 - トップページ、API - /healthz）
URL	ユーザーが実際にアクセスする https:// のアドレス
ハートビート間隔	60 秒
リトライ回数	2 または 3 回。一瞬の通信の揺らぎで夜中に起こされないようにします
証明書の有効期限通知	オンにして、期限の 7〜14 日前に通知されるようにします

データベースを使うアプリなら、トップページとは別に /healthz のようなヘルスチェック用エンドポイントも監視しておくと、バックエンドやデータベース接続の異常も検知できます。

通知を設定し、実際にテストする

右上のプロフィールメニューから 設定 → 通知（Notifications） を開くか、監視項目の編集画面で 通知の設定 をクリックします。

1. 普段使っている通知先（Telegram、Slack、Discord、SMTP メール、Webhook など）を選び、トークンや認証情報を入力します。
2. テスト（Test） をクリックし、スマートフォンやメールにテスト通知が届くことを確認します。
3. デフォルトで有効（Default enabled） をオンにするか、各監視項目の編集画面でこの通知先をオンにして、監視項目を保存します（テスト送信だけして、監視項目への紐づけと保存を忘れるケースがよくあります）。

本当に障害が起きたときに通知が届くか、テスト用のサービスで一度試しておきましょう。

1. 本番トラフィックを受けていないテスト用サービスを監視に追加し、緑色の Up になるのを待ちます。
2. Zenavo でそのテスト用サービスを停止し、1〜3分ほど待って監視が赤色の Down になり、障害通知が届くことを確認します。
3. テスト用サービスを再起動し、復旧（Up）の通知が届くことを確認します。

公開ステータスページ（任意）

status.example.com/status/main のようなユーザー向けのステータスページを作りたい場合は、上部バーの ステータスページ（Status Pages） から新規作成し、外部に公開してよい監視項目だけを追加します。管理画面や内部サービスのアドレスは公開ページに含めないでください。

バックアップとアップグレード

監視項目、通知設定、稼働率の履歴はすべて /app/data ボリュームにあります。uptime-kuma サービスの バックアップと復元 タブでバックアップできます。

1. プロジェクトを停止します（ボリュームのバックアップにはプロジェクトの停止が必要です）。
2. バックアップを作成し、完了したらプロジェクトを再起動します。
3. バックアップを1つダウンロードして保管します（通知用の Bot トークンや Webhook URL が含まれるため、厳重に管理してください）。詳しくはバックアップと復元をご覧ください。

テンプレートは louislam/uptime-kuma:1（v1 系）を指定しています。将来のメジャーバージョンへアップグレードするときは、先に Uptime Kuma のリリースノートを読み、/app/data をバックアップしてから行ってください。データベース構造が移行されたあとは、イメージタグだけを旧バージョンに戻しても起動しないため、戻すにはアップグレード前のバックアップを使います。

よくある質問

「テスト」ボタンでは通知が届くのに、サービスが落ちたときに通知されません 監視項目の編集画面を開き、右側の 通知 一覧で通知チャネルがオンになっているか確認して、画面下部の 保存 をクリックしてください。

ホストの Docker ソケットをマウントする必要はありますか？ ありません。HTTP(s) や TCP ポートの監視でほとんどのサービスをチェックでき、docker.sock を渡さない方が安全です。同じ Zenavo プロジェクト内の別サービスを監視する場合は、http://api.zenavo.internal:3000/healthz のようにプライベートネットワークのホスト名も使えます。

一瞬の通信エラーで誤報が多く届きます 監視項目の リトライ回数（Retries） を 0 から 2〜3 回に増やし、タイムアウトも少し長めに調整して、連続して失敗したときだけ通知されるようにしてください。

まずは Uptime Kuma テンプレートから始めましょう。ドメインの設定と管理者登録を終えたら、通知先を紐づけてテストサービスで停止・復旧の通知まで確認しておけば安心です。