普段、身内で遊ぶための Minecraft サーバーを管理してます。
そのサーバーで先日、Mob ファームが原因の大規模な負荷問題が発生しました。発覚したときにはすでにサーバーの処理速度が大幅に低下しており、まともにプレイできない状態となってしまいました。この出来事から、サーバーに入って異変に気付くのでは遅いと実感し、監視環境を整備することにしました。
この記事では、Minecraftサーバーのメトリクスを取得し、ダッシュボードで可視化・Discordへアラート通知するまでの構成を紹介します。
きっかけは25,000体のゾンビピグリン
Mob ファーム AFK で問題が発生
この日、とある参加者が前日に作成されたばかりのゾンビピグリンファームで AFK していました。
このゾンビピグリンファームは、ネザーで湧いたゾンビピグリンを一度オーバーワールドへ送る方式でしたが、実はこの時、オーバーワールド側の処理装置には問題があり正常に動作していませんでした。その結果、オーバーワールドへ送られ続けたゾンビピグリンが特定チャンクに溜まり続ける状態になっていました。
パフォーマンスが悪化
最終的にオーバーワールドの2チャンクに約26000体のゾンビピグリンが溜まってしまいました。
僕がサーバーにログインしたときにはTPSは1桁、MSPTは4桁に達していて、サーバー内での移動は困難で、接続タイムアウトも発生する状態でした。
参加プレイヤーが放置していた場所からゾンビピグリンファームが怪しいと考えて調査した結果、オーバーワールドに溜まったゾンビピグリンが原因と判明し、サーバーコマンドからゾンビピグリンを kill することで復旧に至りました。
ログインしてから気付くでは遅い
今回の問題では、ログインした時点ですでにサーバーが重かったのですが原因がわからないため、何が起きているのか調査を行い、30分後に大量のエンティティをサーバーコマンドによって発見という流れでした。
今回は、サーバーがダウンする前に気付くことができましたが、今後も同じように気付けるとは限りません。
そこで、サーバーの処理速度が低下した時点で管理者へ通知する仕組みを構築することにしました。
構築したMinecraftサーバー監視環境
全体構成
Minecraft サーバーの監視は、Minecraft Prometheus Exporter でサーバー内のメトリクスを公開し、Grafana Alloy で収集して Grafana Cloud に送信する構成にしています。
全体構成図は以下のようになっています。
Minecraft Prometheus Exporter からは TPS やオンラインプレイヤー数、エンティティ数などの Minecraft 固有のメトリクスを取得し、VPS 側からはホストのリソース使用状況を取得します。
これらを Grafana Cloud にまとめて送ることで、Minecraft サーバーの状態と VPS の状態をひとつのダッシュボードから確認できるようにしています。
なぜGrafana Cloudを選んだか
監視環境には Grafana Cloud を利用することにしました。
Prometheus と Grafana を VPS 上に構築する方法もありましたが、今回は Minecraft サーバーと同じ VPS 上で監視基盤まで管理したくありませんでした。監視対象と監視基盤が同じサーバーにあると、VPS 自体に問題が起きた場合に監視も一緒に使えなくなってしまいます。かといって専用に VPS を構築するのもそれはそれで面倒です。そこで、メトリクスの保存やダッシュボード、アラート機能をまとめて利用できる Grafana Cloud を選びました。
Grafana Cloud には無料プランがあり、2026年8月時点では、Metrics について主に以下の制限があります。
- 月10,000 active series まで
- メトリクスの保持期間は14日間
- Grafana を利用する active user は月3人まで
個人で運用している Minecraft サーバー1台とVPSのメトリクスを監視する用途であれば、十分使える範囲だと判断しました。
特に今回の目的は、メトリクスを何か月も保存して分析することではありません。
TPS の低下などの異常を早めに検知し、問題が起きたときに直近のメトリクスから原因を調べられるようにすることが目的です。そのため、14日間という保持期間も今回の用途では特に問題になりませんでした。
Google Cloud などの監視サービスを利用することも検討しましたが、個人の Minecraft サーバー監視に継続的なコストをかけるほどではないと考え、今回は無料枠で始められる Grafana Cloud を採用しました。
Minecraft のメトリクスを Prometheus 形式で取得する
まずは、Minecraft サーバーのメトリクスを取得できるようにします。
今回は Minecraft Prometheus Exporter というプラグインを使用しました。
Minecraft Prometheus Exporter は、Minecraft サーバーの状態を Prometheus 形式のメトリクスとして公開してくれる Bukkit プラグインです。
Paper、Spigot、Bukkit などに対応しており、今回は Purpur サーバーに導入しています。
導入方法は一般的なプラグインと同じで、配布されているJARファイルを Minecraft サーバーの plugins ディレクトリに配置するだけです。
デフォルトでは以下のエンドポイントからメトリクスを確認できます。
http://localhost:9940/metrics
ブラウザや curl などでこのエンドポイントへアクセスすると、Minecraft サーバーの状態がPrometheus 形式のテキストとして出力されます。
Prometheus について簡単に説明すると、サーバーやアプリケーションから「現在の TPS はいくつか」「メモリをどれくらい使っているか」といった数値を定期的に収集し、時系列データとして扱うための監視システムです。
今回はこの /metrics エンドポイントを後述する Grafana Alloy から定期的に取得し、Grafana Cloud へ送信します。
取得できる Minecraft のメトリクス
Minecraft Prometheus Exporter を導入すると、Minecraft サーバー内部のさまざまな情報をメトリクスとして取得できるようになります。
例えば、以下のような情報があります。
- TPS
- Tickの平均処理時間
- オンラインプレイヤー数
- ワールドごとの読み込みチャンク数
- ワールドごとのエンティティ数
- ワールドデータのサイズ
- JVMのメモリ使用量
特に今回の監視では、TPS、Tickの処理時間、エンティティ数、読み込み済みチャンク数などを重点的に見ています。
例えば、ワールドごとのエンティティ数は mc_entities_total、読み込み済みチャンク数は mc_loaded_chunks_total として取得できます。
今回のように大量のゾンビピグリンが原因でサーバー負荷が急上昇したケースでは、TPSが低下していることだけでなく、エンティティ数が急増しているといった変化も Grafana 上から確認できます。
また、mc_jvm_memory からJVMのメモリ使用状況、mc_world_size からワールドデータのサイズなども取得できます。
次は、ここで公開した Prometheus メトリクスを Grafana Alloy から取得して、Grafana Cloud へ送信していきます。
Grafana Alloy から Grafana Cloud へメトリクスを送る
Grafana Alloy を VPS にインストール
Grafana Alloy は、メトリクスやログなどのテレメトリデータを収集して、Grafana Cloud などへ送信するためのエージェントです。
今回は Minecraft サーバーと同じ VPS に Grafana Alloy をインストールし、Minecraft Prometheus Exporter が公開している /metrics エンドポイントを定期的に scrape するように設定しました。
ここでいう scrape とは、Alloy が定期的に /metrics へアクセスして、その時点のメトリクスを取得することです。
取得したメトリクスは、Grafana Cloud へ送信します。
VPS 自体のメトリクスも取得する
Alloy では Minecraft のメトリクスだけでなく、Minecraft サーバーが動いている VPS 自体のメトリクスも収集するようにしました。
主に確認しているのは以下のような情報です。
- CPU 使用率
- Load Average
- メモリ使用量
- ディスク使用量
- Disk I/O
- Network I/O
Minecraft サーバーを監視するだけなら TPS や Tick の処理時間を見るだけでもある程度の異常は検知できます。
しかし、それだけでは「Minecraft が重くなっていること」は分かっても、「なぜ重くなっているのか」までは分からないことがあります。
例えば TPS が低下したタイミングで CPU 使用率や Load Average も大きく上昇していれば、CPU 負荷との関連を疑えます。
一方で CPU に余裕があるにもかかわらず TPS が低下しているのであれば、Disk I/O や Minecraft 内部の処理など、別の原因を調べる手掛かりになります。
両方を同じ Grafana ダッシュボード上で時系列に沿って確認できるようにしておくことで、問題が発生したときに、そのタイミングでサーバー全体に何が起きていたのかを追いやすくなります。
Grafana で Minecraft 用ダッシュボードを作る
Grafana Cloud に送信したメトリクスを使って、Minecraft サーバーの状態を確認するためのダッシュボードを作成しました。
ダッシュボードでは Minecraft 内部の状態だけでなく、VPS や JVM、ストレージ、ネットワークの状態もまとめて確認できるようにしています。
実際に作成したダッシュボードがこちらです。
大きく以下の4つのセクションに分けています。
- Server Status：プレイヤー数やTPS、MSPTなど、現在の状態
- Minecraft Performance：TPS、MSPT、エンティティ数、読み込みチャンク数など
- VPS / JVM：CPU、メモリ、Load Average、JVMの状態など
- Storage / Network：ディスク、ネットワーク、ワールドサイズなど
普段は上部の Server Status を見るだけで大まかな状態が分かり、異常があった場合は下のグラフから原因を調べられるような構成にしています。
TPS / MSPT
Minecraft サーバーの状態を確認するうえで、まず見るようにしているのが TPS と MSPT です。
TPS（Ticks Per Second）は Minecraft が1秒間に処理できている Tick 数で、正常な状態では基本的に 20 を維持します。
MSPT（Milliseconds Per Tick）は 1 Tick の処理にかかった時間です。Minecraft は1秒間に 20 Tick 処理するため、単純計算では 1 Tick あたり 50 msを超える処理が続くと、TPS 20 を維持できなくなります。
ダッシュボード上部には現在の TPS と平均・最大 MSPT を大きく表示し、その下には時系列のグラフも配置しました。
プレイヤー数
現在サーバーに接続しているプレイヤー数も表示しています。
ダッシュボード下部ではプレイヤーがどのディメンションにいるのかも確認できるようにしています。
プレイヤー数そのものを見るだけでなく、TPS やエンティティ数などと並べることで、どのタイミングで、どのディメンションにプレイヤーがいたのかを負荷調査の手掛かりにできます。
エンティティ数
エンティティ数は、読み込まれているエンティティ数をワールドごとに表示しています。
- オーバーワールド
- ネザー
- エンド
これは今回監視環境を作るきっかけになった、大量のゾンビピグリンが特定の場所に溜まってしまった問題を調査するうえでも重要なメトリクスです。
普段は数百体程度だったエンティティ数が突然数千、数万と増えていれば、TPSが大きく低下する前でも異常に気付ける可能性があります。
ただし、このメトリクスだけでは「ゾンビピグリンが何体いるか」や「どのチャンクに集中しているか」までは分かりません。そのため、異常な増加を発見するための指標として利用し、必要に応じて Minecraft 側で詳しく調査します。
読み込み済みチャンク数
現在読み込まれているチャンク数をワールドごとに表示しています。
Minecraft ではプレイヤーの移動やチャンクローダーなどによって読み込まれるチャンク数が変化します。
エンティティ数と一緒に確認することで、「読み込みチャンクが急激に増えている」 や「チャンク数は変わっていないのにエンティティだけ増えている」といった違いも確認できます。
JVM メモリ
Minecraft サーバーは Java 上で動作しているため、JVM のメモリについてもダッシュボードに表示しています。
グラフでは主に、
- JVM が確保しているメモリ
- 実際に使用しているメモリ
- JVM に設定されている最大メモリ
を確認できます。
Minecraft サーバーのメモリ使用量がどのように変化しているかを、VPS 全体のメモリ使用量と比較できるようにしています。
VPS のリソース
Minecraft 内部のメトリクスだけでは原因を判断できないこともあるため、VPS 側についても同じダッシュボードで確認できるようにしました。
現在は主に以下を表示しています。
- CPU 使用率
- Load Average
- メモリ使用量
- I/O Wait
- CPU Steal
- ディスク使用率
- Disk Read / Write Throughput
- Disk Read / Write Latency
- Network RX / TX
例えば TPS や MSPT が悪化した時間帯に I/O Wait やディスクレイテンシも上昇していれば、ストレージ I/O が影響している可能性を考えられます。
逆に Minecraft 側のエンティティ数だけが急増していれば、ゲーム内の装置や Mob などを疑う、といった切り分けができます。
ワールドサイズ
おまけとして、各ワールドの現在のディスク使用量も表示しています。
オーバーワールド、ネザー、エンドを分けて表示しているため、探索などによってどのワールドが大きくなっているのかを簡単に確認できます。
サーバー負荷をリアルタイムに判断するための指標ではありませんが、別途サーバーのバックアップ処理を行っているため、その際の参考値となります。
TPSが18未満になったらDiscordへ通知する
ダッシュボードを作ったことでサーバーの状態を確認できるようになりましたが、異常に気付くために常にGrafanaを見ているわけにはいきません。
そこで、TPSが一定時間低下した場合に Discord へ自動でアラートを送信するようにしました。
Grafana Alerting で TPS の低下を検知する
Grafana Alerting では、収集しているメトリクスに対して条件を設定し、その条件を満たした場合にアラートを発火できます。
今回は Minecraft サーバーのTPSに対して、次の条件を設定しました。
- TPS が18未満の状態が2分以上継続した場合
TPS が一瞬だけ低下することはあるため、18を下回った瞬間に通知するのではなく、2分以上継続した場合のみアラートを発火するようにしています。
これによって、一時的な負荷による通知をある程度抑えつつ、サーバーの性能低下が続いている場合には気付けるようにしました。
アラートを Discord へ通知する
アラートの通知先には、普段から確認しやすい Discord を使用しました。
Grafana 側で Discord を Contact point として設定しておくことで、アラートが発火した際に Discordへ通知できます。
また、TPS が回復してアラート条件から外れた場合にも復旧通知が届くようにしています。
これによって、
TPS 低下 → Discord へアラート → Grafana で状況を確認 → TPS 回復 → Discord へ復旧通知
という流れでサーバーの状態を把握できます。
Discord の通知を見やすくする
Grafana から送られるデフォルトの通知は情報量が多く、Minecraft サーバーの監視用途としては少し確認しづらかったため、通知内容もカスタマイズしました。
アラートを受け取ったときに「何が起きているのか」がすぐ分かるように、Minecraft サーバー名やアラートの内容、TPS など、必要な情報を中心に表示しています。
実際の通知はこのようになりました。
上の赤い通知がアラート発火時、下の緑色の通知がTPS回復後の復旧通知です。
この通知によって、今回の監視環境を作るきっかけになったゾンビピグリンの大量発生でも、TPS低下を早い段階で検知できれば、サーバーが操作できないほど重くなる前に異常に気付ける可能性があります。
ダッシュボードだけでなく、Discord 通知による異常の検知まで自動化したことで、普段 Grafana を開いていなくてもサーバーの状態を監視できるようになりました。
まとめ
ゾンビピグリンファームで起きたパフォーマンス低下をきっかけに、
- Minecraft の Prometheus メトリクスを取得
- Grafana Alloy で収集
- Grafana Cloud へ保存
- Grafana Dashboard で可視化
- TPS 低下を Grafana Alerting で検知
- Discord へ通知
という監視環境を構築しました。
Minecraft サーバーは普段正常に動いていても、装置の故障や大量のエンティティなど、ちょっとしたきっかけで急激に負荷が上がることがあります。
常に管理画面を眺めるのではなく、異常が起きたら通知される状態にしておくことで、サーバーの運用はかなり楽になると思います。
