Dockerで実現｜Uptime Kuma監視サーバーの構築・運用ガイド
AWSなどでサーバー（EC2）を構築した際、「サーバーの死活監視やレスポンスタイムの測定を手軽に始めたい」と思ったことはありませんか？ 本格的なクラウド監視サービスを導入するほどではないけれど、SlackやDiscordに通知を送れる視認性の高い監視ダッシュボードが欲しい。そのような場合に適しているのが、オープンソースの軽量かつ強力な監視ツール Uptime Kuma です。
本記事では、すでに用意されたEC2インスタンス（Amazon Linux 2023など）に Docker / Docker Composeを使って Uptime Kumaの最新安定版である v2.4.0 を最速で立ち上げ、実際のAWSリソース（EC2など）を安全に監視するまでの全手順を詳しく解説します。
この記事の目次
この構成のメリット・デメリット
技術選定において、メリット・デメリットを理解しておくことは非常に重要です。
メリット
- 動作の軽さと機能の豊富さ：Uptime KumaはNode.js製で非常に動作が軽く、HTTP/HTTPS、TCP、Ping、DNS、Dockerコンテナなどの監視に標準で対応しています。
- 視認性の高さ：ステータスページを数クリックで作成でき、一目で稼働状況がわかる視認性に優れたUIを持っています。
- 運用の手軽さ：コンテナベースなので、インストールからアップデート、データの移行までが非常にシンプルです。
デメリット・考慮すべき点
- 監視サーバー自体の可用性：今回はEC2のシングルインスタンス構成です。監視サーバー自体がダウンした場合、監視が機能しなくなります（本番環境では冗長化やAWS Managed Servicesの検討が必要です）。
- SSL/TLS対応（HTTPS化）：初期状態ではポート 80（HTTP）での接続となります。本番運用する際は、手前にNginxリバースプロキシやAWSのALB（Application Load Balancer）を挟んでHTTPS化（ポート 443）することを推奨します。
システム構成
今回の構成イメージは以下の通りです。
Plaintext
[ インターネット ]
│ (HTTP: ポート80)
▼
[ AWS EC2 インスタンス ] (セキュリティグループでポート80を許可)
│
(Docker ホスト)
│ (ポート 80 -> 3001 マッピング)
▼
[ Uptime Kuma v2.4.0 コンテナ ] (SQLite データベースでデータを永続化)
Docker & Docker Compose のセットアップ
まずは、EC2インスタンスにSSHでログインし、Docker環境を構築します。Docker Composeに関しては、所定のプラグインディレクトリを作成した上で、GitHubのリリーページからバイナリ（v5.3.1）を直接ダウンロードしてインストールします。
Bash
# パッケージの更新
sudo dnf update -y# Dockerのインストール (Amazon Linux 2023想定)
sudo dnf install -y docker# Dockerサービスの起動と自動起動有効化
sudo systemctl start docker
sudo systemctl enable docker# ec2-userをdockerグループに追加（再ログイン後にsudoなしでdockerコマンドが使えるようになります）
sudo usermod -aG docker ec2-user# Docker CLIプラグイン用ディレクトリの作成
mkdir -p ~/.docker/cli-plugins# Docker Compose v5.3.1のダウンロードと設置
curl -SL https://github.com/docker/compose/releases/download/v5.3.1/docker-compose-linux-x86_64 -o ~/.docker/cli-plugins/docker-compose# 実行権限の付与
chmod +x ~/.docker/cli-plugins/docker-composeポイント： usermod 実行後は、設定を反映するために一度SSH接続を切断して再ログインしてください。 再ログイン後、docker compose version を実行してバージョンが表示されれば、Composeの導入は成功です。
Uptime Kuma (v2.4.0) のデプロイ
監視ダッシュボードのデータを永続化（コンテナを再起動しても設定が消えないように）するため、ボリュームをマウントした docker-compose.yml を作成して起動します。イメージタグを明確に 2.4.0 に指定します。
ディレクトリの作成
Bash
mkdir ~/uptime-kuma && cd ~/uptime-kumadocker-compose.yml の作成
vi docker-compose.ymli キーを押してインサートモードにし、以下の内容を貼り付けて Esc キーを押した後に :wq で保存します。
YAML
services:
uptime-kuma:
image: louislam/uptime-kuma:2.4.0
container_name: uptime-kuma
volumes:
- ./data:/app/data
ports:
- "80:3001" # AWSのポート80をコンテナ内部の3001ポートに接続
restart: alwaysコンテナの起動
Bash
docker compose up -d起動に成功したか確認します。
Plaintext
[ec2-user@ip-10-0-1-152 uptime-kuma]$ docker compose ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
4f769676758e louislam/uptime-kuma:2.4.0 "/usr/bin/dumb-init …" 8 minutes ago Up 8 minutes (healthy) 0.0.0.0:80->3001/tcp, :::80->3001/tcp uptime-kuma上記のように STATUS が Up … (healthy) になり、PORTS で 0.0.0.0:80->3001/tcp へ正しくマッピングされていれば、コンテナ側の準備は完了です。
トラブルシューティング：ブラウザからアクセスできない場合
「コンテナは間違いなく起動しているのに、ブラウザにIPアドレスを入れてもタイムアウトや接続エラーになる」というのは、この構築で特につまずきやすいポイントです。アクセスできない場合は、以下のステップで切り分けを行います。
Step 1：EC2内部でサービスが稼働しているか確認する（最優先）
まずは「EC2の内部」で、Uptime Kumaが応答を返しているかを確認します。EC2のターミナルで以下を実行してください。
Bash
curl -I http://localhost- HTTP/1.1 200 OK や 302 Found が返ってきた場合：コンテナは正常に動作しています。原因は「AWSのネットワーク設定（セキュリティグループ）」か「クライアント側のブラウザの挙動」のどちらかに絞られます。
- Connection refusedと表示される場合：コンテナ起動時にデータベースの作成に失敗しているか、別プロセス（テスト用のNginxなど）がポート80を先に占有しています。docker ps を確認し、競合プロセスを docker stop <コンテナ名> で停止してください。
Step 2：AWSセキュリティグループの設定（パブリックIPの許可）を確認する
ここが最も見落としやすいポイントです。Uptime Kumaを構築した「監視元サーバー（EC2）」のセキュリティグループを確認してください。
- 自身のパブリックIPアドレスからのアクセス許可：あなたがブラウザでUptime Kumaの管理画面（http://<KumaのパブリックIP>）にアクセスするためには、Uptime Kumaが起動しているEC2のセキュリティグループ（インバウンドルール）に、HTTP（ポート80） を追加し、ソースに「あなたの接続元グローバルIPアドレス」、または検証用として一時的に「任意の場所（0.0.0.0/0）」が許可されている必要があります。この設定がない場合、インターネット側からUptime Kumaの画面を開くことができません。
- ターゲットへのアクセス許可（監視を始めるための設定）：反対に、Uptime Kumaが「監視対象のサーバー」を外から監視する際も同様です。監視される側のサーバーは、Uptime Kumaサーバーの「パブリックIPアドレス（グローバルIP）」 からのアクセスを許可するようにセキュリティグループを設定しておく必要があります（※同じVPC内にいない場合）。この設定がない場合、Uptime Kumaからは対象サーバーが「ダウンしている（タイムアウト）」ように見えてしまいます。
Step 3：ブラウザの「HTTPS自動リダイレクト」の罠を回避する
現在の主要なブラウザでは、セキュリティ機能により、手動で http:// と入力しても、自動的にhttps:// (ポート443)へ書き換えられる場合があります。
- 対策A (最も確実な方法)：スマートフォンの Wi-Fiをオフ（4G/5Gモバイル回線） にして、ブラウザから http://<EC2のパブリックIP> にアクセスを試みます。
- 対策B (Chromeキャッシュの削除)：Chromeで chrome://net-internals/#hsts を開き、「Delete domain security policies」に対象IPを入力してDeleteを実行します。その後、シークレットウィンドウで再度アクセスを試みます。
実践：AWS上のターゲット（EC2など）を監視する
Uptime Kumaが立ち上がったら、実際にAWS上のリソース監視を設定しましょう。
事前準備：監視対象側のセキュリティグループ設定
Uptime Kuma（監視サーバー）がターゲットにアクセスできるように、監視対象リソース（ターゲット）側のセキュリティグループにインバウンドルールを追加します。
セキュリティのベストプラクティス
- 同一のVPC（ネットワーク内）で監視する場合：監視対象のポートの「ソース」に、Uptime Kumaが稼働しているEC2インスタンスの 「プライベートIPアドレス」 を指定します。不要なポート公開を防ぎ、安全なプライベート経路で監視できます。
- 異なるVPCや別環境からパブリックIPで監視する場合：監視対象ポートの「ソース」に、Uptime Kumaサーバーの 「パブリックIPアドレス（グローバルIP）」 を指定して、アクセスを許可します。この設定がされていないと、Uptime Kumaからの監視パケットが遮断されてしまいます。
監視設定の追加と通知設定の手順
Uptime Kumaのダッシュボード右上の「＋モニターを追加」から、以下の設定を入力します。
監視の追加サンプル 3選
① EC2上のWebアプリケーション監視（HTTP / HTTPS）
EC2内で動いているWebサイトやAPIが正常に応答しているかを監視します。
- モニタータイプ: HTTP(s)
- フレンドリーネーム: EC2-Production-Web
- URL: http://<監視対象EC2のIP>:<ポート>
- 心拍間隔: 60 秒（標準的な間隔）
- リトライ: 3 （ネットワークの揺らぎによる誤検知を防ぐため、3回連続失敗でダウンと判定）
- 期待されるステータスコード: [200] （500エラーや502 Bad Gateway時にアラートにする設定）
② EC2インスタンス自体の生存監視（Ping / ICMP）
OS自体がハングアップしていないか、インスタンスが起動しているかをネットワーク層で監視します。
️ AWS側の注意点: EC2のデフォルト設定では、Ping（ICMP通信）は拒否されます。監視対象EC2のセキュリティグループで、「すべてのICMP – IPv4（Echo Request）」を許可し、ソースにUptime KumaサーバーのIPを指定してください。
- モニタータイプ：Ping
- フレンドリーネーム：EC2-OS-Status
- ホスト名 / IPアドレス：<監視対象EC2のIP>
- 心拍間隔：30 秒
③ EC2内のSSHやデータベースのポート監視（TCP）
「サーバー自体は稼働している（Pingは通る）が、SSHサービスやMySQLなどのミドルウェアが落ちていないか」を監視します。
- モニタータイプ：TCPポート
- フレンドリーネーム：EC2-SSH-Service
- ホスト名 / IPアドレス：<監視対象EC2のIP>
- ポート：22（データベースなら 3306 や 5432 など）
通知のアソシエーション設定
監視対象がダウンした際に、設定した通知先にリアルタイムでアラートを届ける手順です。
- 各モニター設定画面の右側にある「通知を設定」をクリックします。
- 「通知を設定」ボタンを押し、通知タイプ（例：Slack や Discord）を選択します。
- 各アプリ側で発行した Webhook URL などを貼り付けます。
- 「テスト」を押して手元に通知が届くことを確認し、保存します。
Uptime Kumaで利用できる監視タイプ一覧
Uptime Kumaは、さまざまな種類のプロトコルや監視ターゲットに対応しており、用途に合わせて使い分けることが可能です。
| 監視タイプ | 主な対象・用途 | 概要 |
| HTTP(s) | Webサイト、API、SaaSなど | 指定したURLにリクエストを送り、ステータスコード（200など）や応答時間を監視します。 |
| HTTP(s) – キーワード | ECサイト、Webシステムなど | 取得したHTML内に「特定の文字列（例: メンテナンス中）」が含まれるか、または「含まれないか」を監視します。 |
| Ping | サーバー、ルーター、ネットワーク機器 | ICMP Echo Requestを送信し、ホストが起動しているか（疎通確認）を監視します。 |
| TCP ポート | SSH、データベース、メールサーバーなど | 指定したホストの特定ポート（例: SSHは22、MySQLは3306）が接続を受け付ける状態かを監視します。 |
| DNS | DNSネームサーバー | 指定したドメインの名前解決が正常に行えるか、期待したIPアドレスが返ってくるかを監視します。 |
| Push | バッチ処理、Cronジョブ、バックアップ処理 | Uptime Kumaが発行する独自のURLに対して、バッチ処理完了時などにリクエストを送信することで「バッチが定刻通りに実行されたか」を逆監視（パッシブ監視）します。 |
| Steam/Game Server | 各種ゲームサーバー | MinecraftやRustなどのマルチプレイゲームサーバーの応答や稼働状況を監視します。 |
| Docker コンテナ | 同一サーバー内のコンテナ | Dockerソケット経由で、特定のDockerコンテナが Running 状態を維持しているかを監視します。 |
アラート通知を連携する通知タイプ一覧
Uptime Kumaは標準で非常に多くの外部通知サービスに対応しています。代表的な通知タイプとそれぞれの特徴は以下の通りです。
| 通知タイプ | 特徴とメリット |
| Slack | 広く利用されている。専用チャンネルへのWebhook URLを用意するだけで簡単にメンション付き障害通知を設定可能。 |
| Discord | Slackと同様、チャンネル統合の「ウェブフックURL」を貼り付けるだけで即座にリッチなテキスト通知が飛ぶためおすすめ。 |
| LINE (LINE Notify) | 個人開発や小規模チームに便利。自身のスマホに直接障害通知をリアルタイムでプッシュ可能。 |
| Microsoft Teams | コラボレーションツール「Teams」のWebhookを使用して、社内チャネルに素早くアラートを共有可能。 |
| Email (SMTP) | GmailやAWS SESなどのSMTPサーバー情報を入力することで、従来のメールによる障害通知を送信可能。 |
| WebHook | 障害発生時、Uptime Kumaから別の自作APIや外部SaaSに向けてカスタムJSONデータをPOST送信し、独自の自動復旧スクリプトなどを起動可能。 |
| Pushover / Gotify | モバイル向けのプッシュ通知専用サービスと連携し、スマホアプリへ迅速にアラートを配信。 |
まとめ：監視の「その先」にある安定運用のために
本ガイドの手順を進めることで、Dockerを使ったUptime Kumaによる高速な監視サーバー構築と、AWSターゲットの死活監視を容易に開始できます。バージョン（Docker Compose v5.3.1 / Uptime Kuma v2.4.0）を固定することで、今後のアップデートや環境複製の手間も大幅に削減されます。
しかし、「監視システムを作ること」と「24時間365日の安定運用を維持すること」は全く別の問題です。
- 深夜の障害通知に対して、誰が、どのようなオンコールスケジュールで、どう対応するか？
- 障害の根本原因分析と、再発を防ぐインシデント管理体制はどう構築するか？
- 監視サーバー自体がダウンした際の、冗長化やバックアップ体制はどうするか？
ツールの導入によってシステムを「可視化」した後は、こうした「体制づくりとインシデント管理」という運用フェーズの設計が必要不可欠です。
運用・インシデント管理に課題をお持ちではありませんか？
Uptime Kumaをトリガーとした障害対応者への迅速な通知設計やエスカレーションルールの策定、さらには恒久的なインシデント管理・自動化運用の仕組みづくりにおいて、ベアサポートでは多数の実績がございます。
「監視を始めたけれど、アラートの運用体制が定まっていない」「夜間対応の設計に不安がある」といったお悩みがございましたら、最適な運用プロセスをご提案・サポートいたしますので、ぜひお気軽にお問い合わせください！
