あなたのサーバーは正常に動いていますか?データベースはレスポンスを返していますか?APIエンドポイントはタイムアウトしていませんか?監視システムがなければ、これらの問いに答えることはできません。そして多くの場合、問題があることに気づくのは、顧客からクレームが来てからです。
私もそういう経験をしたことがあります。VPSで動いているアプリが深夜2時にダウンして、朝になって顧客から電話が来て初めて気づくという事態です。その日から全サーバーにモニタリングを導入することにしました。いくつかのツールを試した結果、Uptime Kumaが20台以上のVPSで使い続けているツールになりました。
サーバー監視ツールの比較
インストール手順に入る前に、主要な選択肢を概観して、なぜUptime KumaがほとんどのケースやSmall Businessに適しているのかを理解しましょう。
Zabbix / Nagios — エンタープライズ級だが重い
ZabbixとNagiosは定番の監視ツールで非常に強力です。CPU、RAM、ディスク、ネットワークの監視、マルチチャンネルのアラート、詳細な履歴レポートなど豊富な機能を備えています。ただし、Zabbixを完全にセットアップするには少なくとも30〜60分の設定作業が必要で、SNMP、Zabbixエージェント、テンプレートなどの知識が求められます。個人のサーバーを数台管理するDeveloperやSysadminには、明らかにオーバースペックです。
- メリット:詳細な監視、豊富なメトリクス、エンタープライズ対応。
- デメリット:セットアップが複雑、RAMを多く消費(Zabbixサーバーだけで約512MB必要)、学習コストが高い。
Prometheus + Grafana — 美しいが専門知識が必要
Prometheus + GrafanaのスタックはプロのDevOpsエンジニアが選ぶ定番です。美しいダッシュボード、柔軟なアラート、Kubernetesとの優れた統合が魅力です。ただし、AlertmanagerでAlertルールを設定するにはYAMLを書き、PromQLを理解し、メトリクスが取得できない原因をデバッグする必要があります。
- メリット:柔軟性が高く、スケーラブルで、ビジュアライゼーションが優れている。
- デメリット:DevOpsの深い知識が必要、使いやすいパブリックStatus Pageが標準で用意されていない。
UptimeRobot / Better Uptime — 便利なSaaSだがコントロールを失う
UptimeRobot(無料)、Better Uptime、FreshpingなどのSaaSサービスは非常に便利で、何もインストールする必要がありません。ただし、サードパーティへの依存、データが相手のサーバーに保存されること、無料プランではモニター数やチェック頻度に制限があるといったデメリットもあります。
Uptime Kuma — セルフホスト、シンプル、十分な機能
Uptime KumaはセルフホストのモニタリングツールでUptimeRobotのような美しいUIを持ちながら、完全に自分のサーバー上で動作します。Dockerで2分でインストールでき、20種類以上のモニタータイプ(HTTP、TCP、DNS、Dockerコンテナなど)をサポートし、Telegram/Slack/Discord/Emailでアラートを送信、顧客と共有できるパブリックStatus Pageも備えています。全データは1つのSQLiteファイルに保存されるため、バックアップも移行も簡単です。
分析:Uptime Kumaはいつ使うべきか?
Uptime Kumaは最も包括的な監視ツールではありません。CPUロードの計測やメモリ使用量の時系列グラフ表示はできません。しかし、サービスがダウンしたときすぐに知り、ユーザーと共有できるステータスページが欲しいというのであれば、Uptime Kumaは追加インフラへの投資なしで十分な役割を果たします。
Uptime Kumaを選ぶべきケース:素早くセットアップしたい、メンテナンスコストを抑えたい、小規模サーバー(1〜2 vCPU)を使っている、または顧客向けのパブリックStatus Pageが必要な場合。Prometheus+Grafanaを選ぶべきケース:詳細なメトリクスが必要、DevOpsチームがいる、大規模な多ノード環境を運用している場合。
UbuntuへのUptime Kumaインストールガイド
方法1:Docker(推奨)
サーバーにDockerが既に入っている場合、これが最も速くメンテナンスしやすい方法です。Uptime Kuma全体がコンテナ内に収まり、システムに影響を与えません。
# データ保存ディレクトリを作成
mkdir -p /opt/uptime-kuma/data
# コンテナを起動
docker run -d \
--name uptime-kuma \
--restart unless-stopped \
-p 3001:3001 \
-v /opt/uptime-kuma/data:/app/data \
louislam/uptime-kuma:1
Docker Composeを使う場合(後々の管理がしやすいのでこちらをよく使います):
# /opt/uptime-kuma/docker-compose.yml
services:
uptime-kuma:
image: louislam/uptime-kuma:1
container_name: uptime-kuma
restart: unless-stopped
ports:
- "3001:3001"
volumes:
- ./data:/app/data
cd /opt/uptime-kuma
docker compose up -d
方法2:npmで直接インストール
DockerがないサーバーやコンテナレイヤーをC避けたい場合に使用します:
# Node.js 18+がない場合はインストール
curl -fsSL https://deb.nodesource.com/setup_18.x | sudo -E bash -
sudo apt install -y nodejs
# Uptime Kumaをクローンしてインストール
git clone https://github.com/louislam/uptime-kuma.git /opt/uptime-kuma
cd /opt/uptime-kuma
npm run setup
# PM2でサービスとして起動
npm install pm2 -g
pm2 start server/server.js --name uptime-kuma
pm2 startup
pm2 save
私がDockerを選ぶ理由は、サーバー移行やバックアップの際に/opt/uptime-kuma/dataディレクトリをコピーするだけで済むからです。Uptime Kumaのアップデートもdocker pullしてコンテナを再起動するだけです。
最初のモニターを追加する
http://your-server-ip:3001にアクセスし、adminアカウントを作成して、Add New Monitorをクリックします:
- Monitor Type:WebサイトにはHTTP(s)、データベース/RedisにはTCP Port
- Heartbeat Interval:本番環境は30〜60秒、重要度の低いサービスは5分
- Retries:ダウン通知前に2〜3回リトライ(ネットワークの一時的な不安定によるフォルスアラームを防止)
Tips:純粋なHTTPモニターの代わりにKeywordモニターを使いましょう。HTTPステータスコードのチェックに加えて、レスポンスボディに特定の文字列が含まれているかも確認するため、サーバーが200 OKを返しながらも実はエラーページを表示しているケースを検知できます。
Telegramアラートの設定
Telegramは私が最もよく使うアラートチャンネルです。スマートフォンですぐに受信でき、メールのようなスパムフィルターにかからず、SMTPの設定よりもはるかに素早くセットアップできます。
ステップ1:Telegram Botを作成する
- Telegramを開き、@BotFatherを検索する
/newbotと入力し、Botの名前とユーザー名を設定する- BotFatherからBot Token(
123456789:ABCdef...の形式)が返ってくるので保存しておく
ステップ2:Chat IDを取得する
# 先にBotにメッセージを送ってから、このコマンドを実行する:
curl "https://api.telegram.org/bot<YOUR_BOT_TOKEN>/getUpdates"
# レスポンスの "chat":{"id": 123456789} を探す
# グループのChat IDは負の数になる:-100...
ステップ3:Uptime Kumaで設定する
- Settings → Notifications → Add Notificationに進む
- Type:Telegramを選択
- Bot TokenとChat IDを入力し、Testをクリックする
- 保存してアラートが必要なモニターに通知を割り当てる
Uptime Kumaはサービスがダウンしたときだけでなく、復旧したときにもアラートを送信します。ダッシュボードを確認しなくても、問題が解決されたことをすぐに知ることができます。
パブリックStatus Pageを作成する
Status Page → New Status Pageに進み、スラッグURL(例:status)を設定し、表示したいモニターを追加してインターフェースをカスタマイズします。顧客はhttp://your-ip:3001/status/statusにアクセスしてリアルタイムのアップタイムを確認できます。
status.yourdomain.comのような独自ドメインでアクセスしたい場合は、Nginxのリバースプロキシが必要です:
server {
listen 80;
server_name status.yourdomain.com;
location / {
proxy_pass http://localhost:3001;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_http_version 1.1;
# WebSocketのリアルタイム通信に必須
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
}
}
UpgradeとConnectionの2行は必須です。Uptime KumaはリアルタイムのアップデートにWebSocketを使用しており、これらがないとダッシュボードが自動更新されません。
実際に使って気づいた実践的なTips
毎日のデータバックアップ:全設定と履歴は/opt/uptime-kuma/data/kuma.dbファイルに保存されています。シンプルなcronジョブで十分です:
# 毎日午前2時にバックアップ
0 2 * * * cp /opt/uptime-kuma/data/kuma.db /backup/kuma-$(date +\%Y\%m\%d).db
外部からUptime Kumaを監視する:Uptime Kuma自身を自分で監視することはできません。無料のUptimeRobot(モニター1つで十分)を使ってUptime Kumaにpingを送りましょう。ダウンした場合でもアラートを受け取れます。
内部サービスも監視する:パブリックURLだけを監視している人が多いですが、データベースポート、Redisポート、内部APIにもTCPモニターを追加することをお勧めします。リバースプロキシが200を返していても、バックエンドがすでに死んでいることがあるからです。
私は20台以上のVPSにUbuntu Server 22.04をインストールしてきましたが、このUptime Kumaのセットアップは常に最初にやることの一つです。SSHキーとファイアウォールの設定直後に行います。最初からモニタリングを入れておくことで、ユーザーが気づく前に問題を検知でき、インシデントが発生した際も憶測ではなく具体的なアップタイム履歴データを参照できます。
