termal.in

← ブログ

VPS 向けの軽量なサーバー監視ツール:Beszel vs Netdata vs Uptime Kuma vs Nezha(どれも要らない場合も)

· Termalin Team vpslinuxcomparisontoolshomelab

VPS 1 台、あるいは数台の軽量なサーバー監視ツールとなると、正直なところ候補は多くありません。そして最適な 1 本は、あなたが何を知りたいかで決まります。マシンが健全かどうかを知りたいなら Beszel。ユーザーが自分のサイトを開けるかどうかを知りたいなら Uptime Kuma。リージョンをまたぐ VPS 群のパネルなら Nezha、今この 1 台の様子なら Glances、そしてインシデント中の毎秒単位の詳細なら Netdata です。多くの人は、このうち 1 つ、ときに 2 つあれば足り、本格的なオブザーバビリティスタックが要ることはまれです。

開示:Termalin を作っているのは私たちです。以下の選択肢のひとつが Termalin です。オープンソースのツールは、2026 年 10 月 15 日に確認した公開ドキュメントをもとに説明しており、いくつかの項目ではそれらが明確に勝っています。

この記事では、各ツールの監視対象、「軽量」が実際にどれだけのコストになるか、そして上位の検索結果が飛ばしがちな部分を扱います。VPS 自体が落ちたとき誰が監視役を見張るのか、アラートをノイズにしないためにどうするか、小さな代替スクリプト、そして開放ポートのないマシンをどう監視するか、です。

手短な答え:どの質問にどのツールか

  • Beszel——「マシンは無事か?」。ハブと、サーバーごとの小さなエージェント。ホストメトリクスと Docker 統計、Telegram などへのアラート。軽量な既定の選択。
  • Netdata——「まさにその 1 秒に何が起きたか?」。毎秒のメトリクスと、プロセスごとの深い詳細。ここでは最もデータを食いますが、それが狙いです。
  • Uptime Kuma——「外の世界から自分のサービスに届くか?」。HTTP・TCP・ping・DNS のチェックとステータスページ。CPU・メモリー・ディスクは監視しません。
  • Nezha——「プロバイダーやリージョンをまたいだ VPS 群の調子はどうか?」。Web ターミナル付きのプローブ型パネルで、マルチリージョン構成で人気。
  • Glances——「今この 1 台は何をしているか?」。htop や btop のようなライブ表示を、より多くの情報とともに。アラート用途ではありません。
  • Termalin——「何も追加インストールせずにサーバーを監視して知らせてほしい」。監視は、すでに使っている SSH アクセス用のコネクターに相乗りします。有料で、実際の制約もあります(後述)。

「軽量」がサーバー監視で実際に意味すること

「軽量」はたいていエージェントのメモリー使用量で語られますが、それは見るべき数字ではありません。全体を数えましょう。

  • 各マシンのエージェント。 たいていは 1 つのコンパイル済みバイナリで、設計上小さい。
  • ハブまたはダッシュボード。 重さが宿るのはここです。Web アプリ、多くの場合データベース、そしてそれらを常時稼働させておく場所。
  • 開放ポート。 待ち受けるポートはすべて、あなたが抱えることになる攻撃対象領域です。
  • パッチを当てるコンテナーやサービス。 これからずっと更新し続けるものが、もう 1 つ増えます。

この物差しで見ると、Beszel(エージェント 1 つ+ハブのコンテナー 1 つ)と Uptime Kuma(コンテナー 1 つ)は本当に軽量です。Netdata の毎秒収集は、このグループの中で CPU・ストレージともに最もリソースを食います。それが解像度と引き換えになっているのです。そして定番の「大きなスタック」、つまり Prometheus に node_exporter、Grafana、Alertmanager を加えたものは、デプロイし、守り、パッチを当てるべき可動部品が 4 つあります。優れてはいますが、軽量ではありません。1〜20 台のサーバーには、たいてい必要以上です。

候補となるツール

Beszel

ハブ(PocketBase 上に構築)と、各サーバーに置く小さな Go 製エージェント。エージェントは 2 通りで動きます。ハブがポート 45876 で SSH 接続してくるか、あるいはエージェントがトークンを使って WebSocket でハブへ外向きにダイヤルするかです。後者のモードは受信ポートが不要で、NAT の内側でも動きます。ホストメトリクスと Docker コンテナーの統計を読み、CPU・メモリー・ディスク・帯域・温度・稼働状態についてアラートを、Telegram や ntfy を含む 25 以上のチャネルへ送ります。MIT ライセンスで、本稿執筆時点のドキュメントは v0.21 です。素朴な「マシンは健全か」については、これが打ち負かすべき 1 本です。

Netdata

毎秒のメトリクスと、密度の高いライブダッシュボード、そしてプロセスごと・サービスごとの自動的な詳細を豊富に備えます。エージェントは無料で、自分のホスト上で無制限に動き、ローカルで自身のダッシュボードを配信します。エージェント同士を束ねて通知を振り分ける Netdata Cloud は、Community プランなら 5 ノードまで無料です。それを超えると Homelab が $90/年(無制限、フェアユース)、または Business が $4.50/ノード/月(年払い)になります。スパイクを調査していて 1 分平均では粗すぎるときに手を伸ばすツールです。

Uptime Kuma

セルフホストの死活監視です。HTTP(s)・TCP・キーワード・ping・DNS・push・Docker コンテナーのチェック、90 以上の通知サービス、そして公開ステータスページ。GitHub スターは約 92k、MIT です。はっきりさせておくべき点が 1 つ。Uptime Kuma はホストの CPU・RAM・ディスクを収集しません。外側からサービスが応答するかどうかを監視します。そのため、ホストメトリクスのツールの代わりではなく、自然な相棒になります。「セルフホストの Uptime Kuma の代替」への答えは、たいてい「Kuma と Beszel を組み合わせる」です。

Nezha

ダッシュボードとエージェントの組み合わせで、システム状態を報告し、HTTP・TCP・ping のチェックと証明書期限のチェックを行い、アラートを出し、スケジュールタスクを走らせ、各ホストへの Web ターミナルも提供します。エージェントはダッシュボードへ外向きにダイヤルします。中国語圏・韓国語圏のコミュニティでは事実上の VPS「プローブ」パネルで、複数のプロバイダーやリージョンにまたがる小さな VPS をたくさん抱え、それらを 1 ページで見たいときに真価を発揮します。

Glances(と htop/btop)

Glances は 1 台をライブに見るツールです。CPU、メモリー、ディスク、ネットワーク、プロセスなどを 1 画面に、SSH 越しか、任意のローカル Web ページで表示します。htop や btop と同じく、「今このマシンは何をしているか」に答えるだけで、それ以上はありません。履歴はなく、本格的なアラートもありません。手を動かすデバッグ用に道具箱に入れておくべきもので、呼び出し通知を飛ばしてくれることは期待しないでください。

比較表

ツール監視対象アラートとチャネル受信ポートが必要かコスト得意なこと
Beszelホストメトリクス+Docker 統計CPU・メモリー・ディスク・帯域・温度・稼働状態、25 以上のチャネル(Telegram、ntfy)WebSocket モードでは不要、SSH モードでは必要(45876)無料、MIT(セルフホスト)軽量な複数台の健全性監視
Netdataホストメトリクス、毎秒組み込みのアラーム、通知はエージェントまたは Cloud 経由ローカルダッシュボードは 19999、Cloud への接続は送信方向エージェントは無料、Cloud は 5 ノードまで無料、以降は $90/年 または $4.50/ノード/月高解像度のインシデント調査
Uptime Kuma死活監視:HTTP・TCP・ping・DNS・push・コンテナー(ホストメトリクスなし)90 以上のサービス、ステータスページ監視対象へ外から接続、ダッシュボードは自分でホスト無料、MIT(セルフホスト)外形的な死活監視+ステータスページ
Nezhaシステム状態+HTTP・TCP・ping+証明書期限アラート、スケジュールタスク、Web ターミナルエージェントがダッシュボードへ外向きに接続無料(セルフホスト)マルチリージョン VPS のパネル
Glances1 台をライブ表示アラート機能なしローカル、任意で Web 表示無料(セルフホスト)今この 1 台の状態
TermalinConnector 経由のホストメトリクス(2 つ目のエージェント不要)既定しきい値のアラート、メール、iOS プッシュ、Telegram、webhook不要(Connector は送信専用)Pro $10/月、年払いで $8/月、Team は 1 席 $15インストール不要の健全性監視とアラート

VPS が落ちたとき、監視役を見張るのは誰か

ここが、ほとんどの比較記事が飛ばす穴です。ハブやダッシュボードが、監視対象と同じ VPS で動いているなら、その VPS と運命をともにします。そして死んだサーバーは、自分が死んだことを伝えられません。「サーバーがオフライン」こそ、あなたが最も欲しいアラートですが、それは 2 つ目の視点からしか機能しません。

これを埋める方法は 3 つあります。

  • 別の場所にある、もう 1 台の安い VPS で外形チェックを走らせる。私たちがやっているのはこれです。メインのマシンが応答しなくなったことに気づくことだけを仕事とする、別の低コストな VPS で Uptime Kuma を動かしています。
  • 無料の外部チェッカーで、自分のネットワークの外側から公開エンドポイントを ping する。
  • ホスト型のサービスで、「動いているか?」の判定ロジックが自分のものではないインフラで走るため、自分のマシンが落ちても生き残る。

どれを選ぶにせよ、ルールは単純です。「オフライン」を検知するものは、オフラインになるマシンの上に置いてはいけません。

無視する癖がつかないアラート

1 時間に 10 回も呼び出してくる監視は、1 週間でミュートされ、そうなれば無いよりたちが悪くなります。デフォルトのままのツールは、ルールを書くまで沈黙しているか、チューニングするまでおしゃべりかのどちらかに傾きがちです。どちらにせよ、やる仕事は同じです。

  • 問題が始まったら 1 通、解消したら 1 通。 5 分ごとのリマインドではありません。
  • グループ化。 同じ 1 分間に起きた複数の問題は 1 通にまとまります。本当に致命的なものは、それでもそのまま通ります。
  • 同じ問題の同日の繰り返しなし。 ただし致命的で、かつ続いている場合は別です。
  • 穏やかな初日。 新しく監視を始めたマシンが、以前からあった失敗ユニットや期限切れ証明書を一度にすべて浴びせてこないように。
  • アラート種別ごと・サーバーごとのミュート。 1 つのうるさいチェックのために、すべてを黙らせずに済むように。

そして、意味のあるしきい値を選びましょう。ディスクは 90% で警告・95% で危険、または 1 日以内に埋まる見込み。inode の枯渇。メモリー不足によるプロセスの強制終了(OOM kill)。失敗した systemd ユニット。期限まで 14 日の TLS 証明書(3 日で危険)。そして「オフライン」は数分経ってから——再起動をアラームにしないためです。どのツールを選ぶにせよ、このチューニングこそが監視の本当の仕事であり、ツール選びよりも重要です。

10 行の代替案:Telegram へのディスク容量アラート

何かをデプロイする前に、VPS で最もよくある障害——ディスクの満杯——は、cron・df・curl だけでカバーできます。これが、まだダッシュボードは要らないという場合の「disk space alert script linux」や「server monitoring telegram alerts」への答えです。

秘密情報はスクリプトの外に出し、環境変数から読みましょう。

#!/usr/bin/env bash
# disk-alert.sh — warn via Telegram when a filesystem is too full.
set -euo pipefail

: "${TELEGRAM_BOT_TOKEN:?set TELEGRAM_BOT_TOKEN}"
: "${TELEGRAM_CHAT_ID:?set TELEGRAM_CHAT_ID}"
threshold="${DISK_THRESHOLD:-90}"

df -x tmpfs -x devtmpfs --output=pcent,target | tail -n +2 | while read -r pct mount; do
  used="${pct%\%}"
  [ "$used" -ge "$threshold" ] || continue
  curl -fsS --max-time 15 \
    --data-urlencode "chat_id=${TELEGRAM_CHAT_ID}" \
    --data-urlencode "text=$(hostname): ${mount} is ${used}% full" \
    "https://api.telegram.org/bot${TELEGRAM_BOT_TOKEN}/sendMessage" >/dev/null
done

実際の値は root だけが読めるファイルに置き、スクリプトや crontab には決して書かないでください。

# /etc/disk-alert.env  — chmod 600, owned by root
export TELEGRAM_BOT_TOKEN=123456789:replace-with-your-bot-token
export TELEGRAM_CHAT_ID=987654321
export DISK_THRESHOLD=90

あとは cron で 15 分ごとに実行します。次の 1 行を /etc/cron.d/disk-alert として保存します(ユーザー名を含むこの形式は、/etc/cron.d/ 内のファイル用です)。

*/15 * * * * root . /etc/disk-alert.env && /usr/local/bin/disk-alert.sh

ディスクが満杯のままなら 15 分ごとに繰り返します。最後の砦のアラートとしては、それは意図どおりです。うるさすぎるなら、代わりに 1 時間ごとに実行してください。

@BotFather でボットを作り、返信できるように 1 通メッセージを送り、getUpdates から自分の chat_id を一度だけ読み取ります。これで全部です。エージェントもポートもダッシュボードもありません。数台を超えるとスケールしませんが、たいていの VPS を落とす障害は、これで捕まえられます。

NAT・CGNAT・開放ポートなしでの監視

NAT や CGNAT の内側のマシンは受信接続を受け付けられないので、マシンへ接続して動く監視はどれも使えません。使えるものはすべて 1 つの形を共有しています。マシンのほうから外へつなぐのです。

  • Beszel の WebSocket モード。エージェントがハブへ外向きにダイヤルし、受信ポートはありません。(SSH モードは受信の 45876 が必要なので、ここでは避けます。)
  • Netdata。エージェントから Netdata Cloud への接続は送信方向です。
  • Uptime Kuma。push モニターを使います。マシンがスケジュールに従って Kuma の URL を呼び、呼び出しが止まると Kuma がアラートを出します。
  • Termalin。Connector は送信専用で、ポートを待ち受けることは決してありません。

一般的な手法——そしてなぜプライベートなマシンでは「外へつながせる」が唯一安全な答えなのか——は ポート転送なしで NAT 越しに SSH(英語)に、ホームラボ版は 自宅 NAS・サーバーへ SSH にあります。

Termalin が収まる場所——と、収まらない場所

Termalin の切り口は上のツールとは違います。監視エージェントをそもそも追加しません。サーバーにすでに Termalin の Connector——鍵なしの SSH アクセスに使うのと同じ、送信専用で受信ポートのないエージェント——が入っていれば、それはもう監視されています。2 つ目のエージェントはありません。 1 分に 1 回、Termalin が Connector のすでに張っている接続の上で、読み取り専用のコマンド(/proc、df、ps など)をいくつか実行するだけです。マシンへの負担は、CPU 時間で数ミリ秒、1 分あたり約 1 キロバイトです。

読み取るのは、おなじみの健全性の全体像です。CPU(iowait や steal を含む)、負荷と pressure(PSI)、メモリーとスワップ、ディスク容量と inode、ディスクとネットワークの I/O、ソケットと開いているファイル、プロセス、コンテナー、失敗したサービス、失敗した SSH サインイン、保留中のセキュリティ更新、待ち受けポート、そして残り日数付きの TLS 証明書です。アラートは既定のしきい値で動き、ルールを書く必要はありません。そして静かであるよう作られています。開始時に 1 回、解消時に 1 回、グループ化、同日の繰り返しなし、初日は穏やかに、そしてアラート種別ごとのミュート。通知先はメール、iOS プッシュ、Telegram(ワンタップでボットを接続)、そして Slack や Discord が受け取れる webhook で、HMAC-SHA256 で署名されます。履歴は Pro で 90 日間、Team で 2 年間です。

AI アシスタントは同じデータを Termalin のホスト型 MCP エンドポイント(server_metrics と alerts_list)から読めるので、Claude や ChatGPT に「サーバーの調子はどう?」と尋ねるだけで、収集済みのデータから答えが返ります。Web ターミナルで出力内のエラーを選択し、「選択範囲を説明」 を選びます。アシスタントが平易な言葉で短い診断を書き、最後に読み取り専用のチェックコマンドをいくつか示します。ボタンを押せば、それらをセッションに入力してくれます。全体像はサーバー監視のページにあります。

次に、正直な制約です。いくつかの項目では、オープンソースのツールのほうが勝っているからです。

  • 外形的な死活監視もステータスページもありません。 これはホストメトリクスとアラートのツールであって、死活監視ツールではありません。Uptime Kuma は今も良い補完になります。
  • ログ収集もカスタムメトリクスもありません。 Grafana/Prometheus の置き換えではありません。
  • ダッシュボードは今のところウェブキャビネットだけで、デスクトップアプリにはありません。ただしデスクトップアプリも、接続中ホストの CPU・メモリー・ディスクをステータスバーとウォッチグリッド(英語)にライブ表示します。
  • エンドツーエンド暗号化ではありません。 これらの数値は、サービスが読める形で保存されます。チャートを描き、アラートを出すために読む必要があるからです。
  • Free プランでは使えません。 Connector が必要で、これは Pro($10/月、または年払いで $8/月、$96/年) と Team(1 席あたり $15) に含まれます。14 日間の Pro トライアルがあり、カードは不要です。

「無料かつセルフホスト」が譲れない条件なら、答えは Beszel か Uptime Kuma です。それは真っ当な判断です。Termalin が向くのはもっと狭い場面です。すでに SSH アクセスに Termalin を使っていて、健全性チャートとまともなアラートのために別の監視スタックを立てて世話し続けるのは避けたい、という場合です。

状況別のおすすめ

  • 趣味の VPS 1 台。 健全性には Beszel、あるいは怖いのがディスク満杯だけなら上の cron スクリプトだけでも十分です。公開サイトを運営しているなら、あとから Uptime Kuma を足します。
  • 複数プロバイダーにまたがる 5〜20 台の VPS(Hetzner、Contabo、Hostinger、Droplet が 1〜2 台)。メトリクスには Beszel、死活監視には Uptime Kuma を、Kuma のインスタンスは別のマシンに置きます。Web ターミナル付きの 1 枚のパネルが好みなら Nezha。すでに SSH に Termalin を使っているなら、その監視を有効にして、追加のスタックは省きます。
  • CGNAT の内側のホームラボ。 送信専用のものなら何でも。Beszel の WebSocket モード、Netdata の Cloud 連携、または Kuma の push モニターです。NAT 越しのガイド(英語)を参照してください。
  • 「AI アシスタントに『サーバーの調子はどう?』と答えてほしい」。 これは Termalin の出番です。人が見るのと同じデータを、エージェントが MCP 越しに読みます。

よくある質問

Netdata は無料ですか? エージェントは無料で、自分のホスト上で無制限に動き、独自のローカルダッシュボードを備えます。Netdata Cloud の Community プランは 5 ノードまで無料で、それを超えると Homelab が $90/年、または Business が $4.50/ノード/月(年払い)です。

Uptime Kuma は CPU・メモリー・ディスクを監視しますか? いいえ。Uptime Kuma は、サービスが応答するかどうかを外側からチェックします(HTTP・TCP・ping・DNS・コンテナー・push)。ホストの CPU・RAM・ディスクには、Beszel・Netdata・Termalin のいずれかと組み合わせてください。

Beszel と Netdata——どちらが軽いですか? Beszel です。マシンごとの小さなエージェント 1 つと、ハブ 1 つだけです。Netdata は毎秒収集し、このグループで最もリソースを食います。軽さではなく解像度のために選ぶツールです。

Telegram アラート付きで最良の無料 VPS 監視は? ホストの健全性なら、Beszel が Telegram に送れて、セルフホストなら無料です。死活監視なら Uptime Kuma も同様です。インストール不要のつなぎなら、上の cron+curl スクリプトが、バックグラウンドで何も動かさずに Telegram へ直接送ります。

NAT の内側、または開放ポートのない VPS はどう監視しますか? マシンのほうから外へつなぐツールを使います。Beszel の WebSocket モード、Netdata エージェントの Cloud 連携、Kuma の push モニター、または Termalin の Connector です。どれも受信ポートを必要としません。ポート転送なしで NAT 越しに SSH(英語)を参照してください。


Termalin はクロスプラットフォームの SSH クライアントです。Pro と Team では、Connector を入れたすべてのサーバーがチャートと既定しきい値のアラートで監視され、サーバーには何も追加インストールされません。サーバー監視、またはダウンロードをご覧ください。

まずは 1 台のホストで試してみてください。

Termalin は、あなたとあなたのエージェントのための高速な SSH クライアントです。

無料プラン · Pro を 14 日間お試し · 料金