Мониторинг доступности сайта: что и как отслеживать

Опубликовано: 01.09.2026

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

Почему пинга главной недостаточно

Проверка «главная страница отдаёт 200» ловит только полное падение. Она не заметит ситуаций, в которых сайт формально жив, но бизнес стоит:

  • главная работает из кэша, а личный кабинет отдаёт ошибку базы данных;
  • страницы открываются, но форма заявки молча не отправляется;
  • сайт доступен, но оплата не проходит из-за истёкшего сертификата у платёжного шлюза;
  • всё работает, но страница грузится двенадцать секунд.

Отсюда следует основной принцип: проверять нужно пользовательский путь, а не факт ответа сервера.

Сценарная проверка

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

Такая проверка ловит проблемы, невидимые для простого пинга. Она сложнее в настройке и запускается реже — раз в 5–15 минут вместо каждой минуты, — но именно она отвечает на вопрос, может ли клиент сделать заказ.

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

Что отслеживать помимо доступности

Метрики, которые дают предупреждение заранее:

  • Время отклика. Рост среднего времени ответа почти всегда предшествует падению. Смотреть стоит не среднее, а перцентили: 95-й показывает, что происходит у самых невезучих посетителей, и именно он отражает реальный опыт.
  • Место на диске. Одна из самых частых и при этом самых глупых причин аварии. Логи растут, диск заканчивается, база перестаёт писать.
  • Срок действия сертификата. Даже при автоматическом обновлении контроль нужен: продление ломается тихо, а узнают об этом все посетители сразу.
  • Количество ошибок 5xx. Всплеск серверных ошибок при формально доступном сайте — сигнал, что часть запросов не обрабатывается.
  • Состояние очередей и фоновых задач. Если рассылка или обработка заказов встала, сайт этого не покажет.
  • Свежесть резервных копий. Отсутствие бэкапа обнаруживается в худший момент, если за ним не следить.

Проверка снаружи и изнутри

Эти два вида мониторинга дополняют друг друга и не заменяют.

Внешний мониторинг обращается к сайту из интернета, желательно из нескольких регионов. Он видит проблемы с DNS, сетью, сертификатами и балансировщиком — всё, что находится между сервером и посетителем.

Внутренний мониторинг собирает метрики на самом сервере: нагрузка, память, диск, число соединений с базой. Он объясняет, почему сайт стал медленным, тогда как внешний лишь фиксирует факт.

Оповещения, которые не начнут игнорировать

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

Несколько правил, которые помогают:

  • Уведомлять после нескольких неудачных проверок подряд. Единичный таймаут — обычно сетевая помеха, а не авария.
  • Разделять уровни. Сайт недоступен — звонок в любое время суток. Диск заполнен на 80% — сообщение в рабочий чат.
  • Группировать связанные события. Падение сервера не должно порождать сорок отдельных уведомлений по каждой проверке.
  • Уведомлять о восстановлении. Иначе непонятно, продолжается инцидент или уже закончился.
  • Убирать проверки, на которые никто не реагирует. Если на алерт полгода никто не отвечает, он либо не нужен, либо неправильно настроен.

С чего начать

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

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

← Вернуться к статьям