Uptime-мониторинг игрового сервера: инструменты

MAATRIX GAMES

Сервер упал в три часа ночи. Никто из админов не смотрел в этот момент в панель хостинга, а игроки, которые пытались зайти в два часа дня следующего дня, просто закрыли клиент и написали в чате «сервер не работает, удаляю». Вы узнали о падении только вечером, когда кто-то наконец написал вам напрямую — и половина этого времени сервер просто стоял мёртвым грузом, пока о нём никто не думал. Это чинится не героическим «проверять почаще руками», а обычным uptime-мониторингом, который сам заметит падение и сам вас разбудит.

Uptime-мониторинг — не то же самое, что мониторинг TPS

Тут стоит сразу развести два разных вопроса, которые легко перепутать. Мониторинг TPS и лагов отвечает на вопрос «сервер работает, но насколько хорошо» — тикрейт, нагрузка на CPU, просадки FPS у сервера. Это тема отдельной статьи про мониторинг TPS и лагов, и если вас интересует именно производительность живого сервера — вам туда.

Uptime-мониторинг — это грубее и проще: сервер вообще жив или нет. Отвечает на процесс игры или нет, принимает ли порт подключения, доступна ли панель управления. Это первый и самый базовый уровень контроля, без которого разговор про TPS вообще не имеет смысла — нет смысла разбирать лаги на сервере, который упал полчаса назад и не отвечает никому. Именно поэтому uptime-проверку стоит настроить в первую очередь, а тонкую диагностику производительности — уже после.

Как вообще проверяется, что сервер "жив"

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

Ping (ICMP). Самая грубая проверка — сервер отвечает на пинг или нет. Плюс — работает всегда и для чего угодно. Минус — многие хостинги и файрволы по умолчанию блокируют ICMP-ответы на внешние пинги, так что «нет ответа на пинг» далеко не всегда значит «сервер упал», это может значить «файрвол режет ICMP». Поэтому чистый ping как единственная проверка для игрового сервера — плохая идея, годится максимум как дополнительный сигнал.

TCP-порт. Проверка того, что порт сервера (игровой порт, RCON-порт, порт панели) вообще принимает соединение. Не говорит ничего про то, что происходит внутри — процесс может быть жив, порт открыт, а сам игровой мир давно завис в дедлоке и не обрабатывает ничего. Но это уже значительно надёжнее пинга и не требует ICMP.

A2S-протокол. Это протокол опроса серверов, который использует Source-движок Valve (CS2, TF2, Left 4 Dead 2 и другие Source-игры) — запрос A2S_INFO по UDP на игровой порт возвращает название сервера, карту, число игроков онлайн и версию. Это самая содержательная проверка из всех: если сервер ответил на A2S_INFO с разумными данными — он не просто «жив», он реально обслуживает игроков. У других движков — свои похожие протоколы опроса (например, у Minecraft это Server List Ping поверх TCP, у Rust — собственный вариант запроса статуса), устроены они иначе, чем A2S, но задачу решают ту же. Специализированные библиотеки вроде node-gamedig умеют абстрагировать эту разницу и опрашивать десятки движков по единому интерфейсу — на нём построены игровые мониторы в некоторых готовых сервисах, о которых ниже.

Для практики: чем точнее проверка (A2S/game-query вместо простого TCP или ping), тем меньше ложных тревог и тем раньше вы заметите ситуацию «порт открыт, но сервер уже не отвечает игрокам».

Готовые внешние сервисы: UptimeRobot и похожие

Самый простой путь — не настраивать ничего самому, а отдать проверку внешнему сервису. Логика одна и та же почти у всех: вы указываете адрес и порт, сервис с внешних узлов периодически стучится к вам и следит за статусом.

UptimeRobot — пример такого сервиса, один из самых известных в этой категории. Регистрируете монитор с типом TCP-порт (для игрового порта — самое практичное) или Ping, задаёте интервал проверки, привязываете контакты для уведомлений. Плюс внешнего сервиса в том, что он смотрит на ваш сервер снаружи, с независимого узла — если упадёт не только сервер, но и вся сеть хостинга целиком, вы всё равно узнаете об этом, потому что проверяющий узел не зависит от вашей инфраструктуры. Минус — бесплатные тарифы обычно ограничивают интервал проверки (типично в районе нескольких минут, а не секунд) и число мониторов, точные условия и лимиты стоит смотреть на сайте сервиса на момент настройки, потому что тарифы меняются.

Специализированных игровых uptime-сервисов, которые прямо из коробки понимают A2S и игровые протоколы конкретных движков, на рынке меньше, чем универсальных HTTP/TCP-мониторов — большинство общих сервисов вроде UptimeRobot ограничены проверкой открытости порта, а не содержимого ответа игрового сервера. Если вам принципиально важно видеть именно «сервер отвечает игрокам», а не просто «порт открыт» — следующий пункт для вас.

Self-hosted вариант: Uptime Kuma

Uptime Kuma — открытый инструмент мониторинга, который вы поднимаете на своей инфраструктуре (например, на небольшой VPS или прямо на хостинге рядом с игровым сервером, если ресурсов достаточно). В отличие от внешнего SaaS-сервиса, здесь вы полностью контролируете и данные, и логику проверок, но взамен сами отвечаете за то, чтобы Uptime Kuma не упал вместе с той же инфраструктурой, которую он мониторит — имеет смысл держать его на отдельной машине, а не на том же хосте, что игровой сервер.

Быстрый старт через Docker:

docker run -d --restart=always -p 3001:3001 \
  -v uptime-kuma:/app/data \
  --name uptime-kuma \
  louislam/uptime-kuma:1

После запуска веб-интерфейс доступен на порту 3001, там же при первом входе создаётся аккаунт администратора. Дальше через «Add New Monitor» заводите проверку под нужный тип — как минимум TCP Port для игрового порта сервера. У Uptime Kuma в списке типов мониторов помимо базовых HTTP/TCP/Ping со временем появлялись и специализированные варианты, включая опрос игровых серверов через gamedig-совместимый протокол — какие именно движки поддерживаются в вашей установленной версии, проще всего свериться прямо в выпадающем списке типов при создании монитора, потому что список пополняется от релиза к релизу.

Плюс self-hosted решения — гибкость и отсутствие лимитов тарифного плана. Минус — это ещё один сервис, который надо поддерживать, обновлять и, в идеале, держать на инфраструктуре, физически отделённой от того, что он проверяет.

Свой скрипт вместо готового сервиса

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

Минимальная проверка TCP-порта через nc (netcat):

#!/bin/bash
HOST="1.2.3.4"
PORT="27015"

if ! nc -z -w5 "$HOST" "$PORT"; then
  curl -s -X POST "https://api.telegram.org/bot<TOKEN>/sendMessage" \
    -d chat_id="<CHAT_ID>" \
    -d text="Сервер $HOST:$PORT не отвечает на порт!"
fi

Для более честной проверки «жив ли именно игровой процесс, а не просто открыт порт» на Python есть библиотека python-a2s для Source-совместимых серверов:

import a2s

address = ("1.2.3.4", 27015)
try:
    info = a2s.info(address, timeout=5)
    print(f"OK: {info.server_name}, игроков {info.player_count}/{info.max_players}")
except Exception as e:
    print(f"Сервер не отвечает: {e}")
    # здесь — отправка уведомления

Прописываете скрипт в cron с интервалом раз в 1-5 минут — про сам синтаксис cron и как не наступить на грабли с плановыми задачами есть отдельная статья про автоматический перезапуск сервера по расписанию через cron, логика с частотой запуска задачи там применима один в один. Минус подхода очевиден: если скрипт запущен на том же хосте, что и игровой сервер, а упадёт вся машина целиком — уведомление просто не уйдёт, потому что отправлять его будет некому. Для по-настоящему независимой проверки скрипт нужно держать на отдельном сервере или использовать внешний сервис из предыдущих пунктов.

Уведомления: email, Telegram, Discord

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

Email — самый универсальный вариант, поддерживается почти всеми сервисами мониторинга из коробки (в UptimeRobot и Uptime Kuma настраивается в пару кликов через SMTP или встроенную интеграцию). Минус — почту не всегда проверяют оперативно, особенно ночью.

Telegram — на практике самый быстрый способ получить пуш на телефон. Через @BotFather создаётся бот, получаете токен, узнаёте свой chat_id (например, написав боту @userinfobot), дальше уведомление — обычный POST-запрос к Telegram Bot API, как в примере скрипта выше. Если у вас уже есть Telegram-сообщество вокруг сервера — логика создания бота и работы с API разобрана в статье как поднять сервер Telegram, тот же принцип работы с ботом применим и для служебных уведомлений админу.

Discord-вебхук — если основное общение вокруг сервера идёт в Discord, уведомление логично слать туда же, в закрытый канал для админов. Создаётся в настройках канала (Integrations → Webhooks → New Webhook), дальше уведомление — POST-запрос с JSON на URL вебхука:

curl -H "Content-Type: application/json" \
  -d '{"content": "⚠️ Сервер не отвечает уже 5 минут"}' \
  https://discord.com/api/webhooks/XXXXX/YYYYY

Uptime Kuma и UptimeRobot поддерживают Discord-вебхуки как встроенный тип уведомления, без необходимости писать код вручную. Если у вас уже настроен бот для управления сервером из Discord — есть отдельная статья про Discord-бота для управления игровым сервером, туда же можно завести и уведомления о падении, чтобы не плодить лишние интеграции.

Практичный совет: не полагайтесь на один канал уведомлений. Email легко пропустить, а Telegram или Discord могут молчать, если у вас разрядился телефон или отключился интернет дома. Комбинация из двух каналов (например, Telegram + email) снижает шанс, что падение останется незамеченным часами.

Что делать после того, как пришло уведомление

Уведомление — это начало, а не конец истории. Полезно заранее прикинуть короткий чек-лист действий, чтобы не соображать спросонья, с чего начинать:

1. Проверить, действительно ли сервер упал, а не мониторинг ложно сработал. Зайдите в панель хостинга или подключитесь по SSH — если сервер отвечает, а мониторинг сказал «упал», возможно, дело в разовом сетевом сбое или слишком строгом таймауте проверки (см. следующий раздел).
2. Посмотреть логи на момент падения. Что именно произошло — краш процесса, нехватка памяти, зависание — обычно видно в последних строках лога перед остановкой. Как читать логи и крэш-репорты и что в них искать в первую очередь — подробно разобрано в статье про логи и крэш-репорты.
3. Перезапустить сервер. Через панель хостинга или systemd/init-скрипт на своей VPS. Если хочется, чтобы это происходило само при падении процесса — читайте про автозапуск сервера при перезагрузке хоста, там же логика применима и к автоматическому перезапуску упавшего процесса через systemd-юнит с Restart=on-failure.
4. Зафиксировать причину, если она повторяется. Разовое падение — досадная случайность, повторяющееся падение по одной и той же причине (утечка памяти, конкретный плагин, недостаток RAM под текущий онлайн) — сигнал, что нужно решение посерьёзнее одного перезапуска.

Как выбрать интервал проверки, чтобы не словить лишний шум

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

Разумный ориентир для игрового сервера — проверка раз в 1-5 минут с таймаутом ответа в несколько секунд и, желательно, требованием нескольких подряд неудачных попыток перед отправкой алерта (в Uptime Kuma это настраивается параметром «Retries» — сколько раз подряд проверка должна провалиться, прежде чем статус реально считается «down»). Это сглаживает единичные сетевые заминки, но всё ещё даёт узнать о реальном падении в течение нескольких минут, а не через час.

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