Мониторинг серверов Minecraft в 2026: полный гайд по инструментам, плагинам и интеграциям

Содержание

• Зачем нужен мониторинг сервера Minecraft: ключевые метрики и проблемы
• Встроенные средства мониторинга: Timings и консоль сервера
• Плагины для глубокого мониторинга производительности
• Внешние сервисы мониторинга и интеграция с Zabbix/Prometheus
• Мониторинг онлайна, алерты и защита от DDoS-атак
• Типовые сценарии: диагностика TPS, поиск лагов и утечек памяти
• Частые ошибки и проблемы при настройке мониторинга

Кратко

• TPS и MSPT — основные показатели игрового цикла. Целевое значение — около 20 TPS, но кратковременная просадка не всегда означает проблему. Оценивайте TPS вместе с MSPT, онлайном и характером нагрузки.
• Spark помогает быстро найти причину лагов. Начните с команд /spark health и /spark profiler start --timeout 300, а синтаксис конкретного релиза проверьте через /spark help.
• Plan нужен для долгосрочной аналитики. Он помогает увидеть историю TPS, онлайна и показателей сервера, но доступные метрики и период хранения зависят от версии и конфигурации.
• Prometheus + Grafana подходят для нескольких серверов. Связка централизует сбор метрик и позволяет настроить алерты в Telegram, Slack или email.
• Zabbix удобно подключать через RCON или экспортируемые метрики. Команда получения TPS и формат ответа зависят от ядра, поэтому скрипт нужно проверять на конкретном Paper/Spigot.

Матрица совместимости и дата проверки

Дата проверки материала: 21 августа 2026 года. Инструкции ориентированы на Paper и Spigot для Minecraft 1.16 и 1.21+, но команды, состав метрик и формат отчетов могут отличаться между ядрами и релизами.

Зачем нужен мониторинг сервера Minecraft: ключевые метрики и проблемы

Падение TPS ниже 15, вылеты с OutOfMemoryError и жалобы игроков на лаги — симптомы, которые знакомы каждому администратору Minecraft-сервера. Настроить мониторинг — значит получить инструмент для проактивного выявления этих проблем до того, как они обрушат игровой процесс. В этой статье разобраны практические методы контроля ключевых метрик: от встроенного Timings до интеграции с Prometheus и Zabbix для централизованного сбора данных и оповещений.

Вы узнаете, как найти плагин, который нагружает игровой тик, построить дашборд с графиками онлайна и потребления RAM за последние сутки и настроить автоматический алерт при падении сервера. Примеры ориентированы на ядра Paper и Spigot для версий 1.16 и 1.21+, но перед применением команду и формат вывода нужно сверить с конкретным релизом.

Сервер Minecraft — это Java-приложение, в котором основной игровой цикл должен обрабатывать тик примерно за 50 миллисекунд. Часть задач может выполняться асинхронно, но задержки в основном тике сразу влияют на физику, ИИ мобов, генерацию чанков и события плагинов. Если обработка занимает больше 50 миллисекунд, TPS снижается, игроки ощущают задержки, а механизмы начинают работать с перебоями.

Для практического мониторинга показатели удобно разделить на четыре группы.

Производительность сервера

• TPS (ticks per second) — частота обработки тиков. Целевое значение — около 20, но кратковременные значения 18–19 не всегда требуют вмешательства. Измеряйте через /spark health, Timings или команду ядра, если она доступна.
• MSPT — среднее время обработки тика. Значение около 50 мс соответствует пределу для 20 TPS; устойчивый рост выше этого уровня указывает на перегрузку игрового цикла.
• Загрузка CPU — проверяется через Spark и системные средства, например node_exporter. Постоянная загрузка одного ядра выше 80% при небольшом онлайне — повод для профилирования, но порог зависит от CPU и типа нагрузки.

JVM и память

• Java heap used — занятая часть кучи JVM. Она может временно расти до запуска сборщика мусора и сама по себе не доказывает утечку.
• Committed и max heap — выделенная JVM память и установленный максимальный размер. Committed может быть заметно больше текущего used и не равен фактическому потреблению процесса.
• RSS процесса — память, которую процесс занимает в операционной системе или контейнере. Она включает heap, native memory, буферы и библиотеки, поэтому не совпадает с показателем Java heap.
• Измеряйте показатели через /spark health, /spark heapsummary, системный мониторинг и metrics экспортера. Утечку подтверждайте сравнением состояния после сборки мусора и повторными замерами.

Игровой онлайн и активность

• Количество игроков — берите из Plan, команды /list, RCON или экспортера. Сопоставляйте онлайн с TPS и нагрузкой на CPU.
• Загруженные чанки и сущности — помогают отличить нагрузку от исследования мира, ферм и генерации чанков от проблем конкретного плагина. Источник показателя зависит от Spark, ядра и экспортера.

Доступность и сеть

• Доступность TCP-порта и Server List Ping — проверяют, отвечает ли сервер извне. Для алерта при полном падении используйте внешний или отдельный системный мониторинг: exporter внутри Minecraft остановится вместе с сервером.
• Входящий трафик, TCP-соединения и ошибки сети — помогают заметить сетевую перегрузку или DDoS-, но не доказывают атаку без анализа источников и логов.

Мониторинг превращает эти цифры в actionable-информацию. Вы не просто видите, что TPS упал, а сопоставляете момент просадки с CPU, памятью, чанками, логами и профилем плагинов. Без системы сбора metrics вы реагируете на последствия — краши и жалобы. С ней — на причины.

Встроенные средства мониторинга: Timings и консоль сервера

Ядра Paper и Spigot могут предоставлять базовые инструменты без установки дополнительных плагинов: систему Timings и консольный вывод. Их удобно использовать для первичной диагностики, но доступность команд и формат отчета нужно проверять на конкретной версии. В современных сборках Paper для детального профилирования чаще выбирают Spark.

Timings — профайлер, который показывает время выполнения обработчиков событий, плагинов и задач в рамках тика. В сборках, где команда доступна, сбор запускается через /timings on, а после воспроизведения проблемы отчет можно сформировать командами, поддерживаемыми конкретным ядром, например /timings paste или /timings report. Перед началом выполните /timings или проверьте справку ядра. Не оставляйте сбор включенным постоянно без необходимости: это создает дополнительную нагрузку и усложняет анализ.

Как читать отчет Timings: пошаговый разбор

Открыв отчет, обратите внимание на три секции, если они присутствуют в используемом формате:

1. Total Server Time — суммарное время обработки тиков. Сопоставляйте его с пределом около 50 мс и фактическим MSPT, а не только с процентом в отчете.
2. Plugins Breakdown — таблица с распределением времени по плагинам. Сортируйте по столбцу Pct Total, но не считайте значение выше 15–20% автоматическим доказательством неисправности. Важно, воспроизводится ли проблема и каков абсолютный вклад плагина.
3. Events & Tasks — детализация по событиям и задачам. Например, высокая доля EntityDamageEvent может указывать на плагин, который изменяет обработку урона, но вывод нужно подтвердить профилем Spark и конфигурацией.

Консоль сервера дополняет картину. Сообщения вида Can't keep up! Is the server overloaded? с указанием отставания в тиках — сигнал о том, что игровой цикл не успевает обработать нагрузку. Предупреждения о превышении лимита чанков (chunk load limit exceeded) указывают на механизмы или плагины, форсирующие загрузку миров.

Ограничения встроенных средств: Timings показывает усредненную картину и не предназначен для подтверждения утечек памяти. Консольный вывод не структурирован и теряется при перезапуске, если логи не сохраняются отдельно. Для анализа JVM, CPU и длительных трендов нужны специализированные плагины и внешние системы.

Когда использовать: для быстрой первичной диагностики без установки дополнительного ПО. Если нужно проверить, какие события и плагины нагружают тик, Timings может быть полезен при условии, что он поддерживается ядром.

Плагины для глубокого мониторинга производительности

Экосистема Bukkit предлагает инструменты с разными задачами: Spark для профилирования в реальном времени, Plan для долгосрочной визуализации и ClearLag для контроля сущностей. Выбор зависит от задачи: найти причину лагов прямо сейчас — Spark, анализировать тренды — Plan, автоматически управлять сущностями — ClearLag. ClearLag не заменяет профилирование и может скрыть первопричину нагрузки, поэтому применять его следует после диагностики.

Spark: профилирование CPU, памяти и TPS

Spark часто используют как основной инструмент профилирования Minecraft-сервера. Для Paper и Spigot он устанавливается как плагин, а для Fabric и Forge доступна другая форма интеграции. Совместимость зависит от конкретного релиза, поэтому перед установкой проверьте поддерживаемую версию Minecraft и ядро. Копирование JAR-файла в папку plugins применимо к Bukkit-совместимому варианту.

Ключевые команды для диагностики:

• /spark health — снимок состояния: TPS, MSPT, загрузка CPU, показатели памяти, количество игроков и часть сведений о чанках. Набор полей может отличаться между версиями. Запускайте команду первым делом при жалобах на лаги.
• /spark profiler start --timeout 300 — пример запуска профилирования на 5 минут. В некоторых версиях синтаксис или способ открытия результата отличается; используйте /spark help, а после завершения — команду, которую подскажет Spark. Flame-граф показывает, какие методы и потоки занимают процессорное время.
• /spark heapsummary — сводка по объектам и классам в heap JVM. Результат полезен для поиска подозрительного роста, но не доказывает утечку без сравнения во времени и проверки после GC.
• /spark heapdump — полный дамп кучи, если команда доступна в установленном релизе. Файл может занимать гигабайты и временно увеличить нагрузку на диск и сервер.

Практический пример: сервер на 1.21 с 20 игроками начал выдавать 15 TPS. /spark health показал высокую загрузку CPU, а профиль за 5 минут выявил, что плагин кастомной генерации руды тратил значительную долю процессорного времени. После отключения проблемной логики TPS восстановился. Такой результат нужно подтверждать повторным профилированием, а не делать вывод только по одному широкому блоку flame-графа.

Когда использовать: при активных проблемах с производительностью — лагах, низком TPS, высоком MSPT или подозрении на утечку памяти. Spark дает детальную картину в реальном времени, но команда и состав результата зависят от версии.

Plan: визуализация статистики и веб-панель

Plan собирает и хранит данные о сервере и игроках в базе данных, обычно SQLite или MySQL, и предоставляет доступ к ним через встроенный веб-сервер. После установки веб-панель часто доступна по адресу http://ваш-сервер:8804, если веб-сервер включен и порт не изменен. Проверьте фактический порт в конфигурации и не публикуйте административную панель без аутентификации и сетевых ограничений.

Возможности Plan зависят от версии и конфигурации, но обычно включают:

• Графики TPS, онлайна и части показателей сервера за выбранный период.
• Индивидуальную статистику по игрокам: время игры, события и активность.
• Интеграционный API и экспорт данных, если они включены и поддерживаются конкретным релизом.

Plan полезен для анализа долгосрочных трендов. Вы видите, что каждую субботу в 20:00 TPS проседает, и можете сопоставить это с онлайном, расписанием задач или активностью плагинов. Plan не следует считать заменой Spark для поиска конкретного метода и универсальной системой критических алертов: для пороговых уведомлений надежнее использовать Prometheus/Alertmanager или Zabbix.

Настройка Plan детально описана в руководстве по оптимизации сервера Minecraft.

Когда использовать: для анализа исторических данных, онлайна и повторяющихся закономерностей. Если нужно понять, как сервер вел себя за последний месяц, Plan удобнее профайлера, но доступный период хранения зависит от базы данных и настроек.

Внешние сервисы мониторинга и интеграция с Zabbix/Prometheus

Когда у вас больше одного сервера или мониторинг Minecraft — часть общей IT-инфраструктуры, плагинов недостаточно. Нужен централизованный сбор metrics, единый дашборд и система алертов. Два основных подхода: связка Prometheus + Grafana и Zabbix, если он уже развернут в инфраструктуре.

Мониторинг Minecraft через Prometheus и Grafana

Prometheus собирает metrics по HTTP, опрашивая экспортеры — специальные сервисы, которые преобразуют внутренние показатели приложения в формат системы мониторинга. Для Minecraft используется mc-prometheus-exporter или совместимый exporter. Название плагина, порт, имена metrics и путь endpoint зависят от конкретного релиза, поэтому не переносите конфигурацию между версиями без проверки.

Пошаговая настройка:

1. Установите совместимый релиз mc-prometheus-exporter в папку plugins. Пример ниже предполагает, что exporter публикует metrics по адресу http://localhost:9225/metrics. Проверьте порт в конфигурации и журнале запуска.
2. Откройте endpoint локально и убедитесь, что он возвращает текстовые metrics. Найдите фактическое имя метрики TPS, CPU и памяти: оно может отличаться от minecraft_tps, использованного в примере алерта.
3. Добавьте в конфигурацию Prometheus (prometheus.yml) новую job:
   

   scrape_configs:
     - job_name: 'minecraft'
       static_configs:
         - targets: ['localhost:9225']

4. Перезапустите или перечитайте конфигурацию Prometheus и проверьте статус target в его интерфейсе. Метрики должны иметь состояние UP.
5. Создайте в Grafana собственные панели для TPS, MSPT, RAM, онлайна, CPU, доступности и ошибок scrape. Не используйте фиктивный ID дашборда: готовый dashboard подходит только после проверки имен metrics и единиц измерения.

Полная инструкция по развертыванию стека с нуля, включая установку node_exporter для системных показателей, приведена в материале по настройке Prometheus и Grafana.

Когда использовать: если у вас несколько Minecraft-серверов или вы хотите объединить игровые серверы с общей IT-инфраструктурой. Prometheus + Grafana дают гибкий сбор и визуализацию, но требуют контроля кардинальности metrics и хранения.

Интеграция с Zabbix: шаблоны и алерты

Zabbix не имеет универсального встроенного экспортера для Minecraft, но показатели можно собирать через RCON-скрипты, выполняемые Zabbix Agent, либо через HTTP endpoint exporter. Принцип работы RCON-варианта: агент по расписанию запускает скрипт, подключается к серверу по RCON, выполняет команду, парсит вывод и возвращает числовое значение.

Команда tps доступна не во всех ядрах. В Paper она обычно присутствует, а в Spigot может отсутствовать или добавляться отдельным плагином. Команда list подходит для получения онлайна, но ее вывод также нужно проверять. Не используйте универсальное регулярное выражение, которое просто берет первое число из ответа: оно может извлечь не TPS, а длительность периода или другой параметр.

Пример скрипта для формата, где значение TPS идет после двоеточия:

#!/bin/bash
set -euo pipefail
source /etc/zabbix/scripts/minecraft-rcon.env
out=$(mcrcon -H 127.0.0.1 -P 25575 -p "$RCON_PASSWORD" 'tps')
tps=$(printf '%s\n' "$out" | sed -n 's/.*:[[:space:]]*\([0-9][0-9.]*\).*/\1/p' | head -n 1)
if [ -z "$tps" ]; then
  echo ZBX_NOTSUPPORTED
  exit 1
fi
printf '%s\n' "$tps"

Этот parser рассчитан на конкретный формат ответа и может потребовать изменения для другой версии, локализации или плагина. Если сервер возвращает локализованный текст, проверяйте реальный вывод и завершайте скрипт с ошибкой при невозможности разобрать значение, а не отправляйте в Zabbix ноль.

Файл с паролем должен быть доступен только пользователю, который запускает скрипт, например с правами 600. Не храните пароль в открытом UserParameter, не публикуйте RCON-порт в Интернет и ограничьте доступ к нему loopback-адресом или firewall. Скрипт должен иметь минимальные права и не позволять передавать произвольные команды через параметры Zabbix.

В конфигурации Zabbix Agent добавляется пользовательский параметр:

UserParameter=minecraft.tps,/etc/zabbix/scripts/minecraft_tps.sh

После настройки элемента данных создайте триггеры: TPS ниже 18 в течение 5 минут — ориентировочное предупреждение, ниже 15 в течение 2 минут — критический алерт. Эти значения нужно сверять с MSPT, онлайном и типом нагрузки. Аналогично настраиваются мониторинг онлайна, доступности TCP-порта и ошибки выполнения скрипта.

Когда использовать: если Zabbix уже развернут в вашей инфраструктуре и вы хотите добавить Minecraft-серверы в существующую систему без внедрения нового стека.

Мониторинг онлайна, алерты и защита от DDoS-атак

Отслеживание количества игроков — базовая, но важная функция. Падение онлайна до нуля в нехарактерное время может означать краш сервера, сбой сети или изменение расписания. Для мониторинга онлайна используйте три уровня контроля:

• Плагины — Plan и Spark показывают текущий онлайн и часть истории. Этого достаточно для ретроспективного анализа, но не для независимого алерта при полном падении процесса.
• Внешние мониторинги — системы, которые выполняют Server List Ping, отображают доступность публичного сервера. Они подходят для контроля доступности, но не всегда показывают причину лагов и не заменяют внутренние metrics.
• Собственные скрипты — bash-скрипт, выполняемый по cron или Zabbix Agent, проверяет доступность порта 25565 и количество игроков через RCON. При отклонении от нормы он отправляет алерт.

DDoS-атака на Minecraft-сервер может проявляться ростом входящего трафика, массовыми попытками подключения и, как следствие, лагами или полной недоступностью. Количество соединений в состоянии SYN_RECEIVED, трафик на порт 25565 и сообщения о превышении лимита подключений — индикаторы для расследования, а не универсальные доказательства атаки. Порог 500 соединений или рост до 100+ Мбит/с нужно оценивать с учетом канала, хостинга и обычного профиля нагрузки.

Базовые меры защиты: настройте firewall с осторожностью, учитывая пользователей за NAT, используйте TCPShield или аналогичный прокси-сервис для фильтрации трафика и держите ядро сервера обновленным. Правило iptables -A INPUT -p tcp --dport 25565 -m connlimit --connlimit-above 5 -j DROP является только примером и не должно без проверки применяться в рабочей среде: оно может заблокировать легитимные подключения с общего IP.

Настройка оповещений в Discord/Telegram

Автоматические оповещения замыкают контур мониторинга. Вы не привязаны к дашборду — система сама сообщит о проблеме. Для рабочих алертов используйте источник, который остается доступным при падении самого Minecraft-процесса.

Через плагины. Возможности Plan для вебхуков и событий зависят от версии и конфигурации. Проверяйте фактический раздел уведомлений в установленном релизе и не рассчитывайте на Plan как на единственный канал сообщения о полном отключении сервера.

Через Alertmanager для Prometheus. Настройте правило алерта в Prometheus. Имя minecraft_tps в примере является условным: замените его на фактическое имя метрики из endpoint:

groups:
  - name: minecraft
    rules:
      - alert: MinecraftLowTPS
        expr: minecraft_tps < 15
        for: 2m
        labels:
          severity: critical
        annotations:
          summary: 'TPS упал ниже 15 на сервере {{ $labels.instance }}'

Alertmanager отправит уведомление в Telegram, Slack или на email согласно настроенным ресиверам. Инструкция по настройке Alertmanager с нуля есть в гайде по стеку мониторинга.

Ориентировочные пороги алертов

Пороги ниже не являются универсальной нормой. Выберите базовый уровень после наблюдения за сервером в обычные и пиковые часы, а затем корректируйте его по числу игроков, версии ядра и типу нагрузки.

Типовые сценарии: диагностика TPS, поиск лагов и утечек памяти

Теория мониторинга превращается в практику, когда сервер начинает тормозить. Разберем сначала общий алгоритм, а затем два частых сценария с пошаговой диагностикой.

Что проверить при падении TPS

1. Подтвердите симптом. Снимите значения TPS и MSPT через /spark health. Команду /tps используйте только после проверки, что она доступна в вашем Paper, Spigot или установленном плагине.
2. Проверьте состояние процесса. Зафиксируйте CPU, Java heap used, committed/max heap, RSS, онлайн и число загруженных чанков. Один показатель не позволяет определить причину.
3. Соберите профиль во время проблемы. Запустите /spark profiler start --timeout 300 или синтаксис, указанный в /spark help. Профилирование вне инцидента может не показать проблемную ветку.
4. Сопоставьте нагрузку. Проверьте CPU и память на уровне ОС, активность генерации чанков, сущности, задачи плагинов и сообщения логов, включая Can't keep up! Is the server overloaded?.
5. Измените только одну переменную. Отключите или перенастройте подозрительный плагин в окне обслуживания. Для теста не полагайтесь на /plugman unload НазваниеПлагина: hot-unload может оставить обработчики и ресурсы. Надежнее остановить сервер, убрать JAR и запустить его снова.
6. Повторите измерение. Сравните TPS, MSPT и профиль после изменения с исходными значениями. Если эффект исчез, верните изменение в рабочую конфигурацию только после проверки логов и стабильности.

Сценарий 1: сервер лагает после установки нового плагина. Симптомы: TPS упал с 20 до 12 сразу после добавления плагина, в чате появились жалобы на задержки. Алгоритм:

1. Выполните /spark health — подтвердите низкий TPS, высокий MSPT и загрузку CPU.
2. Запустите профилирование на 5 минут через /spark profiler start --timeout 300, если такой синтаксис поддерживается установленной версией.
3. Откройте flame-граф и найдите методы нового плагина. Широкий блок — повод для проверки, но не единственное доказательство причины.
4. Временно отключите плагин безопасным способом и проверьте, восстановились ли TPS и MSPT. Если да, сравните конфигурацию и логи плагина перед заменой или оптимизацией.

Сценарий 2: постепенное падение TPS и рост потребления RAM в течение нескольких часов. Симптомы: сервер запускается с 20 TPS, через 6 часов TPS падает до 14, а Java heap или RSS растет. Это может быть утечка, но также результатом нормального расширения committed heap, кешей или роста числа загруженных объектов. Алгоритм:

1. Выполните /spark health и /spark heapsummary сразу после запуска. Сохраните значения Java heap used, committed/max heap и RSS.
2. Через 4–6 часов, когда проблема проявится, повторите измерения. При необходимости отдельно зафиксируйте состояние после плановой или ручной сборки мусора, если это допустимо для вашей среды.
3. Сравните отчеты. Ищите классы, объем которых растет непропорционально и не освобождается после GC. Например, рост HashMap$Node требует поиска владельца коллекции, но сам класс не указывает на конкретный плагин.
4. Определите плагин-владелец по пакету класса, конфигурации и логам, затем отключите его для контролируемой проверки. Не увеличивайте RAM как единственное исправление: это может только отсрочить проблему.

Анализ дампа памяти (heap dump) для поиска утечек

Когда heapsummary недостаточно, снимите полный дамп кучи командой /spark heapdump, если она доступна в установленной версии. Файл сохранится в папку плагина или в путь, указанный Spark, а его размер может достигать нескольких гигабайт. Перед операцией проверьте свободное место и влияние на производительность.

Для анализа используйте Eclipse Memory Analyzer (MAT) — инструмент, запускаемый на рабочей машине.

Порядок анализа в MAT:

1. Откройте дамп через File → Open Heap Dump.
2. Запустите Leak Suspects Report из автоматических предложений. MAT покажет подозрительные объекты и цепочки удержания.
3. Изучите Dominator Tree — дерево объектов, отсортированное по занимаемой памяти. Корневые элементы с аномально большим объемом — кандидаты на дополнительную проверку.
4. Для найденного объекта выполните Path to GC Roots → exclude weak references. Цепочка ссылок поможет определить, какой компонент удерживает объект.

Этот метод требует практики, но полезен для сложных случаев, когда проблема находится в сторонней библиотеке или в нетривиальном взаимодействии плагинов. Результат heap dump нужно сопоставлять с конфигурацией, логами и повторным замером: единичный большой объект не равен утечке.

Частые ошибки и проблемы при настройке мониторинга

Даже опытные администраторы допускают типичные ошибки при внедрении мониторинга Minecraft-серверов. Вот наиболее распространенные проблемы и способы их решения:

• Игнорирование базовых метрик. Многие сразу настраивают сложные дашборды, забывая про TPS, MSPT и показатели памяти. Начните с Spark health и доступности сервера, затем добавляйте историю Plan и внешние metrics.
• Слишком агрессивные пороги алертов. Алерт на TPS ниже 19 может срабатывать при каждой кратковременной просадке. Используйте ориентиры из таблицы и корректируйте их после наблюдения за нормальным профилем нагрузки.
• Неправильная интерпретация RAM. Рост Java heap committed или RSS не доказывает утечку. Сравнивайте used после GC, committed/max heap и RSS, а также проверяйте число игроков, чанков и кешей.
• Отсутствие исторических данных. Без хранения metrics за длительный период невозможно выявить тренды. Plan или Prometheus должны работать постоянно, а не только при возникновении проблем.
• Непроверенные команды и имена metrics. Команды Timings, Spark и /tps, порт exporter и имя minecraft_tps могут отличаться. Проверяйте /help, конфигурацию и фактический ответ /metrics.
• Неправильная интерпретация Timings. Высокий процент в Plugins Breakdown не всегда означает проблемный плагин. Учитывайте контекст, абсолютное время, MSPT и повторяемость результата.
• Пренебрежение RCON-безопасностью. Используйте сложные пароли RCON, ограничивайте доступ по IP, защищайте файл секретов и не открывайте RCON-порт в Интернет.
• Мониторинг только изнутри сервера. Если exporter и алертинг находятся в том же процессе Minecraft, его падение остановит и сбор metrics. Для доступности нужен отдельный Zabbix, Prometheus probe или внешний мониторинг.

FAQ

Какой TPS считается нормальным на Minecraft-сервере?

Целевой уровень — около 20 TPS при MSPT около 50 мс или ниже. Значения 18–19 могут быть допустимы во время кратковременной нагрузки, а устойчивое снижение ниже 15 обычно требует диагностики. Оценивайте показатель вместе с MSPT, онлайном и жалобами игроков.

Что лучше: Spark или Timings?

Spark удобнее для профилирования CPU, TPS, MSPT и памяти во время активного инцидента. Timings может помочь увидеть распределение времени по событиям и плагинам, если он доступен в конкретном Paper или Spigot. Это не взаимоисключающие инструменты, но для современных Paper при глубоком профилировании чаще выбирают Spark.

Как узнать, какой плагин лагает?

Снимите /spark health, затем запустите профилирование во время просадки TPS и сопоставьте flame-граф с логами и нагрузкой CPU. Не делайте вывод только по проценту в Timings или по названию самого тяжелого класса: подтвердите результат отключением или изменением конфигурации в контролируемом тесте.

Как настроить алерт при падении Minecraft-сервера?

Для полного падения используйте независимую проверку TCP-порта или Server List Ping через Zabbix, Prometheus probe или внешний мониторинг. Для просадки TPS применяйте Spark/Plan для анализа и Prometheus + Alertmanager или Zabbix для пороговых уведомлений. Внутренний exporter не может отправить алерт после остановки процесса Minecraft.

Систематический мониторинг превращает администрирование Minecraft-сервера из реактивного тушения проблем в управляемый процесс. Начните с Spark и базовой проверки TPS, MSPT, CPU и памяти. Добавьте Plan для отслеживания трендов, а при нескольких серверах — Prometheus + Grafana или интеграцию с уже работающим Zabbix. Каждый следующий шаг должен подтверждаться измерениями и повторной проверкой, а не только увеличением ресурсов.