Внешний мониторинг игровых серверов: настройка трекера статуса для Minecraft, CS и Rust | AdminWiki
Logo

Внешний мониторинг игровых серверов: настройка трекера статуса для Minecraft, CS и Rust

30 июля 2026 8 мин. чтения
Содержание статьи

Зачем нужен внешний мониторинг игрового сервера

Внутренний агент мониторинга, установленный на сервере, перестаёт отвечать одновременно с падением операционной системы или зависанием процесса. Внешний трекер имитирует подключение реального игрока и фиксирует проблему даже при полной недоступности сервера изнутри. Это критично для игровых проектов: по статистике, пять минут простоя снижают онлайн на 20%, а десять минут - заставляют игроков искать альтернативные серверы и не возвращаться.

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

Для администраторов, управляющих несколькими проектами одновременно, внешний мониторинг через единую панель (Grafana или Zabbix) даёт сводную картину по всей инфраструктуре. Вы видите пиковые нагрузки, динамику онлайна и можете коррелировать падения с обновлениями плагинов или DDoS-атаками. В этой статье разберём протоколы опроса для Minecraft, CS и Rust, напишем скрипт сбора метрик и настроим оповещения.

Протоколы мониторинга: Source Query, UDP и API для каждой игры

Каждый игровой движок предоставляет специфичный интерфейс для внешнего опроса. Выбор протокола определяет, какие данные вы получите и насколько сложной будет реализация трекера. Сравним три основных подхода.

ПротоколИгрыТранспортДанныеСложность
Source Query (A2S_INFO)CS 1.6, CS:GO, CS2, RustUDPНазвание, карта, игроки, версияНизкая
Server List PingMinecraft (Java Edition)TCPОписание, онлайн, версия протоколаНизкая
Minecraft QueryMinecraft (Java Edition)UDPСписок игроков, плагины, полные слотыСредняя
RCONВсе перечисленныеTCPВыполнение команд, детальная статистикаСредняя

Source Query для серверов CS и Rust

Протокол Source Query работает поверх UDP и используется всеми играми на движке Source, включая Rust. Базовый запрос A2S_INFO состоит из пяти байт: 0xFF 0xFF 0xFF 0xFF 0x54 и строки Source Engine Query. Сервер возвращает структуру с названием, картой, количеством игроков, максимальным количеством слотов и версией.

Для получения списка игроков отправляется запрос A2S_PLAYER с префиксом 0xFF 0xFF 0xFF 0xFF 0x55 и challenge-числом, полученным в ответе на первый запрос. Библиотека python-valve инкапсулирует эту логику и позволяет получить данные в три строки кода.

import valve.source.a2s

SERVER_ADDRESS = ("176.62.66.47", 28015)
server = valve.source.a2s.ServerQuerier(SERVER_ADDRESS)
info = server.info()
print(f"Сервер: {info['server_name']}, игроков: {info['player_count']}/{info['max_players']}")

Адрес 176.62.66.47:28015 - пример реального Rust-сервера. На нём включена защита VAC, карта Procedural Map, версия 2631, максимальный онлайн - 500 игроков. При опросе раз в минуту вы получаете актуальный срез состояния без нагрузки на игровой процесс.

Мониторинг Minecraft через Server List Ping и Query

Server List Ping - базовый механизм, который использует клиент Minecraft для отображения сервера в списке. Подключение идёт по TCP на порт 25565. Клиент отправляет handshake-пакет с адресом сервера и портом, затем запрос статуса. Ответ приходит в формате JSON и содержит описание, версию протокола, текущий и максимальный онлайн, а также sample-список игроков (ограниченный 10-12 записями).

Библиотека mcstatus для Python реализует оба протокола. Пример опроса:

from mcstatus import JavaServer

server = JavaServer.lookup("mc.example.com:25565")
status = server.status()
print(f"Версия: {status.version.name}, игроков: {status.players.online}/{status.players.max}")

Minecraft Query требует явного включения в server.properties параметром enable-query=true и указанием порта query.port=25565. Протокол работает по UDP и возвращает полный список игроков (без ограничения sample), список установленных плагинов и карту. Для серверов с модами и плагинами Query - единственный способ получить детальную информацию без RCON.

Детальнее тема мониторинга Minecraft раскрыта в статье «Мониторинг серверов Minecraft в 2026: инструменты, плагины и интеграции», где разобраны плагины Spark и Timings для диагностики лагов и утечек памяти.

Практическая настройка трекера: пишем скрипт сбора метрик

Скрипт должен опрашивать список серверов, собирать метрики и экспортировать их в систему мониторинга. Ниже - решение на Python с поддержкой Source Query и Minecraft Server List Ping. Скрипт обрабатывает таймауты, невалидные ответы и логирует ошибки без прерывания цикла опроса.

import time
import valve.source.a2s
from mcstatus import JavaServer

SERVERS = [
    {"name": "rust_main", "type": "source", "addr": ("176.62.66.47", 28015)},
    {"name": "cs2_public", "type": "source", "addr": ("192.168.1.10", 27015)},
    {"name": "mc_survival", "type": "minecraft", "addr": "mc.example.com:25565"},
]

def poll_source(addr):
    server = valve.source.a2s.ServerQuerier(addr, timeout=3.0)
    info = server.info()
    return {"online": 1, "players": info["player_count"], "max_players": info["max_players"]}

def poll_minecraft(addr):
    server = JavaServer.lookup(addr, timeout=3.0)
    status = server.status()
    return {"online": 1, "players": status.players.online, "max_players": status.players.max}

def collect_metrics():
    results = []
    for srv in SERVERS:
        try:
            if srv["type"] == "source":
                data = poll_source(srv["addr"])
            elif srv["type"] == "minecraft":
                data = poll_minecraft(srv["addr"])
            else:
                continue
            results.append((srv["name"], data))
        except Exception as e:
            results.append((srv["name"], {"online": 0, "players": 0, "max_players": 0}))
            print(f"[ERROR] {srv['name']}: {e}")
    return results

if __name__ == "__main__":
    while True:
        metrics = collect_metrics()
        for name, data in metrics:
            print(f"{name}: online={data['online']}, players={data['players']}/{data['max_players']}")
        time.sleep(60)

Этот код - основа трекера. Далее адаптируем его под экспорт в Prometheus и Zabbix.

Экспорт метрик в Prometheus

Prometheus ожидает метрики в текстовом формате по HTTP. Создадим экспортер на Flask, который при GET-запросе к /metrics возвращает актуальные значения.

from flask import Flask, Response

app = Flask(__name__)

@app.route("/metrics")
def metrics():
    data = collect_metrics()
    lines = []
    for name, d in data:
        lines.append(f"game_server_online{{server=\"{name}\"}} {d['online']}")
        lines.append(f"game_server_players{{server=\"{name}\"}} {d['players']}")
        lines.append(f"game_server_max_players{{server=\"{name}\"}} {d['max_players']}")
    return Response("\n".join(lines) + "\n", mimetype="text/plain")

if __name__ == "__main__":
    app.run(host="0.0.0.0", port=9100)

В конфигурации prometheus.yml добавляем цель:

scrape_configs:
  - job_name: 'game_servers'
    scrape_interval: 60s
    static_configs:
      - targets: ['localhost:9100']

Метрики game_server_online, game_server_players и game_server_max_players появятся в Prometheus и станут доступны для построения графиков в Grafana и настройки алертов.

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

Для Zabbix используем механизм trapper-элементов. Шаблон создаётся с элементами данных типа «Zabbix trapper», ключи: game.server.online[rust_main], game.server.players[rust_main] и аналогично для остальных серверов. Скрипт отправляет значения через утилиту zabbix_sender.

import subprocess

def send_to_zabbix(metrics):
    args = ["zabbix_sender", "-z", "127.0.0.1", "-s", "game-tracker"]
    for name, d in metrics:
        args.extend(["-k", f"game.server.online[{name}]", "-o", str(d["online"])])
        args.extend(["-k", f"game.server.players[{name}]", "-o", str(d["players"])])
    subprocess.run(args, capture_output=True)

Интервал опроса в Zabbix настраивается на стороне сервера и не зависит от частоты отправки данных скриптом. Рекомендуем вызывать скрипт по cron каждую минуту.

Если вы администрируете RP-проекты на SAMP или MTA, аналогичный подход с API-опросами описан в руководстве «Мониторинг игровых серверов SAMP, MTA и GTA RP», включая готовый дашборд в Grafana и Telegram-алерты.

Настройка оповещений о сбоях и изменениях статуса

Алертинг превращает мониторинг из пассивного наблюдения в активный инструмент реагирования. Критические события: сервер перестал отвечать на query-запросы, онлайн упал до нуля в нехарактерное время, количество игроков снизилось более чем на 50% за пять минут.

Алертинг в Prometheus: правила и Alertmanager

Файл alert.rules.yml описывает условия срабатывания. Пример правила для детектирования падения сервера:

groups:
  - name: game_servers
    rules:
      - alert: GameServerDown
        expr: game_server_online == 0
        for: 2m
        labels:
          severity: critical
        annotations:
          summary: "Сервер {{ $labels.server }} не отвечает"
          description: "Сервер {{ $labels.server }} недоступен более 2 минут."
      - alert: GameServerZeroPlayers
        expr: game_server_players == 0 and game_server_online == 1
        for: 10m
        labels:
          severity: warning
        annotations:
          summary: "На сервере {{ $labels.server }} нет игроков"

Alertmanager маршрутизирует уведомления по каналам. Конфигурация для Telegram и Slack:

route:
  receiver: 'telegram-critical'
  routes:
    - match:
        severity: warning
      receiver: 'slack-warnings'
receivers:
  - name: 'telegram-critical'
    telegram_configs:
      - bot_token: 'YOUR_BOT_TOKEN'
        chat_id: -123456789
  - name: 'slack-warnings'
    slack_configs:
      - api_url: 'https://hooks.slack.com/services/...'
        channel: '#alerts'

Триггеры в Zabbix для мониторинга онлайна

В Zabbix создаются триггеры на элементах данных trapper-типа. Триггер отсутствия данных: функция nodata(120)=1 сработает, если скрипт не отправил метрику за две минуты. Триггер нулевого онлайна: выражение last(/game-tracker/game.server.players[rust_main])=0 с уровнем важности «Предупреждение». Действие назначается на группу триггеров и отправляет сообщение через Telegram Webhook или email.

Для комплексного подхода к наблюдаемости высоконагруженных систем, включая Kubernetes-кластеры с игровыми серверами, обратитесь к материалу «Наблюдаемость для высоконагруженных систем в 2026» - там разобраны SRE-практики, дашборды Grafana и интеграция с GitLab по GitOps.

Обеспечение безопасности мониторинга

Открытие портов Query и RCON наружу создаёт вектор атаки. Злоумышленник может получить список игроков, информацию о сервере, а при компрометации RCON-пароля - полный контроль над игровым процессом. На сервере Rust включена защита VAC, но античит не защищает от эксплуатации административных протоколов.

Правила безопасности:

  • Ограничьте доступ к портам RCON и Query файрволом по белому списку IP-адресов вашего трекера. Используйте iptables или ufw: ufw allow from 10.0.0.5 to any port 28016 proto tcp.
  • Установите сложный RCON-пароль длиной не менее 20 символов, сгенерированный случайным образом. Храните его в vault-решении (HashiCorp Vault, Ansible Vault), а не в открытом конфигурационном файле.
  • Вынесите трекер в изолированную подсеть или подключите его к игровым серверам через VPN (WireGuard, OpenVPN). Это исключает перехват query-трафика и снижает поверхность атаки.
  • Не используйте стандартные порты для RCON. Измените rcon.port в конфигурации сервера на нестандартное значение.
  • Логируйте все RCON-подключения и настройте алерт на попытки аутентификации с неверным паролем.

Мониторинг сетевой маршрутизации - ещё один уровень защиты, позволяющий выявить аномалии на уровне BGP-маршрутов и вовремя обнаружить DDoS-атаку. Практические методы сбора метрик по задержкам и потерям пакетов с помощью Prometheus описаны в статье «Мониторинг BGP и Looking Glass».

Заключение: автоматизация как конкурентное преимущество

Внешний трекер статуса, интегрированный с Prometheus или Zabbix, сокращает время обнаружения сбоя с часов (по жалобам игроков) до двух минут. Вы получаете объективные данные о доступности серверов и динамике онлайна, на основе которых принимаете решения о масштабировании инфраструктуры и оптимизации производительности.

Скрипт из этого руководства подключается к любому количеству серверов Minecraft, CS и Rust, собирает метрики и экспортирует их в единую панель. Алертинг через Telegram или Slack избавляет от необходимости постоянно проверять состояние серверов вручную. Интеграция с панелями управления (Pterodactyl, TCAdmin, Crafty) выполняется аналогично - через API-запросы к их эндпоинтам.

Для дальнейшего углубления в тему рекомендуем изучить материал «Мониторинг загрузки файлов на сервер», где разобраны инструменты диагностики узких мест дисковой подсистемы и сети, критичных для производительности игровых миров с большим количеством чанков.

Поделиться:
Сохранить гайд? В закладки браузера