Почему успешный HTTP-код еще не означает рабочий сайт
Многие владельцы считают, что если сайт возвращает код 200, значит все в порядке. На практике это не всегда так. Сервер может успешно отдать страницу, но внутри будет заглушка, ошибка приложения, пустой шаблон или сообщение о временной недоступности. Для пользователя это падение, даже если технически запрос завершился успешно.
Поэтому мониторинг доступности должен смотреть не только на код ответа. Важно проверять содержимое страницы: есть ли на ней ожидаемый текст и нет ли признаков аварии.
Какие скрытые ошибки встречаются чаще всего
Первый тип - дефолтная страница веб-сервера. После сбоя конфигурации пользователь может увидеть стандартную страницу nginx или Apache вместо сайта. Код ответа иногда остается успешным, особенно если заглушка отдается как обычный HTML.
Второй тип - текстовая ошибка внутри приложения. Например, сайт показывает "temporary unavailable", "service unavailable", "database error" или сообщение о технических работах. Для владельца это может быть временный режим, но для клиента это невозможность выполнить целевое действие.
Третий тип - пустая или неполная страница. Шапка загрузилась, а каталог, форма или блок с товарами не отрисовались из-за ошибки API. Код ответа может быть нормальным, но бизнес-функция сайта не работает.
Как работают текстовые проверки
Есть два подхода. Первый - требовать наличие текста, который должен быть на странице. Это может быть название компании, часть заголовка, стабильная фраза из футера или технический маркер вроде `body`, если нужно проверить, что вернулся HTML-документ.
Второй подход - запрещать тексты, которых на рабочей странице быть не должно. Например, типовые сообщения ошибок веб-сервера, фразы о временной недоступности, ошибки базы данных или заглушки прокси. Если такой текст найден, мониторинг считает проверку проблемной.
Лучше использовать оба подхода. Тогда система поймает и исчезновение нужного контента, и появление аварийного сообщения.
Почему важен приоритет пользовательских правил
У разных сайтов разные нормы. На одном сайте слово `error` может быть частью статьи или документации, а на другом оно почти всегда означает проблему. Поэтому универсальные правила должны быть осторожными, а пользовательские настройки - иметь приоритет.
Если владелец явно указал, что конкретный текст должен быть на странице или не должен встречаться, мониторинг должен ориентироваться на это правило. Так проверки становятся точнее и не превращаются в источник ложных тревог.
Пример для владельца сайта
Допустим, на главной странице интернет-магазина всегда есть текст "Каталог товаров". Его можно добавить как обязательный. А фразы "502 Bad Gateway", "Service Temporarily Unavailable", "Apache2 default page" и "nginx error" можно добавить как недопустимые. Если после сбоя прокси начнет отдавать заглушку, мониторинг заметит не только код ответа, но и смысл страницы.
Для сайта услуг можно требовать наличие телефона, email или названия услуги. Для корпоративного сайта - название компании и ключевой заголовок. Главное, чтобы текст был стабильным и не исчезал при обычном обновлении контента.
Как это использовать в Web-Puls
В Web-Puls можно проверять доступность сайта и добавлять правила по тексту страницы. Это помогает поймать ситуации, когда сервер "жив", но посетитель видит не то, что должен. В истории будет видно, когда правило сработало и когда страница восстановилась.
Такая проверка особенно полезна после релизов, смены шаблона, переноса сайта, настройки прокси или CDN. Именно в эти моменты чаще всего возникают ситуации, когда инфраструктура отвечает, но содержимое страницы уже неправильное.
Вывод
Код 200 - это только начало проверки. Пользователю важна не цифра ответа, а рабочая страница. Поэтому надежный мониторинг должен проверять и доступность, и SSL, и содержимое. Текстовые правила помогают увидеть скрытые аварии раньше, чем их заметят клиенты.