Главная страница открывается, а форма уже не отправляет заявки. Сервер отвечает, но клиент не может завершить заказ. Мониторинг сайта нужен, чтобы обнаруживать такие отказы и доводить сигнал до человека, который может восстановить работу. Команда Гуси-Лебеди объясняет, что проверять, как выбирать пороги и как убедиться, что сама система наблюдения работает.
Что такое мониторинг сайта и почему HTTP 200 недостаточно
Мониторинг сайта регулярно проверяет состояние ресурса и важных процессов. Его задача состоит в обнаружении проблем, сборе данных для диагностики и уведомлении ответственных. Набор графиков полезен только тогда, когда по нему можно понять, какое действие клиента нарушено и что проверить сначала.
Ответ HTTP 200 подтверждает успешный ответ на конкретный запрос, но не всю работу сайта. Внутри может оказаться заглушка, пустая оболочка приложения или сообщение об ошибке. Главная может открываться из кэша, пока обработчик формы недоступен. Поэтому задайте ожидаемый результат каждой проверки.
Для страницы услуги это может быть нужный заголовок и содержательный элемент. Для поиска осмысленный результат контрольного запроса. Для формы подтверждённое получение обращения, а не только надпись «Спасибо». Успешный ping тоже не подтверждает работу HTTPS, интерфейса или CRM.
Разделяйте симптом и причину. «Заявка не дошла до менеджера» описывает нарушение процесса. «Истёк токен» может оказаться его причиной, но это нужно проверить. Не превращайте первое предположение в заключение об инциденте.
Какие сценарии и зависимости включить в проверки
Начните с действий, отказ которых мешает посетителю и бизнесу: открыть предложение, выбрать товар, отправить обращение, войти в кабинет, получить документ. Опишите начало сценария, ожидаемый результат и зависимости. Проверка всех URL без понимания этих путей не гарантирует покрытие важных функций.
| Сценарий | Подтверждение успеха | Что может пропустить простая проверка |
|---|---|---|
| Открыть услугу | Нужная страница и содержание | Заглушку с успешным HTTP-кодом |
| Выбрать вариант | Выбор сохраняется до формы | Ошибка клиентского JavaScript |
| Отправить обращение | Запись принята с контрольным ID | Ложное сообщение об отправке |
| Передать в CRM | Заявка найдена в нужном состоянии | Зависшая очередь или ошибка доступа |
| Сформировать выгрузку | Результат создан и доставлен | Запуск задания без завершения |
Проверяйте DNS и сертификат на фактическом публичном адресе. Обновлённый файл на сервере ещё не подтверждает, что его использует внешний узел. Для домена контролируйте срок регистрации и результат продления, для фоновых задач время последнего успешного завершения.
С резервной копией важен отдельный вопрос: можно ли восстановить систему. Наличие архива не подтверждает полноту и работоспособность восстановления. Такие проверки проводят по согласованному регламенту и в безопасной среде.
В настройку мониторинга и контроля сайта включайте зависимости важного сценария. Для доставки заявки полезна проверка цепочки, описанной в статье об API-интеграции: сайт, сохранение, очередь и принимающая система.
Как сочетать внешние проверки и метрики приложения
Внешняя проверка обращается к сайту с отдельной точки и наблюдает поведение снаружи. Внутренние метрики показывают ошибки приложения, ресурсы, очередь и зависимости. Измерения реальных пользователей помогают обнаружить проблемы устройств и сетей, но зависят от посещений и настроенного сбора данных.
Эти способы дополняют друг друга. Серверные показатели могут не заметить сломанный клиентский скрипт. Одна внешняя точка может пропустить региональную проблему. Браузерный сценарий воспроизводим, но не охватывает все сочетания устройств, браузеров и пользовательских действий.
В руководстве Google SRE выделены задержки, нагрузка, ошибки и насыщение ресурсов. Для сайта свяжите эти группы с конкретным действием: задержка отправки формы, ошибки создания заявки, возраст очереди. Не ограничивайтесь состоянием машины.
Интервал выбирайте по допустимому времени обнаружения, нагрузке и стоимости проверки. Простую HTTP-проверку можно выполнять иначе, чем полный браузерный путь. Универсальное обещание «обнаружим любой сбой за минуту» без условий и измерения не заменяет настройки.
Контрольные заявки должны быть узнаваемыми и отделяться от реальных обращений. Заранее согласуйте их обработку и очистку. Мониторинг не должен создавать настоящие заказы, платежи и поток сообщений менеджерам только ради проверки.
Как измерять доступность и скорость без самообмана
Сначала договоритесь, что считается успешным результатом, за какой период ведётся расчёт и какие наблюдения включены. Можно считать долю успешных проверок или долю времени доступности. Это разные показатели, особенно при неодинаковых интервалах и пропусках данных.
Учебный пример: из 1000 одинаково определённых проверок 995 успешны. Доля успешных проверок равна 99,5%. Это не автоматически точная доля времени доступности: короткий сбой между запусками мог остаться незамеченным. Пример иллюстрирует расчёт, а не задаёт норматив проекта.
Доступность формы и доступность главной страницы показывайте раздельно. Для окна обслуживания задайте явное правило учёта. Если проверяющий узел сам не работал, отсутствие наблюдений не следует превращать в подтверждённый успех сайта.
| Показатель | Что объясняет | Ограничение |
|---|---|---|
| Доля успешных проверок | Результат определённого сценария | Не видит отказы между запусками |
| Задержка ответа | Время конкретного этапа | Не равна готовности всей страницы |
| Доля ошибок | Частоту определённых отказов | Зависит от определения ошибки |
| Возраст очереди | Ожидание фоновой обработки | Нужна проверка завершённого результата |
Среднее время может скрывать медленные ответы. Смотрите распределение и выбранные перцентили вместе с количеством наблюдений. На малой выборке высокий перцентиль нестабилен. Быстрые ошибки учитывайте отдельно: они способны улучшить среднее время, пока полезность сайта ухудшается.
Разделяйте серверный отклик, загрузку страницы и готовность интерфейса. Для оценки пользовательской производительности пригодится отдельный материал о Core Web Vitals. Порог должен относиться к определённому измерению и соответствовать требованиям вашего сценария.
Как настроить уведомления и реакцию на сбой
У каждого критичного сигнала нужен владелец, канал доставки и понятный первый шаг. Сообщение «сайт упал» слишком общее. Полезнее указать сценарий, наблюдаемый симптом, время с часовым поясом, контрольный ID, последнюю успешную проверку и ссылку на диагностические данные.
Отдельно задайте подтверждение инцидента и восстановления. Реакция на каждый единичный сбой создаёт шум, а слишком длинное ожидание может скрыть нестабильность. Проверьте, как правило ведёт себя при чередовании успешных и неудачных запусков.
Связанные сообщения группируйте, чтобы один отказ не превращался в десятки уведомлений. В документации Prometheus по оповещениям описана роль Alertmanager в обработке и маршрутизации сигналов. Конкретные правила выбирайте под команду и зависимости сайта.
Учебное уведомление может говорить: «Обращение принято сайтом, не найдено в CRM. Контрольный ID сохранён. Проверьте очередь передачи и ответ CRM». Это пример формулировки, а не сообщение о реальном сбое. Причину добавляйте после подтверждения.
Если ответственный не подтвердил получение, предусмотрите резервный маршрут. Проверка, которая заметила отказ, но не довела сообщение до исполнителя, ещё не обеспечивает реакцию. Дешёвое увеличение частоты запросов не исправит потерю уведомлений.
Как выбрать инструмент и проверить сам мониторинг
Сравнивайте сервисы по нужным функциям: проверка содержимого, браузерные шаги, API, регионы, DNS и TLS, история ответов, роли и каналы уведомлений. Тарифы и ограничения проверяйте на действующих страницах выбранного инструмента. Старый обзор не подтверждает текущий бесплатный интервал или доступность функции.
Веб-сценарии могут состоять из нескольких шагов. Такой подход описан, например, в документации Zabbix по веб-мониторингу. Подтверждайте возможности на своём процессе, а не только по списку функций.
Для рекламы отдельно проверьте мониторинг сайта в Яндекс Директе. По документации он проверяет главную страницу и может приостанавливать показы при недоступности. Это полезная дополнительная защита бюджета, но такая проверка не подтверждает отправку формы и получение заявки в CRM.
- Запишите сценарии и критерии успеха.
- Настройте проверки и видимые состояния ошибок.
- В согласованной среде воспроизведите безопасный контрольный отказ.
- Проверьте доставку сообщения и реакцию ответственного.
- Восстановите сценарий и подтвердите результат для пользователя.
- Убедитесь, что сигнал закрывается по принятому правилу.
Отдельно проверьте прекращение работы самого проверяющего процесса. Если он остановился, зелёный статус последнего запуска не должен бесконечно выглядеть актуальным. Показывайте свежесть данных и время последнего наблюдения.
После инцидента измеряйте отдельно время обнаружения, реакции и восстановления. Эти интервалы помогают понять, что менять: покрытие, доставку сообщения или процесс исправления. Приёмка завершена, когда путь от отказа до восстановленного пользовательского действия проверен, а у команды есть понятная инструкция дальнейшей работы.