Мониторинг сайта: доступность, скорость и безопасность под контролем

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

Главная страница падает редко. Чаще ломаются отдельные узлы — оплата, форма, интеграция с CRM, — а сервер при этом отвечает кодом 200. Поэтому проверять нужно не факт ответа, а то, что сайт выполняет свою работу.

Многие полагались на бесплатный мониторинг в Яндекс Метрике, но 3 сентября 2024 года Метрика приостановила доступ к мониторингу сайта: уведомления о доступности по SMS и почте больше не приходят, а сама Метрика советует следить за трафиком в отчётах или пользоваться сторонними инструментами.

Что мониторить на сайте: сводная таблица

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

Мониторинг доступности сайта: код ответа, ключевое слово, регионы

Базовая проверка — внешний сервис раз в 1–5 минут запрашивает страницу и смотрит код ответа. Коды 2xx — норма, 5xx — сбой сервера или приложения, 4xx на важной странице — поломка после релиза. Но одного кода мало, поэтому добавляют ещё три условия.

• Ключевое слово. Сервис ищет в ответе текст, который есть только на рабочей странице: название компании в подвале, кнопку «В корзину». Так ловится «белый экран» и заглушка хостинга, которые отдают код 200.
• Несколько страниц. Главная, карточка товара, корзина, форма, личный кабинет — каждая ломается по-своему.
• Несколько регионов. Сайт может открываться из Европы и не открываться из России — из-за провайдера, гео-фильтров или блокировки IP. Если клиенты в России, часть проверок должна идти из российских точек. Сбой подтверждается, когда его видят две локации и больше — это отсекает ложные тревоги.

Время ответа сервера

Сервис аптайма заодно замеряет, за сколько сервер отвечает. Разовый скачок не страшен, а вот рост за неделю с 0,3 до 1,5 секунды — сигнал разобраться до того, как сайт ляжет в пик. Порог алерта задают от своей нормы: например, ответ дольше 3 секунд три проверки подряд. Что делать с медленным сайтом — в статье о скорости загрузки сайта.

Домен, SSL и DNS: сроки, которые не прощают забывчивости

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

• SSL-сертификат. Проверяют срок действия и полноту цепочки: сайт с неполной цепочкой открывается в одном браузере и ругается в другом. Сроки сокращаются: Let's Encrypt выдаёт сертификаты на 90 дней, платные с 15 марта 2026 года действуют не больше 200 дней за выпуск, а Let's Encrypt с июня 2025 года не присылает писем об окончании срока. Автопродление обязательно, а мониторинг нужен, чтобы заметить, когда оно тихо сломалось. Подробности — в статье что такое SSL-сертификат.
• Домен. Алерт за 30 дней до окончания регистрации плюс автопродление у регистратора с актуальной картой или балансом. Проверьте, что домен оформлен на компанию, а не на бывшего подрядчика.
• DNS. Отвечают ли NS-серверы и не изменились ли A- и MX-записи. Неожиданная смена IP в A-записи — повод немедленно проверить доступы к регистратору: так выглядит угон домена.

Сервер и приложение: ресурсы, логи, ошибки

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

Ресурсы сервера

Минимум: процессор, память, место на диске, процессы веб-сервера и базы, очередь фоновых задач. Самый частый сбой — закончилось место: база не пишет заказы, бэкап не создаётся уже неделю. Пороги ставят с запасом: 80% — предупреждение, 90% — авария.

Ошибки приложения

Логи веб-сервера показывают всплески 500-х и 404-х ошибок, а Sentry (облачный или на своём сервере) и совместимый с ним GlitchTip собирают исключения из кода со стеком вызовов. Алерт настраивают не на каждую ошибку, а на новый тип или резкий рост частоты — иначе через неделю уведомления перестанут читать.

Бизнес-проверки: заявки, бэкапы и SEO-сигналы

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

Формы и заявки: синтетические проверки

Синтетическая проверка — скрипт, который по расписанию отправляет тестовую заявку и проверяет, что она появилась в CRM с пометкой «тест»; не дошла за 10–15 минут — алерт. Для оплаты — тестовый платёж в песочнице или проверка, что открывается страница платёжного сервиса. Проще — heartbeat: сайт или CRM сами отправляют сигнал в систему мониторинга после каждой успешной заявки, и если сигнала нет дольше обычного (скажем, 4 часа в рабочее время), это повод проверить.

Бэкапы

Мониторинг бэкапов — это три проверки: копия создана по расписанию, её размер не упал в разы (пустой архив — частая поломка) и из неё можно восстановиться. Первые две автоматизируются heartbeat-сигналом от скрипта резервного копирования. Третья — регламент: раз в квартал разворачиваем копию на тестовом стенде и открываем сайт.

SEO-сигналы

После релиза на сайт нередко попадает robots.txt с Disallow: / или noindex со стенда. Проверяйте robots.txt после каждого деплоя и включите в Яндекс Вебмастере мониторинг важных страниц и уведомления о критичных ошибках диагностики: Вебмастер сообщит, если страницы выпадут из поиска или робот не сможет получить к ним доступ.

Мониторинг безопасности сайта: что отслеживать

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

• Изменение файлов. Контроль целостности сравнивает файлы сайта с эталоном и сообщает о новых и изменённых. В 1С-Битрикс для этого есть встроенный контроль целостности в модуле проактивной защиты, на остальных CMS — скрипты сравнения контрольных сумм или git-репозиторий на сервере: любой файл вне коммита — повод разобраться.
• Вирусы и вредоносный код. Регулярное сканирование сервера и внешние проверки — подробно в статье о проверке сайта на вирусы.
• Яндекс Вебмастер, раздел «Безопасность и нарушения». Яндекс выборочно проверяет проиндексированные страницы и показывает там заражение и вредоносный код, а ошибки сертификата — в разделе «Диагностика». Включите уведомления на почту, которую читают.
• Журнал WAF и входы в админку. Резкий рост заблокированных запросов, перебор паролей, вход администратора из новой страны или ночью. Алертом стоит сделать появление нового администратора — это частый след взлома.
• Обновления и уязвимости. Отслеживайте версии CMS, модулей и зависимостей и публикации об уязвимостях в них. Для Битрикса есть официальный сканер безопасности, для проектов на npm и Composer — команды аудита зависимостей в CI.

Всплеск трафика и времени ответа может означать атаку — как отличить её от падения хостинга, разобрано в материалах о защите от DDoS и WAF.

Инструменты мониторинга сайта в 2026 году

Обычно сочетают внешний мониторинг аптайма и внутренний мониторинг сервера. Функции и тарифы меняются — перед подключением проверьте их на сайте сервиса.

Оповещения, эскалация и дежурства

Алерт должен дойти до человека, который может что-то сделать, в любое время, когда сайт приносит деньги.

Каналы оповещений

• Мессенджеры. Самый быстрый канал. С февраля 2026 года Роскомнадзор замедляет Telegram в России: сообщения могут задерживаться, а сервер мониторинга в РФ — не достучаться до API мессенджера, поэтому Telegram не должен быть единственным каналом. Для Max нужен бот, зарегистрированный на платформе Max для партнёров (юрлицо, ИП или самозанятый), и небольшой обработчик, который принимает webhook от мониторинга и отправляет сообщение через API Max, — если сервис не поддерживает Max напрямую.
• Почта — для некритичных событий и отчётов. Добавьте адрес сервиса в контакты, иначе алерты уйдут в спам.
• SMS и звонок — для аварий ночью и в выходные: мессенджер на беззвучном не разбудит дежурного, звонок разбудит.

Эскалация и приоритеты

Разделите события по важности: сайт недоступен или не принимает заявки — авария, сертификат истекает через 20 дней — плановая задача. Для аварии нужна цепочка эскалации: алерт получил дежурный; если он не подтвердил его за 10–15 минут, оповещение уходит следующему по списку, затем техническому директору. Назначьте дежурства и держите под рукой короткую инструкцию: где смотреть логи, как откатить релиз, куда звонить в хостинг. Если сайт уже упал, а разбираться некому, пригодится наш план действий на первый час после сбоя.

Своими силами или подрядчик

Бесплатный сервис аптайма владелец подключит сам за 15 минут. Мониторинг сервера, бэкапов, синтетические проверки заявок и дежурства требуют администратора. Обычно это делают при настройке сервера и инфраструктуры — у нас настройка мониторинга стоит от 25 000 ₽, итог зависит от числа серверов и проверок. Реакцию на алерты круглосуточно закрывает техническая поддержка сайта по SLA: разовые работы по постоплате считаются от 2 500 ₽ в час. Если мониторинг ведёт подрядчик, у заказчика должен оставаться собственный доступ к данным аптайма — это основа для контроля выполнения соглашения об уровне сервиса.

Типичные ошибки при настройке мониторинга

• Мониторят только главную. Главная закеширована и открывается, а корзина, форма и личный кабинет не работают.
• Алерты уходят в спам или на ящик уволенного сотрудника. Раз в квартал устраивайте учебную тревогу: остановите тестовую страницу и проверьте, кто и через сколько минут отреагировал.
• Слишком много шума. Алерт на каждую 404-ю ошибку и каждый скачок процессора — и через неделю все уведомления отключены. Настройте повторную проверку и пороги.
• Не проверяют бэкапы и заявки. Сайт доступен на 100%, а лиды неделю не доходят до CRM из-за сменившегося ключа API.

Чек-лист: мониторинг сайта настроен правильно

• Внешний мониторинг доступности с интервалом 1–5 минут и проверкой ключевого слова
• Проверяются главная, корзина или форма заявки, оплата и личный кабинет
• Часть проверок идёт из России, сбой подтверждается из двух и более точек
• Отслеживаются сроки SSL (с цепочкой) и домена, DNS-записи
• Настроены алерты на CPU, память и диск, включая место под бэкапы
• Ошибки приложения собираются в Sentry, GlitchTip или аналог, алерт на всплеск
• Синтетическая тестовая заявка регулярно доходит до CRM
• Бэкапы подтверждаются heartbeat-сигналом, восстановление проверяется раз в квартал
• Включены контроль целостности файлов, уведомления Вебмастера, отслеживаются уязвимости CMS
• robots.txt проверяется после каждого релиза
• Минимум два канала оповещений, для аварий — SMS или звонок
• Назначены дежурные и цепочка эскалации, есть инструкция на случай сбоя
• Заказчик имеет собственный доступ к мониторингу и отчётам об аптайме