Как настроить мониторинг сайта: пошагово

Зачем вообще настраивать мониторинг

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

Мониторинг доступности решает одну простую задачу: вы узнаёте о сбое раньше, чем о нём узнает ваша аудитория. Это не про «красивые графики», а про то, что время от падения до реакции сокращается с часов до минут.

Разберёмся с терминами, чтобы дальше говорить на одном языке. Доступность (uptime) — это доля времени, в течение которой сайт отвечает корректно. Время простоя (downtime) — обратная величина. Если сайт лежал 2 часа в месяц, его доступность составила примерно 99,7 %. Звучит неплохо, но это почти 24 часа простоя в год — за такое время реальный бизнес теряет ощутимые деньги.

Точную математику — сколько простоя «стоит» тот или иной процент аптайма — удобно смотреть на калькуляторе доступности. Он показывает, какую долю времени вы фактически гарантируете клиенту при заданном SLA, и помогает не обещать лишнего в договоре.

Мониторинг нужен не только владельцам интернет-магазинов. Он критичен для:

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

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

Что именно мониторить

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

Доступность (HTTP-проверки)

Базовая проверка: запрос к странице и контроль HTTP-статуса. Главное — проверять не только «сайт отвечает», но и то, что он отвечает правильно. Код 200 — это хорошо, а вот код 500, 502 или 503 — уже авария, даже если страница технически «загрузилась».

Важно следить не только за кодом, но и за временем ответа. Сайт, который отвечает за 20 секунд, формально «доступен», но по факту для пользователя он мёртв. Порог по времени ответа — вторая важная метрика после статуса.

SSL-сертификат

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

Мониторить нужно два параметра: срок действия (чтобы успеть перевыпустить за 2–4 недели) и корректность цепочки сертификатов (бывают ошибки, когда промежуточный сертификат не подгружается).

Домен и DNS

Домен — фундамент, на котором стоит всё остальное. Если домен не продлён, сайт перестаёт резолвиться целиком, причём это может выглядеть как «сайт лежит», хотя хостинг исправен. Отдельно стоит следить за сроком регистрации и за тем, что NS-записи не меняются без вашего ведома (увод домена — реальный вектор атак).

Порты и сервисы

Если сайт работает поверх нестандартных сервисов — отдельное API, SSH-доступ, база данных, SMTP для почты — стоит проверять и их. Сайт может быть доступен, а платёжный шлюз или форма обратной связи — нет.

Резюме: что и зачем проверять

Набор проверок зависит от проекта. Для простого лендинга хватит HTTP + SSL + домен. Для интернет-магазина добавьте ключевые страницы и порт платёжного сервиса. Для SaaS — эндпоинты API.

Подготовка: что решить до настройки

Прежде чем создавать проверки, зафиксируйте три вещи. Это сэкономит время и избавит от ложных алертов.

1. Какие URL проверять

Не ограничивайтесь главной страницей. Составьте список «критичных» адресов:

• главная страница;
• страница товара или услуги (для магазинов);
• корзина и оформление заказа;
• форма обратной связи;
• личный кабинет;
• ключевой API-эндпоинт.

Для динамических страниц указывайте конкретный метод (GET/POST) и, если нужно, проверяйте не только статус, но и наличие ключевой строки в теле ответа — это ловит «белый экран», когда сервер отдаёт 200, но контента нет.

2. Пороги и частота проверок

Частота — это баланс между скоростью обнаружения и нагрузкой на сервер. Проверять раз в 10 секунд имеет смысл только для сверхкритичных сервисов. Для большинства сайтов достаточно интервала 1–5 минут.

Время ответа (response time) — метрика, на которую ставят отдельный порог. Если TTFB стабильно растёт, это ранний признак деградации: сервер перегружается, запросы к базе тормозят. Алерт по времени ответа ловит проблему до того, как сайт упадёт окончательно.

Важная деталь: алерт должен срабатывать не на единичную неудачу, а на серию. Одиночный таймаут может быть случайностью (перезапуск контейнера, миграция). Настраивайте срабатывание после 2–3 неудачных проверок подряд — это отсекает шум.

3. Кто и как получает алерты

Заранее определите, куда приходят уведомления и кто на них реагирует. Если алерт уходит в почтовый ящик, который проверяют раз в день, — мониторинг не работает. Лучшая практика: несколько каналов с разной приоритетностью (мессенджер для срочного, почта для сводок).

Настройка проверок: пошагово

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

Шаг 1. Базовые проверки HTTP

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

• URL — адрес с протоколом, например https://example.com/;
• Тип запроса — GET;
• Ожидаемый статус — 200 (или 301/302, если вы сознательно ждёте редирект);
• Частота — 1–5 минут;
• Порог времени ответа — 2–3 секунды.

Затем продублируйте проверку для каждой критичной страницы из списка, составленного на этапе подготовки.

Шаг 2. Проверка SSL-сертификата

Отдельная проверка, которая следит за сроком действия. Настройте её так, чтобы уведомление приходило за 14–30 дней до истечения — этого хватает, чтобы перевыпустить сертификат без спешки. Для сертификатов Let's Encrypt с автопродлением срок «тревоги» можно сократить, но проверка всё равно нужна: автопродление иногда ломается (недоступность валидационного пути, смена DNS).

Шаг 3. Проверка домена

Контролируйте срок регистрации домена и неизменность NS-записей. Порог — 30 дней до окончания регистрации: перенос и продление у некоторых регистраторов занимают время.

Шаг 4. Проверка портов

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

• 443 и 80 — сам веб-сервер;
• 22 — SSH-доступ для администраторов;
• 3306 — MySQL (если доступен извне);
• 587 — SMTP для отправки почты.

Проверка порта говорит не только о том, что порт «открыт», но и о том, что сервис на нём жив и отвечает.

Шаг 5. Настройка алертов

Привяжите к проверкам каналы уведомлений. Ключевые правила:

• Разделяйте критичное и информационное. Падение главной страницы — срочный алерт. Истечение сертификата через 30 дней — плановое уведомление.
• Дублируйте критичное. Один канал может быть недоступен, поэтому срочные события шлите минимум в два места.
• Настройте «восстановление». Уведомление «сайт снова работает» так же важно, как и «сайт упал»: оно закрывает инцидент и снимает тревогу у команды.

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

Самопроверка без внешних инструментов

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

Проверка HTTP-ответа через curl

curl -I https://example.com/

Разбор вывода построчно:

HTTP/2 200
server: nginx
date: Mon, 15 Sep 2026 09:00:00 GMT
content-type: text/html; charset=UTF-8

• HTTP/2 200 — статус-код. 200 означает «всё в порядке». Любой код из диапазона 5xx (500, 502, 503) — авария на стороне сервера.
• server — какой веб-сервер отдаёт ответ. Полезно при диагностике.
• content-type — что именно отдаётся. Если вместо text/html приходит application/json с ошибкой — что-то сломалось в приложении.

Чтобы увидеть полный цикл запроса с временными метками, используйте флаг -w:

curl -o /dev/null -s -w "status=%{http_code} time_total=%{time_total}s\n" https://example.com/

Вывод:

status=200 time_total=0.487s

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

Проверка SSL-сертификата через openssl

openssl s_client -connect example.com:443 -servername example.com < /dev/null 2>/dev/null | openssl x509 -noout -dates

Вывод:

notBefore=Sep  1 00:00:00 2026 GMT
notAfter=Nov 30 23:59:59 2026 GMT

• notBefore — с какого момента сертификат действителен;
• notAfter — до какого. Именно эту дату и отслеживает проверка SSL-сертификата. Если notAfter уже в прошлом — браузеры блокируют сайт.

Проверка DNS через dig

dig example.com A +short

Вывод:

93.184.216.34

Это IP-адрес, на который резолвится домен. Если команда возвращает пустую строку — домен не резолвится, и сайт «лежит» для всех пользователей независимо от состояния хостинга.

Проверка NS-записей:

dig example.com NS +short

Сравните вывод с теми NS, которые указал ваш регистратор. Расхождение — тревожный признак (возможный увод домена или несогласованная смена DNS).

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

На что смотреть в результатах

Сам факт «алерт пришёл» — это только половина дела. Дальше нужно понять, что именно сломалось. Быстрая локализация экономит часы при разборе инцидента.

Типичные симптомы и их причины

Отдельно стоит обращать внимание на повторяющиеся короткие падения. Если сайт падает на 30 секунд каждые пару часов, а потом «сам восстанавливается» — это не случайность, а симптом: перезапуск контейнера, cron-задача, переполнение памяти. Такие паттерны видны только на истории проверок, единичный взгляд в момент «всё работает» их не покажет.

История и отчётность

История проверок — это не просто лог, а инструмент для разговора с клиентом или руководством. Когда вы показываете график доступности за месяц, вопрос «почему сайт тормозил» превращается из спора в разговор о фактах. Для агентств это ещё и основа отчётности перед заказчиком: цифры аптайма подкрепляют счёт за поддержку.

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

Коротко о главном

Настроенный мониторинг доступности — это не разовое действие, а базовая гигиена проекта. Соберите список критичных страниц, настройте проверки HTTP, SSL, домена и портов, подключите алерты по двум каналам и обязательно протестируйте их срабатывание. Дальше останется только реагировать на сигналы — и разбирать инциденты по истории, а не по жалобам пользователей.

Начать можно с простого: проверьте доступность своего сайта прямо сейчас, чтобы увидеть, что происходит с ним в эту минуту. А если хотите разобраться, что именно означают цифры вроде «99,9 % аптайма» и сколько простоя они допускают, загляните в статью «Что такое uptime и как его считать».