Мониторинг серверов Minecraft: что мерить и как настроить

Лагающий Minecraft-сервер опознаётся не по тревожной лампочке в панели хостинга, а по раздражённым сообщениям в Discord: «опять фризы», «меня откинуло», «блоки не ставятся». Пинг при этом может быть безупречным — процесс жив, порт открыт, status-запрос отвечает, но тик-луп уже не укладывается в 50 мс, а сборщик мусора подвешивает JVM на секунды. Мониторинг нужен не ради красивых графиков, а чтобы поймать деградацию до того, как игроки начнут уходить.

Причина в природе игры: Minecraft — однопоточная tick-based система, мир обновляется 20 раз в секунду. Если цикл не укладывается в отведённые 50 мс, начинаются фризы. Красный индикатор в панели хостинга здесь плохой помощник: сервер отвечает на status-запрос, порт открыт, процесс жив — а играть невозможно.

Минимальный набор метрик, дающий реальную картину, выглядит так:

• TPS (ticks per second) — сколько тиков сервер успевает обработать. Норма 20.0, 19.5 уже заметно, 17 и ниже — играть невозможно.
• MSPT (milliseconds per tick) — время обработки одного тика. Чувствительнее TPS: деградация видна раньше, чем просядет сам TPS.
• Память JVM — heap used/max и, что важнее, частота и длительность пауз сборщика мусора.
• Онлайн и вход/выход игроков — помогают отличить «сервер лагает» от «сервер пустой».
• Задержка отклика, ошибки плагинов, ресурсы машины — CPU, диск (I/O загрузки чанков), сеть.

TPS 20.0 при онлайне два человека и при онлайне восемьдесят — две разные вселенные. Любые пороги имеет смысл смотреть в связке с количеством игроков и типом сборки: одиночный сервер на ваниле и ферма редстоуна на 200 модов ведут себя по-разному.

Начинать с Prometheus не обязательно. Есть лестница решений — от пятиминутного скрипта до полноценной observability-платформы. Пинг и status-запрос (mcstatus, Uptime Kuma, uptime-боты) дают аптайм, онлайн и задержку отклика при низкой сложности, но не видят TPS, MSPT и лагов внутри игры. Скрипты через RCON отдают TPS, MSPT, список игроков и свои команды — средняя сложность, зато нужен включённый RCON и история метрик из коробки отсутствует. Связка Prometheus + exporter + Grafana обеспечивает полную телеметрию, историю, алерты и дашборды, но требует поднять и поддерживать стек. Плагины вроде Spark и Plan дают профилирование и поиск узкого места, однако внешние алерты через них неудобны. Zabbix и внешний мониторинг следят за машиной целиком — CPU, диск, сеть, сервисы — и часто избыточны для одного-двух серверов.

Оптимальная схема для большинства проектов: внешний пинг для аптайма плюс RCON-проверки для TPS плюс Spark, когда нужно разобраться в конкретном лаге. Prometheus имеет смысл, если серверов несколько или нужна история за месяцы.

Готовые экспортеры умеют опрашивать Minecraft по status-протоколу и по RCON, отдавая метрики в формате Prometheus. Простейший вариант — поднять его в Docker рядом с сервером:

docker-compose.yml
services:
  mc-exporter:
    image: dirien/minecraft-prometheus-exporter:latest
    restart: unless-stopped
    ports:
      - '9150:9150'
    command:
      - '--server.host=<IP>'
      - '--server.port=25565'
      - '--rcon.host=<IP>'
      - '--rcon.port=25575'
      - '--rcon.password=change-me'
  prometheus:
    image: prom/prometheus:latest
    restart: unless-stopped
    ports:
      - '9090:9090'
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml
  grafana:
    image: grafana/grafana:latest
    restart: unless-stopped
    ports:
      - '3000:3000'

Набор флагов у разных образов отличается, поэтому первый запуск стоит делать с --help и сверяться с README. Дальше Prometheus должен узнать, откуда тянуть метрики:

prometheus.yml
global:
  scrape_interval: 15s
scrape_configs:
  - job_name: 'minecraft'
    static_configs:
      - targets: ['mc-exporter:9150']
rule_files:
  - 'alerts.yml'

В Grafana источником данных выбирается Prometheus, а готовые дашборды для Minecraft-экспортеров лежат в публичной библиотеке Grafana — импортируются по ID за пару кликов. Через 15–20 минут накопятся графики, по которым уже видно суточный профиль нагрузки.

Если поднимать стек не хочется, хватит одного скрипта. Важно, что через RCON доступны команды, которые не отдаёт ни один статус-запрос:

разовый опрос TPS по RCON (mcrcon)
mcrcon -H 127.0.0.1 -P 25575 -p пароль 'tps'
# ответ: TPS from last 1m, 5m, 15m: 19.87, 20.0, 19.99

список игроков
mcrcon -H 127.0.0.1 -P 25575 -p пароль 'list'

В консоли сервера (Bukkit/Spigot/Paper) в server.properties обязательно: enable-rcon=true, rcon.port=25575, rcon.password=надёжный_пароль.

Пинг проще и безопаснее — RCON-порт не должен смотреть в интернет. Проверка статуса на Python выглядит так:

from mcstatus import JavaServer
import time
server = JavaServer.lookup('<IP>:25565')
while True:
    try:
        status = server.status()
        print(f'online={status.players.online} ping={status.latency:.1f}ms')
        if status.players.online == 0 and status.latency > 400:
            print('подозрение на деградацию')
    except Exception as e:
        print('SERVER DOWN:', e)
    time.sleep(30)

RCON-пароль — это фактически админский доступ к серверу. Слушайте порт только на 127.0.0.1 или закрывайте файрволом: перебор пароля здесь означает полный контроль над игровым миром.

График без уведомления полезен только тому, кто на него смотрит. Разумные значения, от которых можно отталкиваться: TPS за минуту в норме 19.5–20.0, тревога ниже 19.0, критично ниже 17.0. MSPT до 35 мс — норма, 35–50 мс — тревога, выше 50 мс — критично. Heap used/max до 70% — норма, 70–85% — тревога, выше 85% и частые GC — критично. Задержка status-ответа до 100 мс — норма, 100–300 мс — тревога, больше 300 мс или отсутствие ответа — критично. Онлайн — по профилю проекта: резкое падение или ситуация, когда процесс жив, но игроки не заходят, требует внимания.

Алерт на TPS стоит делать не мгновенным, а с выдержкой: условие «TPS меньше 19 в течение 5 минут» отсекает ложные срабатывания от сохранения мира или запуска бэкапа. Уведомления удобно отправлять в Discord-вебхук — дежурный увидит их там же, где сидят игроки.

Проверяйте не только сервер, но и себя. Мониторинг с той же машины упадёт вместе с ней — внешний пинг с другого хостинга или uptime-сервиса обязателен. Логи тоже метрика: простой grep по слову Exception раз в минуту с алертом на рост числа совпадений ловит проблемы до падения. Не мониторьте то, что не будете чинить: сто метрик без ответственного превращаются в шум и привычку игнорировать уведомления. Замеряйте после обновления — новая версия ядра или плагина меняет профиль нагрузки, сравните сутки до и после. Для разбора конкретного лага есть Spark: команда /spark profiler start собирает профиль за 30 секунд и показывает, какой мод или чанк съедает тик. Порог по онлайну бесполезен без контекста: падение до нуля ночью — норма, падение до нуля в прайм-тайм при живом процессе — уже повод для проверки.

По ресурсам: экспортер и Prometheus на одном сервере с игрой съедают заметную часть CPU, поэтому лучше вынести стек на отдельную машину. Для трёх-четырёх серверов хватит самого слабого VPS с 1 ГБ памяти.

Практика показывает: почти каждый раз, когда поступает жалоба «сервер лагает», проблема оказывается не в железе и не в сети, а в одном-двух чанках с фермами или в моде-плагине, который раз в минуту обходил все сущности в мире. Без истории метрик поймать это почти невозможно — в момент прихода админа сервер уже отдыхал. Поэтому первое, что стоит ставить на новый проект, — не оптимизацию, а сбор TPS и алерт на пятиминутное падение ниже 19. График за неделю отвечает на вопросы быстрее, чем час чтения логов. Формула проста: внешний пинг для аптайма, RCON-опрос TPS для здравости тик-лупа, Grafana с историей для разбора инцидентов. Этого хватит, чтобы перестать узнавать о проблемах от игроков.