Мониторинг здоровья железа хостинга — на что смотрит арендатор VPS

MAATRIX GAMES

Сервер вроде бы ничего не делает — TPS в норме, плагинов немного, онлайн средний, а тики всё равно рвутся рывками, будто кто-то периодически отжимает у вас процессор. Первая мысль обычно "у меня руки кривые, что-то не так с конфигом", и админ час копается в server.properties вместо того, чтобы посмотреть на одну метрику, которая честно скажет: дело не в вас, а в перегруженном хосте хостинга. Разберём, что арендатор VPS вообще может увидеть о железе, на котором крутится его виртуалка, а что физически скрыто гипервизором, и как по доступным метрикам отличить "у меня баг" от "мне достался шумный сосед".

Что видно арендатору VPS, а что скрыто гипервизором

VPS — это не физический сервер, а виртуальная машина на общем железе, и здесь важно сразу зафиксировать границу. Изнутри гостевой системы (той, куда вы заходите по SSH) вы видите только то, что гипервизор решил показать: сколько CPU-ядер выделено вашей виртуалке, сколько RAM, какая внутри файловая система и сетевой интерфейс. Вы не видите температуру физических CPU хост-машины, SMART-показатели реальных дисков, загрузку соседних виртуалок по именам или топологию стойки — это уровень хост-системы, к которому у арендатора нет и не должно быть доступа по соображениям безопасности и приватности других клиентов.

При этом гипервизор (в основном это KVM или Xen — именно на них у большинства хостеров, включая MAATRIX GAMES, крутятся игровые VPS) прокидывает внутрь виртуалки набор косвенных метрик, которые как раз и позволяют судить о состоянии физического хоста, не имея туда прямого доступа: счётчики CPU steal, статистика диска через virtio-блочное устройство, задержки сети до внешних точек. По сути, вы читаете не термометр на процессоре хоста, а тень, которую перегруженный хост отбрасывает на вашу виртуалку — и этой тени достаточно, чтобы принять решение.

То, что вы видите через top или /proc, — это данные, которые гипервизор публикует намеренно, а не дыра в изоляции. Подробнее о границе между правами владельца физического сервера и правами арендатора VPS — в статье права владельца vs права арендатора VPS.

CPU steal time — главный индикатор перегруженного хоста

Steal time (в выводе утилит обозначается как st или %steal) — это доля времени, когда вашей виртуальной машине было выделено процессорное время по расписанию, но гипервизор не смог его дать, потому что физический CPU в этот момент обслуживал другие виртуалки на том же хосте. Это единственная метрика, которая напрямую и достоверно говорит: "физическое ядро сейчас занято не вами, а соседями" — и её видно из гостевой системы без каких-либо специальных привилегий.

Проверяется без установки чего-либо дополнительного — все нужные счётчики уже есть в ядре Linux:

# самый быстрый способ — top, колонка st в строке %Cpu(s)
top

# показывает steal по каждому ядру отдельно за интервал в 1 секунду
mpstat -P ALL 1 5

# то же самое, но с накоплением истории через sysstat
sar -u 1 10

Ориентир (это именно ориентир, а не измеренный порог, который годится для любого хоста): steal 0-2% почти всегда в пределах нормального шума и не стоит внимания. Steal, который держится в районе 10% и выше на протяжении минут, а не секунд, — уже повод насторожиться: ваша виртуалка регулярно недополучает выделенные ей такты CPU. Если steal доходит до 20-30% в моменты, когда именно у вас растёт онлайн или спавнится больше сущностей, это прямой кандидат объяснить лаги и просадки TPS, которые внешне выглядят как "движок не справляется", хотя на деле движку просто не додают процессор.

Оговорка: steal time не отличает "хост перегружен по вине хостера" от "у хостера просто закончился запас на этой ноде из-за роста нагрузки клиентов" — картина в метрике одинаковая. Отличить можно только по динамике: разовые скачки в пиковые часы — обычная жизнь shared-инфраструктуры, устойчивый рост steal день за днём без изменений в вашей нагрузке — сигнал написать в поддержку.

Диск: iowait и задержки как второй по важности сигнал

Второй по частоте виновник "необъяснимых" лагов — не CPU, а диск, особенно на бюджетных тарифах, где диски виртуалки — это тонко нарезанный слой поверх общего хранилища хостера (сетевого или локального RAID). Здесь арендатору доступны две группы метрик: доля времени, когда процессы ждут ввода-вывода (iowait), и реальная задержка отдельных операций чтения/записи.

# iowait виден в том же top/mpstat — колонка wa
top

# детальная статистика по устройствам: r/s, w/s, await (задержка в мс), %util
iostat -xz 1 5

# то же самое в реальном времени с историей
dstat -d --disk-util 1

Для игрового сервера, который постоянно пишет чанки, инвентари и логи (особенно Minecraft с частыми автосохранениями), нормальный await для NVMe-подложки — единицы миллисекунд, для сетевого хранилища на HDD-пуле — уже может быть 10-20 мс, и это не аномалия сама по себе. Настораживать должны не абсолютные цифры (они сильно разнятся между хостерами и накопителями), а резкий скачок await в 5-10 раз относительно вашего же обычного уровня при том же профиле нагрузки — диск хоста физически не успевает обслуживать очередь запросов, и это снова похоже на "шумных соседей", только на уровне дисковой подсистемы.

Полезно снимать baseline в спокойное время (типичные iowait/await ночью при низком онлайне) — тогда любое отклонение от своей же нормы видно сразу, без гаданий, что считается "плохим" числом на конкретном железе.

Память: что реально видно и где заканчивается прозрачность

С памятью арендатору проще и сложнее одновременно. Проще — потому что free -h и vmstat честно показывают, сколько RAM выделено виртуалке, сколько занято, сколько в кэше страниц. Сложнее — потому что физическая перегрузка памяти на хосте (когда гипервизор частично отдаёт чужую RAM другим виртуалкам через overcommit или balloon-драйвер) снаружи выглядит не как отдельная метрика "чужая нехватка памяти", а просто как аномально высокий steal time и общая просадка отзывчивости — маскируется под уже знакомую картину из первого раздела.

free -h
vmstat 1 5
# колонка si/so в vmstat — это своп ВНУТРИ вашей же виртуалки,
# не путать с балансировкой памяти хоста, которую изнутри не видно вообще

Если своп-раздел или своп-файл есть и si/so в vmstat регулярно не нулевые под обычной нагрузкой — это ваша зона ответственности: тарифа не хватает по памяти, нужен апгрейд или оптимизация числа плагинов/модов, а не жалоба хостеру. А вот если памяти формально достаточно (используется 60-70% от лимита), но при пиковой нагрузке растёт steal и падает отзывчивость — это снова косвенный след давления на хост.

Сеть: задержка и джиттер до собственного сервера

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

# базовая проверка стабильности до ближайшего апстрима хостера
ping -c 100 <IP шлюза или ближайшего апстрима>

# видно потери и джиттер по каждому хопу отдельно
mtr -rwc 100 8.8.8.8

# если нужен трафик именно игрового порта, а не ICMP
nc -zv -w2 <IP сервера> <порт игры>

Признак проблемы на стороне хоста, а не вашей игры: стабильно растущий джиттер (разброс между соседними значениями ping) при том, что ваш сервер не грузит канал (проверяется через vnstat или iftop, подробнее — в статье про мониторинг сетевого трафика игрового сервера). Если джиттер растёт именно у вас, а не у игроков в разных регионах одновременно — вероятнее локальная проблема сетевой карты хоста или перегруженный аплинк ноды, и это повод для тикета с приложенным mtr-отчётом.

Как собрать метрики в один дашборд, а не смотреть их вручную

Ручной запуск top и mpstat каждый раз, когда "что-то не так", работает, но не даёт истории — а для разговора с поддержкой нужна именно история: "steal держится выше 15% с 20:00 до 23:00 каждый день последнюю неделю" звучит убедительнее, чем "у меня иногда лагает".

Вариантов немного:

Если уже используете Prometheus и Grafana для мониторинга TPS и онлайна, добавить туда экспортёр node_exporter — вопрос одной команды, а steal time и iowait лягут в те же дашборды, что и игровые метрики. Подробная настройка связки описана в статье Grafana и Prometheus для игрового хостинга, а более лёгкий вариант с алертами через веб — в статье про Zabbix для мониторинга игровых серверов.

Порог для алерта разумно ставить не по абсолютному числу, а по длительности: разовый скачок steal до 15% на 10 секунд — шум, а steal выше 10% дольше 5 минут подряд — уже событие, достойное уведомления в Discord или на почту, чтобы не мониторить графики вручную по вечерам.

Когда это повод писать в поддержку, а когда проблема у вас

Главный вопрос после всех графиков — что с этим делать. Правило простое: если метрика показывает давление именно на хост (steal, скачки диска, сетевой джиттер) и это давление не объясняется вашей же нагрузкой (у вас не выросло число сущностей/игроков/плагинов в этот момент), это повод обратиться в поддержку хостера. Если же метрика показывает, что вы упираетесь в собственный лимит по CPU/RAM/диску, который сами же и выбрали в тарифе, — это не баг хостинга, а сигнал на апгрейд или оптимизацию.

Перед обращением в поддержку стоит собрать конкретику, а не писать "у меня лагает":

• Скриншот или лог mpstat -P ALL 1 60 за момент проблемы с колонкой %steal
• Время начала и конца эпизода (по возможности — точное, с точностью до минуты)
• Подтверждение, что ваша собственная нагрузка (онлайн, RCON-команды, автосейвы) в этот момент не менялась
• Для диска — вывод iostat -xz 1 10 с аномальным await

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

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