Опубликовано вНовости

Настройка мониторинга VPS: CPU, RAM и аптайм для сайта

Настройка мониторинга VPS: CPU, RAM и аптайм для сайта

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

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

Базовая архитектура: как собрать метрики и алерты

Чтобы настройка мониторинга VPS не превратилась в набор разрозненных графиков, полезно держать в голове простую схему.

  1. Источник метрик

Это агент или экспортёр, который читает состояние системы: CPU, RAM, swap, загрузку, события OOM, диски (если нужно). Для Linux обычно используют node_exporter или аналоги.

  1. Сбор метрик и хранение

Система типа Prometheus забирает метрики по HTTP и хранит их. Если нужен удобный долгий архив, наращивают связку с long-term storage или используют managed-решения.

  1. Визуализация

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

  1. Алерты

Alertmanager отправляет уведомления. Здесь же важно настроить дедупликацию и группировку, чтобы вы получали одно осмысленное сообщение вместо потока.

  1. Мониторинг аптайма

Это отдельный слой: пинг, проверка порта, HTTP/HTTPS проверки, иногда DNS. Можно сделать это тем же мониторингом, например через blackbox_exporter, а можно поставить специализированный инструмент вроде Uptime Kuma.

Вне зависимости от стека, логика одна: сначала добейтесь корректного сбора, затем настройте пороги и окна, потом проверьте алерты на «контролируемой» ситуации (например, нагрузка на CPU в тесте).

Метрики CPU для VPS: что собирать и как интерпретировать

CPU-метрики важны не потому, что «всё должно быть зелёным», а потому что перегрев по CPU быстро превращается в рост времени ответа и очереди запросов. Для сайта критично понимать не только загрузку, но и характер нагрузки: равномерная она или взрывная, есть ли троттлинг, как ведут себя steal-проценты (актуально для виртуалок).

Какие метрики обычно дают максимальную пользу:

  • CPU usage (utilization), обычно в процентах
  • Load average (1/5/15 минут), но с осторожностью
  • CPU steal time (если доступно в вашем окружении)
  • Context switches и процессы в run queue (если есть потребность в глубокой диагностике)
  • Метрики throttling (часто для контейнеров/виртуализации, зависит от платформы)

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

Типичная ошибка при интерпретации load average: считать её «процентами» и делать вывод без контекста. На многоядерных машинах load average может быть высоким, но сайт может работать нормально, если реальные потоки исполняются эффективно. Поэтому для сайта полезно связать CPU usage с метриками приложения: latency, request rate, ошибки. Если приложение ещё и имеет метрики (например, через Prometheus exporter), сравнение ускоряет диагностику.

Практичная настройка алертов по CPU

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

  • Тревога при высоком CPU usage дольше N минут
  • Отдельная тревога при резком росте CPU (если у вас бывают «внезапные» всплески)
  • Сигнал при устойчивом росте load average относительно количества ядер (если вы это используете)

Если взять условный ориентир, часто применяют порог в районе 80% на среднюю загрузку и подтверждение в несколько минут. Но это именно ориентир: для некоторых веб-нагрузок пороги ниже, для других выше. Главное: выбирайте пороги на основе поведения вашего сайта под нормальной нагрузкой.

В Prometheus rules это может выглядеть так (пример, который нужно адаптировать под ваши значения и имена метрик):

«`yaml groups:

  • name: cpu

rules:

  • alert: HighCPUUsage

expr: (100 — avg by(instance) (irate(nodecpuseconds_total{mode=»idle»}[5m])) * 100) > 80 for: 5m labels: severity: warning annotations: summary: Высокая загрузка CPU на {{ $labels.instance }} description: CPU > порога {{ $value }}% в течение 5 минут. «`

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

Метрики RAM для VPS: как отследить утечки, давление и OOM

Проблемы с памятью обычно проявляются хуже и позже, чем кажется. CPU может быть загружен, но сайт работает. А вот RAM начинает «подъедать» кэш, приводит к росту времени операций и в худшем случае заканчивается OOM-killer’ом. В результате приложение падает или начинает перезапускаться.

Для мониторинга RAM стоит собирать минимум два типа данных:

  • Уровень занятости памяти (free/available)
  • Наличие и использование swap
  • События, связанные с нехваткой памяти (OOM) — если доступны

Что именно отслеживать в системе:

  • MemAvailable или аналог доступной памяти
  • Swap usage и swap in/out (если включен swap)
  • Оценка давления: когда доступной памяти мало, даже «недоиспользованная» память начинает ухудшать поведение
  • Отдельно стоит следить за OOM events и перезапусками сервисов (если есть systemd/journald интеграция)

Здесь важно не путать «free» и «available». Во многих системах кэш и буферы держат память, и free будет выглядеть пугающе, хотя система в целом справляется. MemAvailable обычно более практична для оценки реального риска.

Логика алертов по RAM: не только проценты

С RAM проще всего ошибиться в одном из двух сценариев: слишком ранний алерт на процентах без учёта кэша или слишком поздний алерт, когда OOM уже случился. Чтобы этого избежать:

  1. Выберите ориентир на доступную память (MemAvailable), а не на «free».
  2. Используйте окно для подтверждения, например 5–10 минут.
  3. Разведите severity: предупреждение при устойчивом снижении доступной памяти и критика при явных признаках OOM или резком скачке swap.

Пример правила, которое опирается на доступную память (адаптируйте порог под вашу систему):

«`yaml groups:

  • name: ram

rules:

  • alert: LowMemAvailable

expr: nodememoryMemAvailablebytes / nodememoryMemTotalbytes < 0.1 for: 10m labels: severity: warning annotations: summary: Низкая доступная RAM на {{ $labels.instance }} description: MemAvailable < 10% в течение 10 минут. «`

Почему окно 10 минут полезно: кратковременные пики обычно не требуют вмешательства. А вот длительное давление на память часто означает утечку, рост кэшей сверх нормы или неудачную настройку лимитов.

Отдельно подумайте о swap

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

  • Не делайте swap своим основным алертом «всегда».
  • Делайте предупреждение при устойчивом swap usage.
  • Делайте критический алерт при росте swap вместе с признаками деградации (например, latency или рост ошибок приложения).

Если у вас отключён swap, это тоже нормально, просто тогда критичность смещается в сторону OOM и перезапусков сервисов. В этом случае без событий приложения вы будете узнавать об аварии позже.

Аптайм: как измерить, что сайт действительно доступен

Аптайм для сайта — не то же самое, что «сервер отвечает по ping». Пинг может быть успешным, а HTTP может отдавать 500 или зависать. Поэтому мониторинг аптайма стоит строить по уровням: от хоста к приложению.

Минимальный уровень:

  • Проверка TCP-порта (есть ли соединение)
  • HTTP/HTTPS проверка (ответ приходит, код корректный)
  • Проверка нужного пути (например, /health или /)
  • Контроль времени ответа (latency) хотя бы в смысле «быстрее/медленнее»

Если у вас есть авторизация или контент дорогой по ресурсу, выбирайте лёгкий эндпоинт для проверки. Частая ошибка — проверять тяжёлую страницу, которая сама по себе может деградировать. Тогда вы будете ловить не падение сайта, а проблемную диагностику.

Настройка HTTP-check для аптайма

Если используете blackbox_exporter, вы получите метрики задержки и статусов и сможете интегрировать всё в единый Prometheus. Пример идеи: задать несколько целей:

  • http://example.com/health
  • http://example.com/ (если это дешёвый вариант)
  • https://example.com/health (если есть TLS)

В Uptime Kuma логика похожа, только конфигурация проще: вы указываете URL, таймаут, интервал и получаете уведомления.

С точки зрения алертов часто применяют такие правила:

  • Сайт недоступен (сетевой сбой) — критическое событие
  • HTTP код не в ожидаемом диапазоне — критическое
  • Долгое время ответа — предупреждение или критическое в зависимости от SLA

Порог по latency нужно подбирать. Если ваш сайт всегда медленный, алерт по «> 1 секунды» может быть бессмысленным. Лучше начать с наблюдений: посмотрите распределение времени ответа в норме, а затем определите что считать аномалией.

Склейка метрик CPU, RAM и аптайма в одну картину

Самая полезная часть настройки мониторинга VPS — не отдельно графики CPU, отдельно графики RAM, и отдельно аптайм. Полезнее связать их по времени с контекстом.

Например, если аптайм начинает падать, а в тот же момент CPU подскакивает и растёт latency, это похоже на перегрузку. Если аптайм «то работает, то падает», при этом RAM постепенно проседает и после этого идут перезапуски — вероятно, проблема в памяти или в поведении приложения. Если аптайм падает при нормальном CPU и RAM, стоит проверять сетевые эффекты, доступность БД, файловые системы и настройки веб-сервера.

Практический лайфхак: сделайте шаблон панели в Grafana с тремя рядами.

  1. График CPU usage с подписями периодов высокой нагрузки (если есть deployment, отметьте их)
  2. График MemAvailable и swap usage
  3. График времени ответа и ошибок HTTP чеков

Тогда вы сможете отвечать на вопрос «что было раньше» за пару минут: перегрузка CPU/RAM или отказ на уровне HTTP.

Ещё одна связка: добавьте метрики приложения, если можете. Например, exporter для Nginx/Apache, для базы данных, для языка/фреймворка. Даже небольшой набор ускоряет диагностику и уменьшает число предположений.

Настройка алертов: пороги, окна, каналы и дедупликация

Алерты — это то, ради чего люди вообще внедряют мониторинг. Но неправильные алерты быстро превращаются в шум.

Хорошее правило: алерт должен отвечать на один конкретный вопрос и содержать достаточно контекста, чтобы вы понимали, куда смотреть дальше.

Что стоит включать в текст уведомления:

  • Инстанс/сервер (hostname или instance label)
  • Тип симптома (CPU high, mem low, HTTP down)
  • Значение метрики и порог
  • Время, сколько уже длится (for/окно)
  • Рекомендованный следующий шаг (хотя бы общий: проверить логи сервиса, посмотреть очередь, проверить доступность upstream)

Дедупликация и группировка нужны обязательно. Иначе вы будете получать уведомления на каждую цель или на каждый цикл проверки. Группируйте по сервису и статусу, а не по каждой метрике отдельно.

Как выбрать severity: warning vs critical

Часто используют минимум два уровня:

  • warning: аномалия, которая может привести к инциденту
  • critical: подтверждённый инцидент, когда приложение не доступно или есть признаки быстрого ухудшения

Например:

  • CPU > порога 5 минут: warning
  • CPU > порога 15 минут и параллельно падает аптайм или растёт latency: critical
  • MemAvailable низкая 10 минут: warning
  • OOM events или критические перезапуски сервиса: critical
  • HTTP 5xx или таймауты healthcheck: critical

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

Каналы уведомлений и расписания

Выберите каналы, которые люди реально проверяют: Slack/Telegram/почта/внутренний чат. Настройте маршрутизацию по severity. Часто удобно:

  • warning отправлять в общий канал в течение рабочего времени
  • critical — в любое время, с эскалацией на дежурного

Если есть on-call процесс, свяжите severity и расписания с ротацией. Если on-call нет, хотя бы настройте отдельный канал для критики, чтобы важное не тонуло.

Минимальный набор внедрения за один вечер

Если цель — быстро получить пользу, начинайте с «работающего каркаса», а не с идеального мониторинга.

Шаги:

  1. Проверьте доступность хоста и систему метрик

Убедитесь, что ваш экспортёр метрик доступен (порт открыт, не блокируется firewall) и Prometheus/сборщик видит нужные серии.

  1. Соберите панель CPU и RAM в Grafana

Сделайте два графика: CPU usage и MemAvailable/swap usage. Добавьте подписанные пороги или хотя бы горизонтальные линии.

  1. Настройте аптайм на уровне HTTP

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

  • Добавьте алерты минимум на три вещи
  • высокий CPU (warning/critical по окну)
  • низкая доступная RAM (warning) и OOM/перезапуски (critical)
  • падение HTTP health (critical)
  1. Протестируйте алерты

Отключите сервис в тесте или имитируйте деградацию (осторожно, лучше на staging). Убедитесь, что уведомления приходят и содержат контекст.

  1. Зафиксируйте runbook

Напишите коротко: что делать при каждом типе алерта. Это может занять страницу в Notion или Confluence. Без runbook даже хороший мониторинг не ускоряет работу.

Если вы делаете мониторинг на нескольких VPS, начните с одного «эталонного» сервера и отработайте процесс. После этого тиражирование конфигов станет простой копией с подстановкой инстансов.

Частые ошибки при мониторинге VPS и как их избежать

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

  1. Слишком много алертов на каждую метрику

Итог: вы перестаёте читать уведомления. Решение: ограничьте алерты симптомами, которые требуют действий, и добавляйте окна for.

  1. Пороги «из интернета» без подстройки

80% CPU может быть нормой для одной нагрузки и аварией для другой. Решение: посмотрите данные за пару недель (или дни, если сервис новый) и отталкивайтесь от фактического поведения.

  1. Аптайм проверяет тяжёлую страницу

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

  1. Игнорируют связку с приложением

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

  1. Мониторинг живёт на том же VPS, который может упасть

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

  1. Нет проверки корректности датчиков

Иногда экспортёр установлен, но метрики не собираются из-за прав, SELinux, неправильного порта или фильтров. Решение: регулярно проверяйте, что метрики обновляются (например, через отсутствие stale данных).

Проверка качества: что должно быть «готово к бою»

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

  • Графики CPU и RAM отображают реальные изменения на вашем сервере
  • Аптайм healthcheck показывает корректный статус при нормальной работе и при контролируемом отключении
  • Алерты приходят один раз на инцидент, а не на каждый цикл проверки
  • В уведомлениях есть контекст: где проблема, что именно произошло, с какой длительностью
  • Есть понятные первые шаги в runbook

Полезно также провести небольшую «проверку на симуляции»: раз в месяц воспроизводить типовой сценарий (например, перегрузить CPU в тестовом интервале или временно остановить сервис на staging). Это укрепляет доверие к сигналам и помогает настроить пороги под реальную жизнь.

Вывод: настройте мониторинг VPS так, чтобы он сокращал время реакции

Настройка мониторинга VPS для сайта становится по-настоящему полезной только тогда, когда метрики CPU, RAM и аптайм работают вместе: CPU и RAM говорят о причинах нагрузки и рисках деградации, аптайм показывает, что происходит с доступностью для пользователя, а алерты связывают это в единый поток действий.

Если вы начнёте с минимального набора (CPU, RAM, HTTP healthcheck, несколько аккуратных алертов с окнами) и добавите дашборд, где всё видно на одной временной оси, у вас появится инструмент раннего предупреждения. Следующий шаг — подстройка порогов под ваше поведение и маленький runbook для каждого типа события. После этого мониторинг перестаёт быть «просто графиками» и начинает реально экономить время на расследования.