クイックスタート:5分で監視システムを構築する
深夜2時のWebサイトダウンは、インフラ運用担当者にとって最大の悪夢です。ユーザーは商品を購入できず、上司からの連絡が鳴り止みません。さらに最悪なのは、ユーザーからの問い合わせで初めて障害に気づくケースです。
Better StackやPingdomに毎月15〜30ドル払い続ける代わりに、自分専用の監視サーバーを立ち上げてみてはいかがでしょうか。Uptime Kumaはメモリ消費量が150MB未満と非常に軽量なオープンソースツールであり、設定ファイル1つですぐに稼働させることができます。
プロジェクト用ディレクトリを作成し、設定ファイルを開きます:
mkdir -p uptime-kuma && cd uptime-kuma
nano docker-compose.yml
docker-compose.yml に以下のコードを貼り付けます:
version: '3.8'
services:
uptime-kuma:
image: louislam/uptime-kuma:1
container_name: uptime-kuma
restart: always
ports:
- "3001:3001"
volumes:
- ./kuma-data:/app/data
コンテナをバックグラウンド(デタッチドモード)で起動します:
docker compose up -d
イメージのプルにはおよそ30〜60秒ほどかかります。完了後、ブラウザから http://サーバーのIPアドレス:3001 にアクセスしてください。初回アクセス時に管理者アカウントの作成を求められます。パスワードを設定すれば、すぐにダッシュボードが表示されます。
技術解説:各コンポーネントの仕組み
個別コマンドではなくDocker Composeを使うべき理由
手軽さからターミナルで直接 docker run を実行してしまいがちですが、おすすめできません。初期起動は速いものの、数か月後にサーバーを再起動した際、マウントしたボリュームのフラグやポート設定を忘れてしまい、過去のアプタイム履歴が完全に失われる恐れがあるためです。
Composeファイルに定義しておくことで、インフラをコードとして管理(IaC)できます:
- louislam/uptime-kuma:1: メジャーバージョン1を指定するタグです。予期せぬ破壊的変更(breaking change)を避けつつ、セキュリティパッチを安全に適用できます。
- restart: always: プロセスがクラッシュした場合や、ホストサーバーが再起動した際にコンテナを自動復旧させます。
- ./kuma-data:/app/data: SQLiteデータベースと監視設定を保存するディレクトリです。コンテナの削除やイメージの更新を行っても、ホスト側のストレージにデータが安全に保持されます。
最初の監視エンドポイントを追加する
ダッシュボード左上の Add New Monitor をクリックします:
- Monitor Type: WebサイトやREST APIの場合は
HTTP(s)を選択します。ネットワーク遅延やパケットロスを計測したい場合はPingを選びます。 - Friendly Name: 識別しやすい名前を設定します(例:API Gateway Production)。
- URL: テスト対象のエンドポイントを入力します(例:
https://api.yourdomain.com/healthz)。 - Heartbeat Interval: デフォルトの60秒に設定します。Uptime Kumaは毎分HTTPリクエストを送信し、2xx系ステータスコードを正常、5xx系エラーまたは48秒以上のタイムアウトを障害として検出します。
- Retries:
2または3に設定します。一瞬のネットワークの揺らぎによる誤報(フォールスポジティブ)を防ぐことができます。
Telegram Botによる即時アラート通知の設定
Telegramはアラート通知先として最適な選択肢の1つです。完全無料で利用でき、通知遅延は1秒未満、グループごとの権限管理も容易です。
- Telegramを開き、@BotFather に
/newbotと送信して指示に従います。作成完了後、BotFatherから123456789:ABCdefGhI...といった形式の HTTP API Token が発行されます。 - @userinfobot にアクセスしてStartを押し、個人の Chat ID を取得します。オンコール対応用グループに通知したい場合は、Botをグループに招待した上でグループID(先頭にマイナスが付く
-1001234567890などの形式)を使用します。 - Uptime Kumaの画面で Settings > Notifications > Setup Notification を開きます。
- Telegram を選択し、先ほど取得したTokenとChat IDを入力します。
- Test ボタンを押します。スマートフォンに即座にテスト通知が届けば連携成功です。今後作成するすべての監視項目に自動適用されるよう、Default enabled をオンにしておきましょう。
システム最適化:より安全で実践的な構成へ
1. ポート3001を閉じ、リバースプロキシとHTTPSを導入する
ポート 3001 をインターネットに直接公開したままにするのは、セキュリティ上大きなリスクです。このポートへの外部アクセスを遮断し、NginxやCloudflare Tunnel経由でドメインを紐づけて無料のSSL証明書を適用することをおすすめします。
docker-compose.yml のポート設定行を以下のように修正します:
ports:
- "127.0.0.1:3001:3001"
この設定により外部からの直接アクセスを遮断し、同一VPS内のリバースプロキシからのローカル接続のみを受け付けるようになります。
2. ユーザー向け公開ステータスページの作成
Uptime Kumaには Status Page 機能が組み込まれています。公開サービスをグループ化し、ブランドロゴを配置した上で、status.yourdomain.com などのカスタムドメインを割り当てることができます。大規模障害が発生した際にも、サポートチームへの問い合わせチケットの急増を抑えるのに役立ちます。
3. キーワード検索によるサイレントエラーの検知
深刻なデータベースエラー(WordPressのMySQL接続エラーなど)が発生した場合でも、エラーメッセージやホワイトスクリーンを表示しながらHTTPステータスコード200を返してしまうケースがあります。単なるステータスコード監視では、実際にはダウンしているにもかかわらず正常判定(グリーン)と誤認してしまいます。
これを防ぐには、Monitor Typeを HTTP(s) – Keyword に変更します。フッターやヘッダーに常に存在する固定文字列(例:Copyright 2026)を指定してください。レスポンスのペイロード内にそのキーワードが含まれている場合のみ、正常稼働として判定されるようになります。
実践的な運用のベストプラクティス
- 監視対象と同じサーバーにUptime Kumaを同居させない: VPSの電源障害や帯域幅の枯渇が発生した場合、Webサイトと監視ツールの両方が同時にダウンしてしまい、アラートが一切届かなくなります。監視専用として、別プロバイダの安価なVPS(1 vCPU / 1GB RAM、月額3〜5ドル程度)を用意して分離運用しましょう。
- データディレクトリの自動バックアップ: 過去の計測データはすべて
./kuma-data配下に集約されています。毎晩このディレクトリをアーカイブし、rclone等を使ってS3やGoogle Driveへアップロードするcronジョブを組んでおくことを推奨します。バックアップファイルのサイズは通常数MB程度に収まります。 - プローブ頻度(監視間隔)の適切な設定: 特段の理由がない限り、監視間隔を5〜10秒などの過度に短い設定にすることは避けてください。Webサーバーのログ肥大化やCPU負荷を招くだけでなく、CloudflareなどのWAFからスクレイピングやDoS攻撃とみなされ、IPブロックを受ける原因になります。一般的なユースケースの95%においては、60秒間隔が最適な基準値です。

