Экспорт статистики игроков с сервера

MAATRIX GAMES

Рано или поздно у любого админа возникает вопрос: а кто вообще играет на моём сервере и когда? Не "сколько онлайна прямо сейчас" — это покажет любой мониторинг — а история: в какие часы реально жарко, кто заходит каждый день, а кто зашёл один раз и пропал. Без этих данных решения о рестартах, вайпах и апгрейде тарифа принимаются на глазок, с ними — по фактам. Разберём, откуда брать статистику подключений, как собирать без гемора и куда складывать, чтобы потом можно было что-то с ней сделать.

Зачем вообще выгружать статистику

Три практические причины, ради которых стоит потратить час на настройку.

Первая — планирование технических работ. Если рестарт или обновление модов роняет сервер на 10 минут в момент, когда там 40 человек, вы теряете лояльность игроков и получаете волну жалоб в Discord. Зная реальные пиковые часы (а не предполагаемые), можно ставить maintenance-окно туда, где сервер и так почти пустой — часто это раннее утро по времени основной аудитории, но не всегда: у серверов с международным коннектом бывает два пика в сутки.

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

Третья — аргументы для решений о развитии сервера. Стоит ли увеличивать тариф под растущий онлайн, открывать второй сервер под другой режим, оправдал ли себя последний ивент приростом активности — графики по дням и неделям отвечают на эти вопросы честнее, чем ощущение "вроде народу прибавилось".

Источники данных: что у вас уже есть

Прежде чем писать что-то своё, посмотрите, что сервер и так пишет.

Логи сервера. Практически любой игровой сервер логирует подключения и отключения игроков — это первый источник, и часто единственный, который нужен для базовой статистики. У Minecraft (Paper, Spigot, Vanilla) это logs/latest.txt и архивные logs/2026-08-29-1.log.gz, где строки вида:

[14:32:07] [Server thread/INFO]: Steve[/192.168.1.10:54321] logged in with entity id 234
[15:10:44] [Server thread/INFO]: Steve left the game

дают вам ник, время входа и время выхода. У серверов на движке Source (CS2) и подобных — свои логи событий подключения в logs/ или через SourceMod, если он установлен. У Rust — server.log в папке сервера, где есть строки [connected] и [disconnected] с SteamID. Общий принцип один: где-то в текстовом логе есть временная метка plus идентификатор игрока plus событие подключения/отключения — этого достаточно для начальной статистики.

Если раньше не занимались разбором логов сервера, для контекста будет полезна статья про логи и краш-репорты — форматы логов там разобраны подробно.

Плагины статистики, если экосистема игры их даёт. Не изобретайте велосипед, если готовое решение уже существует.

• Для Minecraft на Paper/Spigot есть плагины плейтайм-статистики вроде Statz или PlaceholderAPI с модулями плейтайма — они считают время на сервере, смерти, убийства и умеют экспортировать данные в CSV или отдавать через команды.
• Для серверов на Oxide/uMod (основа для Rust и ряда других игр) есть плагины учёта сессий, пишущие статистику в JSON или встроенную базу фреймворка.
• Для FiveM-серверов (ESX, QBCore) статистика игроков обычно уже часть фреймворка — данные о последнем входе и активности лежат в MySQL-таблицах, их нужно только выгрузить SQL-запросом.

Прежде чем писать свой парсер, проверьте, нет ли готового решения под вашу игру — экономит часы.

Собственный скрипт, парсящий подключения/отключения. Когда готового плагина нет или он не даёт нужный разрез данных — пишете свой парсер логов. Задача несложная: построчно читать лог, находить события входа/выхода по регулярке, писать их в структурированный формат. Пример на Python для формата логов Paper/Spigot:

import re
import csv
from datetime import datetime

LOGIN_RE = re.compile(r'\[(\d{2}:\d{2}:\d{2})\].*?(\w+)\[/[\d.:]+\] logged in')
LOGOUT_RE = re.compile(r'\[(\d{2}:\d{2}:\d{2})\].*?(\w+) left the game')

def parse_log(path, log_date):
    events = []
    with open(path, encoding='utf-8') as f:
        for line in f:
            if m := LOGIN_RE.search(line):
                ts = datetime.strptime(f"{log_date} {m.group(1)}", "%Y-%m-%d %H:%M:%S")
                events.append((ts, m.group(2), 'login'))
            elif m := LOGOUT_RE.search(line):
                ts = datetime.strptime(f"{log_date} {m.group(1)}", "%Y-%m-%d %H:%M:%S")
                events.append((ts, m.group(2), 'logout'))
    return events

with open('player_events.csv', 'a', newline='', encoding='utf-8') as out:
    writer = csv.writer(out)
    for ts, nick, event in parse_log('logs/latest.log', '2026-08-29'):
        writer.writerow([ts.isoformat(), nick, event])

Это простой каркас, не готовое решение под копипаст — формат логов может отличаться, регулярки придётся подогнать под конкретную сборку. Дальше скрипт запускается по крону (логика cron-задач разобрана в статье про автоматический рестарт по расписанию) раз в день, разбирая логи за прошедшие сутки.

Ещё один рабочий вариант — не парсить логи, а подключаться через RCON и периодически (раз в минуту через cron) опрашивать список онлайна командой вроде list (Minecraft) или её аналогом, складывая снепшоты в файл. Грубее по точности (не время входа/выхода, а "кто был онлайн в момент опроса"), зато проще и не зависит от формата логов сборки. Подробности — в статье про RCON и основные команды.

Что считать статистикой, а что — уже лишнее

Полезный минимальный набор полей, который покрывает 90% практических задач:

Всё, что сверх этого — история чатов, координаты передвижения, детальный лог действий каждого игрока — уже не про "понять пиковые часы и активность", а про слежку. Даже если технически легко это собирать, не стоит: об этом ниже отдельно.

Куда складывать собранные данные

На старте не нужна сложная инфраструктура — важно, чтобы данные были в структурированном виде и их можно было потом обработать.

CSV-файл — самый простой и рабочий вариант для одного-двух серверов с умеренным онлайном. Один файл player_sessions.csv с колонками timestamp,nick,event или сразу агрегированный nick,login,logout,duration_minutes — этого достаточно, чтобы открыть файл в Excel/Google Sheets или прогнать через pandas и получить графики по часам и дням недели. Минус — при большом объёме данных CSV становится неудобным для запросов "покажи топ-20 игроков за последний месяц".

База данных, если данных много или нужны более гибкие запросы. Не обязательно поднимать что-то тяжёлое — для одного сервера подойдёт даже SQLite: файл на диске, никакого отдельного процесса БД, а SQL-запросы уже дают нормальную аналитику:

SELECT nick, COUNT(*) as sessions, SUM(duration_minutes) as total_minutes
FROM player_sessions
WHERE login_date >= date('now', '-30 days')
GROUP BY nick
ORDER BY total_minutes DESC
LIMIT 20;

Если на сервере уже крутятся плагины, которые сами пишут данные в MySQL (частая история для экономики, приватов, статистики — многие популярные плагины используют MySQL вместо встроенного SQLite ради надёжности при высокой нагрузке), логичнее не городить отдельное хранилище, а завести ещё одну таблицу в той же базе и писать статистику подключений туда же.

Для визуализации после того как данные легли в БД или CSV — простейший вариант: pandas + matplotlib в Jupyter-блокноте на своей машине, раз в неделю смотреть графики. Дашборд на самом сервере ради этого городить не нужно, по крайней мере на старте.

Разбивка по часам: как выглядит анализ на практике

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

import pandas as pd

df = pd.read_csv('player_sessions.csv', parse_dates=['login', 'logout'])
df['hour'] = df['login'].dt.hour
hourly = df.groupby('hour').size()
print(hourly.sort_values(ascending=False).head(5))

Результат — пять самых нагруженных часов за период. Именно на эти данные, а не на интуицию, стоит опираться при выборе окна для рестартов, вайпов карты или загрузки бекапов (если бекап заметно грузит диск, лучше ставить его не в пиковый час — детали в статье про настройку расписания автобекапов).

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

Приватность: где проходит грань

Здесь стоит сказать честно, без реверансов. Собирать статистику подключений — нормально и полезно. Превращать сервер в систему слежки за каждым шагом игрока — не нормально, даже если технически легко.

Практические принципы:

• Собирайте минимум, необходимый для задачи. Если цель — понять пиковые часы, вам не нужны координаты передвижения игроков или содержимое приватного чата. Ник, время входа, время выхода — обычно достаточно.
• IP-адреса — по необходимости, а не по умолчанию. Если IP реально нужен (например, для античита или банов по подсети), храните его отдельно от публичной статистики активности.
• Не публикуйте личную статистику без контекста. Топ по онлайну на сайте — нормально. Детальный лог "кто когда заходил по минутам" в открытом доступе — уже похоже на слежку, даже без такого намерения.
• Ограничьте доступ к сырым данным. Файл с историей подключений — это персональные данные в широком смысле. Он должен лежать там, куда есть доступ у админов, а не в публичной папке.
• Скажите игрокам, что вы собираете. Пара строк в правилах сервера или Discord ("логируем время онлайна для статистики и банов") снимает большинство вопросов и работает на доверие.

Ориентируйтесь на здравый смысл: собирайте то, что реально используете, и не собирайте то, что просто "может пригодиться".

Автоматизация: чтобы не собирать вручную каждый раз

Ручной прогон скрипта раз в неделю работает, но быстро надоедает. Разумный минимум автоматизации:

1. Cron-задача, которая раз в сутки (например, в 4 утра, в самый тихий час) парсит логи за прошедший день и дописывает строки в CSV или БД.
2. Отдельный скрипт раз в неделю строит агрегаты (топ по часам, топ по игрокам) и, если на сервере уже есть бот в Discord, отправляет краткую сводку в admin-канал — тогда статистику не нужно даже открывать руками. Как поднять такого бота — в статье про Discord-бота для управления сервером.
3. Ротация старых логов (logrotate или встроенный механизм игры) не должна ломать парсер — если лог архивируется в .gz, парсер должен уметь читать и такие файлы, иначе история обрывается незаметно.

Отдельно стоит завести uptime-мониторинг сервера, если ещё не настроен — он не только шлёт алерты о падении, но и даёт грубые данные об онлайне на случай, если основной парсер логов даст сбой. Обзор инструментов — в статье про uptime-мониторинг игрового сервера.

Частые вопросы