なぜWebサイトの監視が必要なのか
以前、私はPrometheus + Grafanaで15台のサーバーを監視していたのですが、そこで気づいたことがあります。サーバーのメトリクス監視と同じくらい重要なのが「ユーザーから見たサービスの可用性」です。CPU使用率が正常でもWebサイトが実際には動いていない、という事態が時々発生するんです。
顧客からの報告を待つのではなく、問題が発生した瞬間に把握できるようにしたいと考えていました。その時に出会ったのがUptime Kumaです。シンプルながら強力な機能を備えており、複雑な設定が不要で、すぐに運用に入れました。
Uptime Kumaの特徴
- HTTPステータスコードの監視
- キーワードマッチング（レスポンス内容の確認）
- SSL証明書の有効期限監視
- 複数プロトコル対応（HTTP、TCP、Ping、DNS等）
- 複数チャネルへのアラート通知（Slack、Discord、メール等）
- シンプルなUI、軽量な動作
Uptime Kumaのインストール
環境構築：Dockerを使った方法
私の環境ではDockerを採用しているため、コンテナベースでのインストールを推奨します。最小限の依存関係で済みますし、他のシステムへの影響がありません。
docker run -d --restart=always -p 3001:3001 -v uptime-kuma:/app/data --name uptime-kuma louislam/uptime-kuma:1このコマンド実行後、http://localhost:3001 にアクセスしてください。初回アクセス時に管理者アカウント設定画面が表示されます。
Docker Composeを使った設定
本番環境では、docker-compose.ymlで管理するのが管理性に優れています。
version: '3.8'
services:
uptime-kuma:
image: louislam/uptime-kuma:1
container_name: uptime-kuma
ports:
- "3001:3001"
volumes:
- uptime-kuma:/app/data
restart: always
networks:
- monitoring
volumes:
uptime-kuma:
driver: local
networks:
monitoring:
driver: bridge起動コマンドは以下の通りです。
docker-compose up -d
docker-compose logs -f uptime-kumaホストマシンへの直接インストール
Node.jsが既にインストールされている場合は、直接インストールすることも可能です。
git clone https://github.com/louislam/uptime-kuma.git
cd uptime-kuma
npm install
npm run build
node server/server.jsただし本番環境ではpm2やsystemdでプロセス管理することを推奨します。
基本設定：モニタリング対象の追加
HTTP監視の設定
ダッシュボードにログインしたら、左上の「Add Monitor」をクリックします。
基本設定項目：
- Monitor Type：「HTTP(s)」を選択
- Friendly Name：「My Company Website」のようにわかりやすい名前
- URL：https://example.com のようにフルURLを入力
- Heartbeat Interval：監視間隔を秒単位で指定（デフォルト60秒）
- Retries：失敗時の再試行回数（デフォルト0回）
詳細設定：レスポンス検証
単なるステータスコード200だけでなく、実際のサービス稼働を確認したい場合があります。例えば、サイトは表示されるが、データベース接続エラーで機能していないという状況を検出できます。
Expected Status Code: 200
Keyword: "Welcome to Dashboard"
Match Type: Contains
このように設定すれば、ステータスコード200 かつ「Welcome to Dashboard」という文字列を含むレスポンスが返ってくる場合のみアップと判定します。
SSL証明書の監視
HTTPS監視を有効にすると、自動的にSSL証明書の有効期限も監視されます。有効期限が30日以内になるとアラートが発火するので、更新漏れを防げます。
アラート通知の設定
Slackへの通知設定
通知が無ければ監視は意味がありません。私のチームではSlackを使っているため、Slack統合を優先しました。
まずはSlackのIncoming Webhookを取得します。
- Slackアプリメニューから「App管理」を開く
- 「カスタムインテグレーション」→「Incoming Webhooks」へ
- 「新規ウェブフックを追加」をクリック
- 通知対象のチャネルを選択して確認
- Webhook URLをコピー
Uptime Kumaの管理画面で以下のように設定します。
Notification設定：
- Settings → Notifications → 「Add Notification」
- Notification Type：「Slack」
- Webhook URL：取得したURLを貼り付け
- Test送信してうまく届くか確認
メール通知の設定
複数チャネルでの通知も推奨します。メール設定は以下の通りです。
Notification Type: Email
SMTP Server: smtp.gmail.com
SMTP Port: 587
Security: TLS
Username: [email protected]
Password: your-app-password
From: [email protected]
To: [email protected]
Gmailを使う場合、通常のパスワードではなく、アプリ用パスワードを生成して使用してください。
監視対象へのアラート割り当て
監視対象を編集し、「Notifications」セクションでSlackやメール通知を有効化します。複数の通知先を同時に選択することで、連絡網が確実になります。
実運用での監視確認
ダッシュボードの見方
Uptime Kumaのダッシュボードには、各監視対象の稼働状況が一覧表示されます。
- ステータス表示：緑（UP）、赤（DOWN）で即座に判別
- 稼働率グラフ：過去30日間の稼働率推移を可視化
- レスポンスタイム：応答時間をグラフで追跡
- インシデント履歴：ダウンタイムがいつ発生したかを記録
動作テスト
実際に監視が正常に動作するか、テストしてみましょう。
# テスト用にローカルWebサーバーを起動
python3 -m http.server 8080
その後、Uptime Kumaで「http://localhost:8080」を監視対象に追加します。サーバーを停止すれば、数秒以内に「DOWN」状態になり、アラートが通知されることを確認できます。
実際の運用での工夫
私の経験では、以下の点が重要でした。
- 監視頻度の調整：本番環境は60秒、ステージングは300秒というように、リソース効率を考慮
- 誤検知の削減：retryを2回に設定し、一時的なエラーで誤アラートを出さない
- 複数地点からの監視：別のサーバーからUptime Kumaを実行し、ネットワーク障害と本体障害を区別
- ステータスページの公開：Uptime Kumaはステータスページも生成でき、顧客に共有可能
ステータスページの有効化
Settings → Status Page から「Enable」をクリック。すると `http://localhost:3001/status` でシンプルなステータスページが公開されます。このURLを顧客に共有すれば、サービス状況を透明に示せます。
本番運用へ向けた注意点
Uptime Kumaは軽量ですが、本番環境では以下を検討してください。
- リバースプロキシ背後での運用：NginxやTraefikで保護
- 定期バックアップ：/app/data ディレクトリを定期的にバックアップ
- ログ監視：Uptime Kuma自体のエラーログも確認
- 冗長化：複数ノードで監視を実行し、単一障害点を避ける
Prometheus + Grafanaとの共存も可能です。Prometheus は詳細なメトリクス分析に、Uptime Kumaはシンプルなアップタイム監視に使い分けるのがベストプラクティスです。
さいごに
Uptime Kumaを導入したことで、顧客からの報告を待つのではなく、問題発生の瞬間に対応できる体制が整いました。シンプルながら実用的な設計のおかげで、複雑な学習曲線もなく、チーム全体がすぐに運用できています。
サイトの稼働状況を可視化し、SLAを確実に達成したいなら、Uptime Kumaは本当に価値があるツールです。
