Блог
Серверы

Как мониторить VPS-сервер

Мониторинг VPS-сервера должен показывать не только “сервер доступен”, но и состояние ресурсов: heartbeat агента, CPU, RAM, диск, load average, сеть и историю инцидентов. Иначе команда видит падение сайта, но не понимает, что происходило на сервере перед сбоем.

мониторинг VPSмониторинг сервераCPURAMheartbeat

Шкала риска

Демо-ориентир для быстрой интерпретации результата.

Норма

Показатель выглядит штатно.

Внимание

Пора проверить динамику и причины.

Риск

Нужна диагностика до инцидента.

Критично

Сервис может быть недоступен пользователям.

Почему ping сервера недостаточно

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

Heartbeat особенно важен: он показывает, что агент на сервере жив и регулярно передаёт данные. Если heartbeat пропал, это может означать остановку агента, сетевую проблему, зависший сервер или сбой доступа к backend мониторинга. Такой сигнал помогает отличить “сайт упал” от “сервер перестал присылать состояние”.

  • ping не показывает состояние приложения
  • heartbeat подтверждает, что агент работает
  • ресурсные метрики объясняют деградацию
  • внешний мониторинг сайта показывает пользовательский симптом

CPU и load average

CPU показывает текущую загрузку процессора, а load average помогает увидеть очередь задач. Для VPS с малым числом ядер даже короткие пики могут заметно влиять на сайт. Если load стабильно выше числа CPU-ядер, запросы могут ждать выполнения, а TTFB будет расти.

Высокий CPU не всегда означает проблему. Нужен контекст: что происходило в это время, были ли деплои, cron-задачи, бэкапы, индексация, всплеск трафика или атака. Полезно смотреть не только среднее значение, но и максимумы за период.

  • сравнивайте load average с числом CPU-ядер
  • смотрите пики CPU рядом с ростом TTFB
  • проверяйте cron и фоновые задачи
  • отделяйте краткий пик от постоянной перегрузки

RAM, swap и OOM

RAM критична для приложений, базы данных, кешей и системных процессов. Когда память заканчивается, сервер начинает активнее использовать swap или убивает процессы через OOM killer. Для пользователя это может выглядеть как 500, 502, долгий ответ или периодическое падение сайта.

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

  • следите за процентом использования RAM
  • проверяйте swap и OOM-события
  • ищите постепенный рост после деплоя
  • сравнивайте RAM с ошибками приложения

Диск: свободное место, запись и последствия переполнения

Заполненный диск — одна из самых частых и неприятных причин аварий. Сайт может перестать писать логи, загружать файлы, сохранять сессии, обновлять кеш или выполнять операции базы данных. При этом внешне проблема часто проявляется как 500 или 503.

Для VPS важно отслеживать не только занятое место, но и скорость роста. Если лог-файл или бэкапы начинают быстро съедать диск, мониторинг должен предупредить до того, как место закончится. Особенно опасны серверы без регулярной ротации логов и очистки временных файлов.

  • контролируйте процент заполнения диска
  • настройте ротацию логов
  • проверяйте старые бэкапы и временные файлы
  • реагируйте заранее, а не при 100% заполнения

Как настроить пороги и уведомления

Универсальных порогов для всех VPS нет, но есть практичные ориентиры. CPU и load важны при устойчивой перегрузке, RAM — когда значение близко к лимиту, диск — заранее, обычно до критических 90-95%. Heartbeat должен быть строгим: если агент перестал присылать данные, состояние сервера неизвестно.

Порог должен вести к действию. Если уведомление не помогает понять, что проверить, его будут игнорировать. В сообщении полезно видеть метрику, значение, порог, сервер, время и подсказку: проверить процессы, логи, cron, диск, базу или сеть.

  • делайте разные пороги для warning и critical
  • уведомляйте по устойчивому состоянию, а не одиночному шуму
  • показывайте значение и порог в уведомлении
  • храните историю для анализа повторяющихся проблем

Безопасность агента мониторинга

Агент мониторинга должен быть предсказуемым и безопасным. Для базового мониторинга достаточно read-only sensor: он собирает метрики и отправляет heartbeat, но не выполняет команды на сервере. Это снижает риск и упрощает объяснение владельцу инфраструктуры.

Если агент перестал работать, мониторинг должен показать это отдельно. Иначе команда может думать, что сервер здоров, хотя на самом деле данные просто перестали приходить. Поэтому heartbeat — обязательная часть мониторинга VPS.

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

  • агент собирает метрики как read-only sensor
  • агент не должен выполнять команды на сервере
  • потеря heartbeat — отдельный инцидент
  • серверные метрики нужно сочетать с внешней проверкой сайта

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

Какие метрики VPS нужно мониторить в первую очередь?

Heartbeat, CPU, load average, RAM, диск, сеть и состояние сайта снаружи. Вместе они показывают и пользовательский симптом, и состояние сервера.

Достаточно ли ping для мониторинга VPS?

Нет. Ping не показывает состояние приложения, базы, диска и HTTP-ответа сайта. Сервер может пинговаться, но сайт уже будет недоступен.

Что значит пропал heartbeat?

Агент перестал передавать данные. Причина может быть в сервере, агенте, сети или доступе к backend мониторинга. Это нужно разбирать как отдельный инцидент.

Нужен ли root-доступ агенту мониторинга?

Для read-only мониторинга обычно не нужно давать агенту больше прав, чем требуется для чтения системных метрик. Он не должен выполнять команды на сервере.

Контролируйте сайт автоматически

Проверяйте доступность, TTFB, SSL, серверные метрики и получайте уведомления ответственным.