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

Ваш Minecraft сервер работает отлично. Игроки строят, PvP-арены шумят, всё стабильно. А потом в один момент всё ложится. Игроки жалуются на лаги, консоль заваливается ошибками, TPS падает до нуля. Что произошло? Без мониторинга вы не узнаете, пока не станет слишком поздно.

Мониторинг это не роскошь для крупных проектов. Это базовая необходимость для любого сервера, который принимает игроков из интернета. В этой статье разберём всё: от простых команд в терминале до полноценного стека с Prometheus и Grafana, алертами в Discord и автоматическими скриптами реагирования.

Зачем вообще мониторить

Простой ответ: раннее обнаружение = быстрая реакция. DDoS-атака, которую вы заметили через 30 секунд, это одно. Атака, о которой вы узнали через 15 минут из жалоб в Discord, это совершенно другое.

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

Мониторинг даёт вам три вещи:

1. Видимость - вы понимаете, что происходит на сервере прямо сейчас
2. Историю - вы можете посмотреть, что было вчера, на прошлой неделе, месяц назад
3. Автоматизацию - система сама реагирует на аномалии, пока вы спите

Ключевые метрики: что отслеживать

Не все метрики одинаково важны. Вот те, на которые нужно смотреть в первую очередь.

Сетевые метрики

Connections per second (CPS) - количество новых TCP-соединений в секунду. Нормальное значение для среднего сервера: 1-10 в секунду. Если вы видите 100+, что-то не так. 1000+ - это почти гарантированно атака.

Bandwidth (Mbps) - потребление полосы пропускания. Minecraft не ест много трафика. 50 игроков генерируют примерно 10-20 Mbps. Если вы видите 500+ Mbps при 50 игроках, это не игроки.

Packet rate (pps) - количество пакетов в секунду. Важно для обнаружения пакетных флудов, которые могут не создавать большого трафика по объёму, но убивают CPU обработкой.

Серверные метрики

CPU - загрузка процессора. Minecraft однопоточный в основном цикле, так что следите за нагрузкой на конкретное ядро. Если одно ядро на 100%, а остальные свободны, это нормальная работа MC под нагрузкой. Если все ядра загружены, проблема скорее в сети.

RAM - потребление памяти. Следите не только за общим использованием, но и за поведением GC (сборщика мусора). Частые GC-паузы убивают TPS.

Disk I/O - чтение/запись на диск. Minecraft генерирует много I/O при сохранении чанков и данных игроков. Если I/O wait высокий, сервер будет лагать вне зависимости от атак.

Minecraft-специфичные метрики

TPS (Ticks Per Second) - главная метрика здоровья MC сервера. 20 TPS = идеально. 18-19 = нормально. Ниже 15 = игроки начнут замечать лаги. Ниже 10 = играть невозможно.

Player count - количество игроков. Внезапный скачок подключений без органического роста - красный флаг. Бот-атаки часто выглядят как резкий рост онлайна.

Chunk loading - скорость загрузки чанков. Если чанки грузятся медленно, это может быть и атака, и проблема с диском.

Базовые инструменты Linux

Начнём с того, что есть на любом Linux-сервере. Эти инструменты не требуют установки и дают быструю картину.

htop: CPU и память в реальном времени

htop -p $(pgrep -d, java)

Эта команда покажет только Java-процессы (ваш MC сервер). Смотрите на:

• %CPU на каждом ядре
• RES (реальное потребление RAM)
• VIRT vs RES (если VIRT сильно больше RES, это нормально для Java)

iftop: сетевой трафик

sudo iftop -i eth0 -n -P

Флаг -n отключает DNS-резолвинг (ускоряет работу), -P показывает порты. Вы увидите, кто шлёт трафик и сколько. Если один IP генерирует гигабиты, это атакующий.

nethogs: трафик по процессам

sudo nethogs eth0

Показывает, какой процесс потребляет трафик. Если java ест 500 Mbps, а обычно 20, что-то не так.

vnstat: история трафика

# Установка
sudo apt install vnstat

# Статистика за сегодня
vnstat -d

# В реальном времени
vnstat -l -i eth0

vnstat собирает статистику по трафику и хранит её. Это позволяет посмотреть паттерны: "а сколько трафика было вчера в это же время?"

Анализ соединений: netstat и ss

Это ваш главный инструмент для диагностики сетевых атак. ss быстрее чем netstat и предпочтительнее на современных системах.

Общая статистика соединений

ss -s

Вывод покажет что-то вроде:

TCP:   1247 (estab 89, closed 1102, orphaned 3, timewait 1098)

Если closed или timewait значительно больше estab, это признак SYN-флуда или connection flood.

Подсчёт соединений по состоянию

ss -tan | awk '{print $1}' | sort | uniq -c | sort -rn

Нормальная картина:

     89 ESTAB
     12 TIME-WAIT
      3 LISTEN
      1 SYN-SENT

Ненормальная картина (атака):

    847 SYN-RECV
     89 ESTAB
    203 TIME-WAIT
      3 LISTEN

847 соединений в состоянии SYN-RECV - это классический SYN-флуд.

Топ IP-адресов по количеству соединений

ss -tan | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -rn | head -20

Если один IP имеет 200+ соединений на ваш сервер, это либо прокси, либо атака. Нормальный игрок - 1-3 соединения.

Мониторинг порта Minecraft

# Количество соединений на порт 25565
ss -tan state established | grep :25565 | wc -l

# Новые соединения в секунду (запускать два раза с интервалом)
ss -tan state syn-recv | grep :25565 | wc -l

Prometheus + Grafana: серьёзный мониторинг

Базовые инструменты хороши для ручной диагностики. Но для постоянного мониторинга с историей и алертами нужен полноценный стек.

Установка Prometheus

# Скачиваем и распаковываем
wget https://github.com/prometheus/prometheus/releases/download/v2.51.0/prometheus-2.51.0.linux-amd64.tar.gz
tar xvf prometheus-2.51.0.linux-amd64.tar.gz
cd prometheus-2.51.0.linux-amd64

Конфигурация prometheus.yml:

global:
  scrape_interval: 15s

scrape_configs:
  - job_name: 'node'
    static_configs:
      - targets: ['localhost:9100']

  - job_name: 'minecraft'
    static_configs:
      - targets: ['localhost:9225']
    metrics_path: /metrics

Node Exporter для системных метрик

# Установка
wget https://github.com/prometheus/node_exporter/releases/download/v1.7.0/node_exporter-1.7.0.linux-amd64.tar.gz
tar xvf node_exporter-1.7.0.linux-amd64.tar.gz

# Запуск как сервис
sudo tee /etc/systemd/system/node_exporter.service << EOF
[Unit]
Description=Node Exporter
After=network.target

[Service]
User=prometheus
ExecStart=/opt/node_exporter/node_exporter
Restart=always

[Install]
WantedBy=multi-user.target
EOF

sudo systemctl enable --now node_exporter

Minecraft Exporter

Для Minecraft есть несколько опций. Самый популярный - плагин для Paper/Spigot, который отдаёт метрики в формате Prometheus.

Установите плагин UnifiedMetrics или PrometheusExporter на ваш MC сервер. После этого метрики будут доступны на порту (обычно 9225).

Типичные метрики, которые вы получите:

mc_tps 19.8
mc_players_online 47
mc_loaded_chunks 12847
mc_entities_total 8923
mc_memory_used_bytes 4294967296
mc_memory_max_bytes 8589934592

Установка Grafana

sudo apt install -y software-properties-common
wget -q -O - https://packages.grafana.com/gpg.key | sudo apt-key add -
echo "deb https://packages.grafana.com/oss/deb stable main" | sudo tee /etc/apt/sources.list.d/grafana.list
sudo apt update && sudo apt install grafana
sudo systemctl enable --now grafana-server

Откройте Grafana на порту 3000, добавьте Prometheus как источник данных.

Полезные Grafana-запросы для MC

TPS за последний час:

mc_tps

Количество игроков:

mc_players_online

Новые TCP-соединения в секунду (из node_exporter):

rate(node_netstat_Tcp_PassiveOpens[1m])

Потребление bandwidth:

rate(node_network_receive_bytes_total{device="eth0"}[1m]) * 8

CPU usage по ядрам:

100 - (avg by(cpu) (rate(node_cpu_seconds_total{mode="idle"}[1m])) * 100)

Количество SYN_RECV соединений:

node_netstat_Tcp_CurrEstab

Spark: профилирование Minecraft

Spark это профайлер, созданный специально для Minecraft. Он показывает, что именно тормозит ваш сервер.

Установка

Скачайте jar-файл с spark.lucko.me и положите в папку plugins вашего сервера. Перезапустите сервер.

Основные команды

/spark tps          - текущий TPS
/spark health       - общая информация о здоровье сервера
/spark profiler     - запуск профилирования
/spark profiler --stop  - остановка и генерация отчёта
/spark gc           - информация о сборке мусора

Мониторинг TPS через Spark

/spark tps

Выведет что-то вроде:

TPS from last 5s, 10s, 1m, 5m, 15m:
 20.0, 20.0, 19.8, 19.9, 19.7

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

Spark и мониторинг памяти

/spark heapdump

Генерирует дамп кучи Java. Это тяжёлая операция, не делайте это во время атаки. Используйте для post-mortem анализа: "почему сервер упал".

Анализ логов сервера

Логи Minecraft содержат массу полезной информации, но её нужно уметь читать.

Паттерны, указывающие на атаку

# "Can't keep up!" сообщения
grep "Can't keep up" logs/latest.log | tail -20

# Количество предупреждений за последний час
grep "$(date +%H):" logs/latest.log | grep -c "WARN"

# Подключения за последние 5 минут
grep "logged in with entity" logs/latest.log | tail -50

Обнаружение ботов в логах

Бот-атаки оставляют характерный след в логах:

# Быстрые подключения/отключения
grep -E "(logged in|lost connection)" logs/latest.log | tail -40

# Если видите паттерн:
# [14:20:01] Player1 logged in
# [14:20:01] Player1 lost connection
# [14:20:01] Player2 logged in
# [14:20:01] Player2 lost connection
# ... и так сотни раз в секунду - это бот-атака

Автоматический парсинг логов

#!/bin/bash
# monitor-logs.sh - простой мониторинг логов MC

LOG_FILE="/home/mc/server/logs/latest.log"
THRESHOLD=50  # подключений за 60 секунд

while true; do
    COUNT=$(grep -c "logged in" <(tail -n 200 "$LOG_FILE"))
    WARNS=$(grep -c "Can't keep up" <(tail -n 200 "$LOG_FILE"))

    if [ "$COUNT" -gt "$THRESHOLD" ]; then
        echo "[ALERT] $(date): $COUNT logins detected!"
        # Отправить алерт (см. секцию про Discord)
    fi

    if [ "$WARNS" -gt 5 ]; then
        echo "[ALERT] $(date): $WARNS 'Can't keep up' warnings!"
    fi

    sleep 10
done

Алерты: Discord, Telegram, Email

Мониторинг бесполезен, если вы не узнаёте о проблемах. Настройте оповещения.

Discord Webhook

Самый простой способ получать алерты для MC-сообщества.

#!/bin/bash
# alert-discord.sh

WEBHOOK_URL="https://discord.com/api/webhooks/YOUR_WEBHOOK_ID/YOUR_WEBHOOK_TOKEN"

send_alert() {
    local message="$1"
    local color="${2:-16711680}"  # red by default

    curl -s -H "Content-Type: application/json" \
        -X POST "$WEBHOOK_URL" \
        -d "{
            \"embeds\": [{
                \"title\": \"Server Alert\",
                \"description\": \"$message\",
                \"color\": $color,
                \"timestamp\": \"$(date -u +%Y-%m-%dT%H:%M:%SZ)\"
            }]
        }"
}

# Использование:
send_alert "High connection rate detected: 482 conn/s" 16711680
send_alert "TPS recovered to 19.8" 65280  # green

Grafana Alerts

В Grafana можно настроить алерты прямо на дашборде. Создайте Alert Rule:

# В Grafana UI: Alerting -> Alert Rules -> New
# Condition:
#   WHEN avg() OF query(A) IS ABOVE 100
# Query A:
#   rate(node_netstat_Tcp_PassiveOpens[1m])
# For: 30s
# Notification channel: Discord webhook

Это отправит алерт в Discord, когда количество новых TCP-соединений превысит 100 в секунду на протяжении 30 секунд.

Простой скрипт мониторинга с алертами

#!/bin/bash
# full-monitor.sh - комплексный мониторинг

DISCORD_WEBHOOK="https://discord.com/api/webhooks/..."
MC_PORT=25565
CONN_THRESHOLD=100
TPS_THRESHOLD=15
CPU_THRESHOLD=90

send_discord() {
    curl -s -H "Content-Type: application/json" \
        -X POST "$DISCORD_WEBHOOK" \
        -d "{\"embeds\":[{\"title\":\"$1\",\"description\":\"$2\",\"color\":$3,\"timestamp\":\"$(date -u +%Y-%m-%dT%H:%M:%SZ)\"}]}"
}

check_connections() {
    local conns=$(ss -tan state syn-recv | grep -c ":$MC_PORT")
    if [ "$conns" -gt "$CONN_THRESHOLD" ]; then
        send_discord "Connection Alert" "SYN_RECV count: $conns (threshold: $CONN_THRESHOLD)" 16711680
        return 1
    fi
    return 0
}

check_cpu() {
    local cpu=$(top -bn1 | grep "Cpu(s)" | awk '{print int($2)}')
    if [ "$cpu" -gt "$CPU_THRESHOLD" ]; then
        send_discord "CPU Alert" "CPU usage: ${cpu}% (threshold: ${CPU_THRESHOLD}%)" 16744448
    fi
}

check_bandwidth() {
    local rx1=$(cat /sys/class/net/eth0/statistics/rx_bytes)
    sleep 1
    local rx2=$(cat /sys/class/net/eth0/statistics/rx_bytes)
    local mbps=$(( (rx2 - rx1) * 8 / 1000000 ))

    if [ "$mbps" -gt 500 ]; then
        send_discord "Bandwidth Alert" "Incoming traffic: ${mbps} Mbps" 16711680
    fi
}

while true; do
    check_connections
    check_cpu
    check_bandwidth
    sleep 5
done

Как отличить атаку от легитимного всплеска

Это важный навык. Не каждый скачок трафика - это атака. Вот ключевые отличия.

Признаки атаки

• Резкий скачок соединений (из 10 в 500 за секунды)
• Много SYN_RECV без перехода в ESTABLISHED
• Трафик идёт с множества IP или с одного IP огромным потоком
• TPS падает, хотя количество реальных игроков не выросло
• "Can't keep up!" сообщения в логах
• Подключения и мгновенные отключения (бот-атака)

Признаки легитимного всплеска

• Постепенный рост соединений (минуты, не секунды)
• Все соединения переходят в ESTABLISHED
• TPS падает пропорционально количеству игроков
• Нет аномального трафика по bandwidth
• Игроки реально играют (чат активен, команды выполняются)
• Совпадает с событием (видео на YouTube, раздача, ивент)

Автоматическое определение

#!/bin/bash
# detect-anomaly.sh

MC_PORT=25565

# Соотношение SYN_RECV к ESTABLISHED
syn_recv=$(ss -tan state syn-recv | grep -c ":$MC_PORT")
established=$(ss -tan state established | grep -c ":$MC_PORT")

if [ "$established" -eq 0 ]; then
    ratio=999
else
    ratio=$((syn_recv / established))
fi

if [ "$ratio" -gt 5 ]; then
    echo "ATTACK: SYN_RECV/ESTABLISHED ratio is $ratio (${syn_recv}/${established})"
    echo "  -> This looks like a SYN flood"
elif [ "$syn_recv" -gt 200 ]; then
    echo "SUSPICIOUS: $syn_recv SYN_RECV connections"
    echo "  -> Monitor closely"
else
    echo "NORMAL: $syn_recv SYN_RECV, $established ESTABLISHED"
fi

Автоматическая реакция на атаки

Мониторинг без реакции бесполезен. Вот как автоматизировать ответ.

Базовый скрипт блокировки

#!/bin/bash
# auto-block.sh - автоматическая блокировка атакующих IP

MC_PORT=25565
CONN_LIMIT=50  # максимум соединений с одного IP
BLOCK_TIME=3600  # блокировка на 1 час

# Найти IP с превышением лимита
ss -tan state established dst :$MC_PORT | \
    awk '{print $5}' | cut -d: -f1 | \
    sort | uniq -c | sort -rn | \
    while read count ip; do
        if [ "$count" -gt "$CONN_LIMIT" ] && [ "$ip" != "" ]; then
            echo "Blocking $ip ($count connections)"
            iptables -A INPUT -s "$ip" -j DROP

            # Автоматическое снятие блокировки через час
            (sleep $BLOCK_TIME && iptables -D INPUT -s "$ip" -j DROP) &
        fi
    done

Интеграция с systemd

Создайте сервис для автоматического мониторинга:

sudo tee /etc/systemd/system/mc-monitor.service << EOF
[Unit]
Description=Minecraft Server Monitor
After=network.target

[Service]
Type=simple
User=root
ExecStart=/opt/mc-monitor/full-monitor.sh
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target
EOF

sudo systemctl enable --now mc-monitor

Rate limiting через iptables

Превентивная мера, которая работает без мониторинга:

# Ограничение новых соединений на порт MC
iptables -A INPUT -p tcp --dport 25565 \
    --syn -m connlimit --connlimit-above 3 \
    --connlimit-mask 32 -j DROP

# Ограничение rate новых соединений
iptables -A INPUT -p tcp --dport 25565 \
    --syn -m limit --limit 25/s --limit-burst 50 -j ACCEPT
iptables -A INPUT -p tcp --dport 25565 --syn -j DROP

Интеграция с DDoS-защитой

Если ваш сервер под защитой MineGuard, мониторинг работает на двух уровнях: на стороне защиты и на вашем сервере.

Дашборд MineGuard показывает сетевые метрики в реальном времени: входящий трафик, количество соединений, заблокированные пакеты. Но мониторинг на вашей стороне по-прежнему важен. Защита фильтрует сетевые атаки, но не видит, что происходит внутри вашего MC сервера: TPS, загрузку чанков, состояние плагинов.

Идеальная схема: DDoS-защита фильтрует трафик на входе, ваш мониторинг следит за здоровьем приложения.

Итого: минимальный набор для старта

Не обязательно сразу настраивать Prometheus + Grafana. Начните с малого:

1. Сегодня: выучите ss -s и iftop. Запускайте при подозрении на проблемы
2. На этой неделе: установите vnstat для истории трафика и Spark для мониторинга TPS
3. В этом месяце: настройте скрипт с Discord-алертами для автоматических уведомлений
4. Когда будете готовы: разверните Prometheus + Grafana для полноценного мониторинга с историей

Если вы хотите узнать, что делать, когда атака уже началась, читайте нашу отдельную статью. А мониторинг поможет вам заметить её до того, как игроки начнут жаловаться.