Мониторинг VPS: метрики CPU RAM нагрузка и алерты для админов

Мониторинг VPS полезен только тогда, когда он связывает метрики с действиями. Для VPS чаще всего первыми «ломаются» CPU и RAM: растёт нагрузка, проседает отклик, начинаются своп-страдания или процессы получают OOM. Если админ видит это не по одному графику, а через понятные алерты с контекстом, скорость реакции обычно возрастает заметно.

В этой статье разберём, какие метрики CPU и RAM действительно нужно собирать, как отличать похожие сигналы (например, load average и реальную загрузку CPU), и как настроить алерты так, чтобы они помогали, а не превращались в шум. Будем говорить про стандартные стеки для мониторинга VPS: Prometheus+Grafana+Alertmanager, Zabbix/Сагент, Netdata, а также про базовые принципы, которые подходят под любой инструмент.

CPU на VPS: что смотреть, чтобы понимать реальную нагрузку

CPU на виртуалках может деградировать по разным причинам: приложение грузит процессор, но чаще ещё встречаются задержки планировщика, I/O-подвисания и ограничение ресурсов со стороны хоста. Поэтому мониторинг VPS для CPU должен отвечать на два вопроса: «процессор занят?» и «почему он занят?».

Разница между load average и загрузкой CPU (%idle/%busy)

load average — это среднее число задач в очереди к исполнению за интервал. Он растёт не только из-за вычислений, но и при ожидании диска/сети, блокировках, нехватке потоков и т.д. В то же время %CPU (например, доля idle) показывает, сколько времени CPU простаивает.

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

• Если load average растёт, а %CPU остаётся невысоким, вероятны блокировки и I/O ожидания.
• Если и load average, и %CPU растут, приложение реально потребляет CPU.
• Если %CPU высок по пользователям, а графики iowait тоже растут, виновата связка CPU+I/O (часто это запросы, которые упираются в диск).

Именно поэтому в мониторинге VPS для CPU полезно держать одновременно:

• загрузку CPU (или как минимум idle/busy),
• iowait,
• load average,
• по возможности метрики планировщика/виртуализации (например, steal time).

iowait: сигнал, что CPU простаивает из-за I/O

iowait показывает время, когда CPU ждал завершения операций ввода-вывода. Это не «проблема приложения с CPU», но это всё равно деградация. Если iowait растёт вместе с общей нагрузкой, то алерт «CPU высокий» будет вводить в заблуждение.

Правильный подход для CPU-алертов:

• не реагировать только на %CPU,
• отдельно отслеживать iowait как признак I/O bottleneck.

Steal time: задержки от виртуализации

Для VPS важно понимать, что часть времени CPU может «красться» хостом. Steal time (в Linux это компонент, который часто экспортируют мониторинговые агенты) растёт, когда виртуалке не хватает реального CPU времени.

Обычно это проявляется так:

• %CPU в гостевой ОС выглядит умеренно,
• при этом приложение тормозит,
• отклик растёт, а внутренняя нагрузка не объясняет деградацию.

Если steal time стабильно растёт, алерты должны поднимать сигнал «проблема инфраструктуры», а не «оптимизируй код». Это критично для корректного триажа инцидента.

CPU saturation: как отличить «пик» от «системной проблемы»

Многие админы ставят порог «CPU > 90%» и получают шквал уведомлений из-за кратковременных всплесков. Для VPS обычно важнее «длительное превышение» и «частота роста».

Хорошая практика:

• вычислять среднее по окну (например, за несколько минут),
• требовать, чтобы условие держалось дольше минимального периода,
• добавлять отдельный алерт на «резкое ускорение» нагрузки (рост rate), если у тебя есть постоянные пики.

В результате ты получаешь:

• алерт на sustained high CPU,
• алерт на рост CPU за короткое время,
• отсутствие алертов на единичный пик.

RAM на VPS: занятость, кэш, swap и признаки давления

RAM мониторят не ради «сколько занято», а ради признаков нехватки: падение производительности, рост свопа, OOM и задержки GC/распределённых очередей. Для админов ключевое — уметь интерпретировать «used RAM» правильно.

MemAvailable важнее MemFree

Обычный «used» в Linux может выглядеть тревожно даже при наличии доступной памяти под кэш и reclaimable. Поэтому в мониторинге VPS для RAM надёжнее смотреть доступную память.

Если инструмент отдаёт MemAvailable, лучше опираться на него:

• чем ниже MemAvailable, тем ближе система к давлению по памяти,
• рост swap обычно следует за нехваткой или ухудшением поведения памяти.

Практика:

• алерт на low MemAvailable,
• алерт на появление/рост активности swap,
• алерт на OOM kills (если в системе они происходят).

Кэш и reclaimable: почему «used» иногда обманывает

Linux эффективно использует память под page cache. Это не «потраченные впустую гигабайты», а ускоритель для файловой системы. Если page cache занимает значительную долю, но при этом MemAvailable остаётся адекватным, система может жить долго.

Поэтому избегай алертов вида «RAM used > X%» без учёта доступной памяти. Они будут шумными и приведут к ложным действиям: перезапускам, масштабированию, чисткам кэшей.

Swap: алерт не на факт, а на скорость ухудшения

Swap может включаться по разным причинам: от реального дефицита памяти до особенностей приложения. Но как минимум три признака стоит отслеживать:

• увеличение swap in/out,
• рост swap usage,
• появление регулярной активности swap при обычной нагрузке.

В идеале алерт должен говорить администратору: «память закончилась или близко», а не просто «swap существует». Для этого условия строят на базе:

• доли MemAvailable,
• активности swap за окно,
• корреляции с ростом нагрузки.

OOM kills и перезапуски: отдельная линия защиты

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

• OOM kills,
• резкие перезапуски сервисов,
• падение частоты успешных запросов (если мониторишь приложение).

Для VPS это особенно важно, потому что перезапуск может быть «тихим»: лог-файлы могут не попадать в обзор, а метрики CPU/RAM покажут проблему слишком поздно.

Дополняем CPU и RAM: метрики, которые объясняют «почему»

Даже если задача — мониторинг VPS именно по CPU и RAM, без пары дополнительных «объясняющих» метрик триаж становится долгим.

Минимальный набор вокруг CPU/RAM:

• Диск: iops/latency (особенно write latency), заполнение файловых систем.
• Сеть: вход/выход, ошибки, drop-пакеты (если доступно).
• Процессы: число процессов/threads, наличие runaway (если есть агент уровня процессов).
• Время отклика (если есть HTTP/TCP чек): полезно для связки «метрика → влияние на пользователей».

С точки зрения алертов это превращается в модель: «CPU/RAM — сигнал», а «диск/сеть/чек — объяснение и приоритет».

Как собрать данные: агенты и сборщики метрик для мониторинга VPS

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

Варианты инструментов для мониторинга VPS

Чаще всего встречаются три подхода:

• Prometheus-стиль (scrape + exporters)
• node_exporter/другие exporters для хоста,
• Grafana для дашбордов,
• Alertmanager для маршрутизации алертов.

Плюс: гибкие правила, удобная версия правил, хороший контроль над выражениями.

• Мониторинг «встроенный в дашборд» (Netdata, похожие)
• быстро ставится,
• обычно есть много преднастроенных графиков.

Минус: сложнее тонко контролировать правила и интеграции без донастроек.

• Zabbix/схожие системы агентного мониторинга
• готовые шаблоны,
• алерты «из коробки»,
• строгий учёт данных.

Плюс: управляемость и сценарии. Минус: иногда тяжело поддерживать нестандартные метрики без разработок.

Если у тебя уже есть стек в команде — бери его. Но принципы остаются одинаковыми: качество метрик, единые имена, стабильные окна агрегации, корректные алерты.

Prometheus+Grafana+Alertmanager: базовая конфигурация подхода

Типовой дизайн для VPS выглядит так:

• node_exporter или аналог собирает системные метрики.
• Prometheus периодически опрашивает (scrape) экспортёр.
• Grafana показывает дашборды по CPU/RAM.
• Alertmanager отправляет уведомления и группирует алерты.

Важно заранее договориться о метках (labels). Минимум обычно:

• instance (или hostname),
• job (экспортёр),
• env (prod/stage),
• service (если это выделенные роли на VPS).

Без меток алерты превращаются в «пришлите портянку», и админ тратит время на поиск, где именно проблема.

Пример идеи правила для CPU (с sustained-логикой). Формула может отличаться в зависимости от того, какие метрики у тебя доступны, но смысл один: следить за долей времени в idle и выводить занятость:

«`yaml groups:

• name: vps-cpu

rules:

• alert: HighCPU_Sustained

expr: | (1 — avg by (instance) (rate(nodecpuseconds_total{mode=»idle»}[5m]))) > 0.85 for: 10m labels: severity: page annotations: summary: «Высокая CPU нагрузка на {{ $labels.instance }}» description: «CPU занята дольше 10 минут. Проверь нагрузку процессов и признаки iowait/steal time.» «`

Обрати внимание на три элемента:

• Окно для rate/range: сглаживает краткие пики.
• for: 10m — фильтрует всплески.
• Аннотации: заранее подсказка, что делать дальше.

Дашборды: как сделать графики, на которых реально принимают решения

Хороший дашборд по мониторингу VPS на CPU/RAM отвечает на вопрос «что происходит сейчас» за 30–60 секунд. Для этого графики группируют по смыслу, а не по метрикам.

Рекомендованная компоновка:

• CPU блок
• % idle (или % busy),
• iowait,
• load average,
• steal time (если есть).
• RAM блок
• MemAvailable,
• swap usage/активность,
• (опционально) OOM kills или события памяти.
• Контекст
• диск latency / iops,
• вход/выход по сети,
• health check (HTTP 200/timeout) или хотя бы нагрузка по сервису.

Если в дашборде есть CPU и RAM, но нет iowait и MemAvailable, админ будет вынужден гадать. А гадание дорого.

Пороговые алерты: как проектировать правила для CPU и RAM

Пороговые алерты остаются самым практичным инструментом, если их правильно настроить. Проблема обычно не в порогах, а в том, как они заданы: где окно, сколько длится, как группируются уведомления, есть ли Runbook.

Правила для CPU: что и как алертить

Для CPU на VPS обычно нужны минимум два класса алертов:

• Sustained high CPU
• условие держится долго (несколько минут),
• severity выше, если это совпадает с деградацией чеков или растущим iowait.

• CPU spike / rapid growth
• ловит «резко стало плохо»,
• ниже severity или другой маршрут (не всегда нужно сразу будить всех).

Отдельно стоит рассмотреть алерты на iowait и steal time:

• высокий iowait и рост времени запросов часто означает I/O bottleneck,
• высокий steal time — сигнал про виртуализацию/хост, иногда это не решается кодом.

Мини-рекомендации к порогам:

• не опирайся на один фиксированный процент для всех VPS: у разных инстансов разный режим работы,
• лучше настрой порог как относительное условие к baseline (например, «выше обычного на X»), либо используй процентили.

Если хочешь оставить пороги фиксированными, сделай хотя бы так:

• разнеси severity на «предупреждение» и «пейдж»,
• добавь for длительность,
• добавь анти-шторм защиту (см. ниже про шум).

Правила для RAM: MemAvailable, swap и признаки OOM

Для RAM хорошо работают три измерения:

• MemAvailable низкая
• означает, что системе скоро станет тяжело держать текущий набор рабочих наборов.

• Swap активен (или растёт usage)
• означает, что память реально вытесняется на диск, и latency обычно начинает расти.

• OOM kills / падения сервисов
• означает, что система уже «перешла грань».

Как лучше оформлять алерты:

• Один алерт на low MemAvailable с for (например, 10–15 минут).
• Второй алерт на рост swap activity, если swap есть.
• Третий алерт на OOM kills (обычно page сразу).

Если swap отключён намеренно, убери алерт на swap usage, иначе он будет бесполезен или вводить в заблуждение.

Когда CPU/RAM нормальные, но система тормозит: «нагрузка без загрузки»

Иногда нагрузка в очередях растёт, пользователи жалуются на таймауты, а %CPU невысокий. Это типичный симптом:

• блокировок,
• ожидания диска/сети,
• проблем с блоками ввода/вывода,
• перегрузки внешних зависимостей (БД/кэш).

Для таких кейсов полезны алерты на «следствия», связанные с метриками влияния:

• HTTP timeout rate растёт,
• средняя/пятидесяти- или девяностоперцентиль задержки растёт,
• количество ошибок в логике запросов растёт (если у тебя есть приложение-метрики).

Даже если цель статьи — CPU/RAM, правильная алерт-стратегия на VPS обычно включает минимум один сигнал «как это ощущает сервис».

Алерты и шум: как сделать уведомления полезными

Админы «бросят» алерты, если они шумные. Поэтому важны механики Alertmanager (или аналогов) и дизайн условий.

Группировка, дедупликация и подавление повторов

Идеальная схема уведомлений обычно такая:

• группируем по instance (или по instance+alertname),
• ограничиваем частоту повторов,
• держим cooldown между похожими алертами.

Это снижает вероятность, что во время масштабного инцидента уведомления затопят команду.

Обычно разумно:

• page — редкие и действительно аварийные события (OOM, длительный sustained high CPU при деградации),
• warn — события, требующие внимания, но без немедленного включения дежурного.

Hysteresis: чтобы порог не «пилял» туда-сюда

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

• используй for (длительность условия),
• делай разные пороги на включение и выключение (если инструмент позволяет),
• либо подстраивай окна сглаживания так, чтобы флуктуации не пересекали порог.

Runbook в алерте: что именно делать

У админа часто есть 30–60 секунд, чтобы начать действия. Поэтому в алерте должна быть минимальная инструкция:

• на какой метрике алерт,
• что проверить первым,
• где смотреть логи/дашборды,
• какие действия безопасны (масштабирование, перезапуск, ограничение нагрузки).

Если Runbook отсутствует, админ будет открывать дашборд и искать контекст. Это увеличивает время реакции и повышает вероятность ошибки.

Пример аннотаций к алерту на RAM:

• summary: что случилось
• description: кратко причины и первый шаг (например, проверить MemAvailable, swap, OOM, загрузку диска)
• dashboard: ссылка на дашборд (если у тебя это поддерживается)
• runbook: ссылка на документ с действиями

Аномалии вместо фиксированных порогов: когда thresholds не работают

Пороговые алерты хорошо работают, когда поведение системы стабильно. Но у VPS часто есть «режимы дня»: ночью нагрузка ниже, утром — выше. Здесь пороги либо будут шуметь, либо пропускать.

Базовые линии и сезонность

Подход для мониторинга VPS:

• собрать данные за время,
• построить baseline для CPU и RAM (типичные диапазоны),
• включить алерты на отклонения от baseline.

В инструментах это реализуют по-разному:

• через процентили и сравнение с текущим окном,
• через модели сезонности,
• через alert на «аномальный рост rate».

Если у тебя нет возможности внедрять сложные модели, уже простая идея помогает: сравнивай текущие значения с тем, что было в прошлые «аналогичные» часы.

Ищи ускорение и изменение, а не только уровень

Уровень CPU/RAM важен, но не всегда хватает. Полезны производные:

• rate изменений CPU (рост за минуту),
• производная по MemAvailable (насколько быстро «съедается» память),
• изменение swap активности.

Если MemAvailable падает слишком быстро, это часто означает утечки или всплеск объёма данных. Тут алерт должен быть раньше, чем «MemAvailable пересек порог», иначе OOM случится быстрее, чем ты успеешь среагировать.

Связка «причина → эффект»

Когда у тебя есть влияние на пользователей (health check, latency, errors), лучше строить алерт по модели:

• причина: CPU/RAM/IO ухудшение,
• эффект: таймауты/ошибки/рост задержек.

Это снижает ложноположительные срабатывания. CPU может быть высоким в момент, когда сервис всё ещё отвечает нормально — тогда тревожить сразу смысла может не быть.

Практический чек-лист: развернуть мониторинг VPS по CPU/RAM и алертам

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

Шаги

• Определи цели алертов
• что считаем аварией: OOM, длительная деградация latency, заполнение диска,
• что считаем предупреждением: приближение к порогу памяти/CPU.

• Выбери метрики CPU и RAM
• CPU: idle/busy или аналог, iowait, load average, steal time (если есть).
• RAM: MemAvailable, swap usage/activity, события OOM kills (если доступны).
• Контекст: диск latency или iops, health check.

• Поставь сборщик метрик и проверь поступление данных
• убедись, что метрики появляются в хранилище,
• проверь задержку (сколько минут от события до графика).

• Построй базовый дашборд
• один экран CPU (idle/iowait/load/steal),
• один экран RAM (MemAvailable/swap/OOM),
• один экран контекста (диск/сеть/health).

• Настрой 3–6 алертов максимум на первый запуск
• CPU sustained high,
• iowait высокий (или как индикатор I/O bottleneck),
• MemAvailable низкая,
• swap активен (если swap включён),
• OOM kills,
• алерт по эффекту (latency/errors/health) при желании.

• Добавь Runbook в алерты
• что проверить первым,
• куда смотреть логи,
• безопасные действия и что не делать.

• Проверь уведомления
• тестируй маршрутизацию (Alertmanager/Slack/Telegram/email),
• убедись, что алерт приходит с instance и ссылкой на дашборд.

• Настрой анти-шторм
• for, группировка, cooldown,
• разные severity по критичности.

Минимальный набор алертов (ориентир)

• HighCPU_Sustained: CPU занята дольше N минут.
• HighIOWait: iowait высок и держится.
• LowMemAvailable: доступная память упала и держится.
• SwapTrendingUp: swap usage/IO растёт.
• OOMKills: произошло OOM убивание или сервисы начали умирать по памяти.
• ServiceDegraded: health/latency ухудшились при росте CPU/RAM или отдельно.

Список можно сократить, если цель — быстро запустить полезную систему. Но не стоит начинать с 20 алертов: команда утонет в уведомлениях.

Типичные ошибки мониторинга VPS по CPU и RAM

Разберём частые проблемы, которые встречаются почти в каждом проекте, где мониторинг «появился позже продакшна».

Ошибка 1. Алертить только по CPU % без iowait

Ставишь порог на CPU, получаешь много срабатываний, но причины разные. В итоге админ открывает дашборд и понимает, что CPU не был реальной причиной, а тормозило ожидание I/O. Итог: недоверие к системе.

Как исправить:

• добавь iowait,
• используй runbook с шагом «проверь I/O и steal time».

Ошибка 2. Путать load average и реальную загрузку CPU

Load average растёт из-за диска или блокировок, но админ видит рост нагрузки и думает, что надо оптимизировать CPU. Это ведёт к неправильным действиям: оптимизация кода вместо диагностики диска/очередей.

Как исправить:

• всегда смотри вместе load average и CPU idle/busy,
• добавь iowait.

Ошибка 3. Алерт по used RAM вместо MemAvailable

Used RAM в Linux может быть «высоким», пока система держит page cache. В этот момент процессам может хватать памяти, а алерт всё равно срабатывает.

Как исправить:

• используй MemAvailable,
• добавь swap и OOM kills как подтверждение давления.

Ошибка 4. Слишком жёсткие пороги и отсутствие for

Если алерт реагирует на 1 минуту или на один выброс, он будет трясти команду. Мониторинг превращается в фон.

Как исправить:

• добавь for,
• сгладь метрики (окна rate/avg),
• раздели severity.

Ошибка 5. Нет контекста в уведомлении

Сообщение вида «CPU alert» не даёт ответить на вопрос «где и что делать». Админ вынужден искать инстанс, искать дашборд, листать логи — время теряется.

Как исправить:

• включи instance/hostname,
• добавь ссылку на дашборд,
• вставь short runbook.

Ошибка 6. Игнорирование steal time и инфраструктурных причин

Если проблемы приходят из-за перегрузки хоста, оптимизация приложения не поможет. Тогда алерт без steal time ведёт к неправильным расходам времени.

Как исправить:

• добавь steal time в CPU блок,
• сделай описание в алерте: «проверь steal time/инфраструктуру».

Как проверить, что алерты реально работают: тестирование и регламент

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

Проверь доставку и маршрутизацию

Тестируй так:

• инициируй заведомо срабатывающий алерт (в тестовом окружении или через отдельный test rule),
• убедись, что приходит нужный получатель,
• проверь, что уведомление содержит instance и ссылки.

Если Slack/Telegram/почта настроены неправильно, ты узнаешь об этом только на инциденте. Поэтому проверка до инцидента экономит нервы.

Проверь, что метрики не «умирают тихо»

Ещё один сценарий: экспортёр/агент перестал собирать данные, но алерты не срабатывают, потому что метрик нет, и правила не оцениваются. Это решают:

• алерты на отсутствие данных (если инструмент поддерживает),
• базовые health checks для scraping.

Даже простое правило «нет метрик за X минут» уже повышает надёжность.

Веди регламент триажа

Регламент нужен не для бюрократии, а чтобы админ не действовал импульсивно. Минимальный регламент по CPU/RAM:

• Сначала проверить влияние: health/latency/errors.
• Затем уточнить причину:
• CPU vs iowait vs steal time,
• MemAvailable vs swap vs OOM kills.
• Затем выбрать действие:
• масштабирование/перераспределение,
• перезапуск только если есть подтверждение и есть безопасный план,
• работа по узкому месту (диск, сеть, очередь, приложение).
• После — зафиксировать вывод и улучшить алерт при необходимости.

Итог: алерты по CPU и RAM, которые ускоряют реакцию, а не отнимают внимание

Мониторинг VPS по метрикам CPU RAM и нагрузке должен отвечать на практические вопросы: что происходит, почему это происходит и что сделать прямо сейчас. Если ты смотришь вместе CPU idle/busy, load average, iowait и steal time, а по памяти опираешься на MemAvailable, swap и OOM kills, то диагностика становится намного точнее.

Следующий шаг — не усложнять. Запусти небольшой набор алертов с for и группировкой, добавь Runbook прямо в уведомления и проверь доставку. Так ты получишь систему, которая действительно помогает админам на реальных инцидентах: меньше шума, быстрее триаж, меньше повторных ошибок.