Почему alert о доступности срабатывает при работающем сайте

Может ли alert о доступности быть “истинным”, даже если главная страница загружается?

Да. Если в браузерной вкладке открывается главная страница, это не доказывает, что проверяемая конечная точка прошла проверку Astrina. И именно это нужно понять в первую очередь, когда вы спрашиваете, почему срабатывает alert о доступности если сайт открывается. Человек может открыть маркетинговую страницу, увидеть логотип и решить, что всё в порядке. Astrina же может проверять /status, /login или JSON-ответ, а не главную страницу.

Это различие важно. Главная страница может загрузиться из кэша, а реальная конечная точка при этом будет тайм-аутиться на сервере. Сайт также может отдавать 200 для оболочки страницы, но всё равно проваливать правило по содержимому, если не хватает нужной строки. Маленькая деталь, большие последствия.

Думайте об этом как о двух разных вопросах. Первый: “что-то вообще видно?” Второй: “конкретная проверка прошла?” Это не одно и то же.

Вот простой пример из трёх частей: пользователь открывает https://example.com, монитор проверяет https://example.com/api/health, а API в течение 90 секунд возвращает 500. Посетители могут ничего не заметить, если страница закэширована, но Astrina справедливо поднимает alert, потому что проверяемая конечная точка сломана. Это не противоречие; в этом и смысл мониторинга сайта показывает сбой а главная страница работает.

Какая именно часть проверки на самом деле не проходит?

Самый быстрый способ прочитать alert о доступности — определить, на каком уровне произошёл сбой. DNS, TCP, TLS, HTTP, редиректы и проверки тела ответа ломаются по разным причинам, и у каждого уровня свой след. Если пропустить этот шаг, легко начать винить “сайт”, когда сбойнулся только один слой. Если вы не уверены, как понять какая часть проверки упала DNS TCP TLS HTTP, смотрите на конкретный этап, где оборвалась цепочка.

Сбой DNS означает, что проверка не смогла найти хост. Сбой TCP означает, что хост найден, но соединение не открылось. Сбой TLS или SSL означает, что сертификат, имя хоста или рукопожатие не удовлетворили проверку. Сбой HTTP означает, что сервер ответил, но с неправильным статус-кодом. Сбой редиректа означает, что цепочка ушла не туда или превысила лимит. Сбой сопоставления содержимого означает, что страница загрузилась, но в теле не оказалось ожидаемого текста.

Эти категории конкретны, а не декоративны. Редирект 301 на страницу входа может выглядеть для человека как “сайт работает”, но монитор может считать его ошибкой, если ожидает 200 по исходному пути. Сертификат, истекающий через 2 дня, может уже вызывать предупреждения в одних браузерах и не вызывать в других, а Astrina уже может отметить состояние TLS. Вот такого рода различия и превращаются в сбивающий с толку alert в 09:17.

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

Почему пользователи и мониторы могут одновременно видеть разные результаты?

Пользователи и мониторы смотрят на веб не из одного и того же места. Браузер может пользоваться локальным кэшем, активной сессией или быстрым CDN-узлом рядом с посетителем. Проверка Astrina может попасть в другой регион, на другой IP-маршрут или сделать “холодный” запрос без какого-либо состояния браузера.

Эта разница многое объясняет. Один посетитель в Лондоне загружает сайт за 1 секунду. Другая проверка в другом месте видит тайм-аут через 5 секунд, потому что транзитный маршрут перегружен. Оба отчёта могут быть правдивыми одновременно.

Поведение CDN — частая причина. Если edge отдаёт главную страницу, но не отдаёт вложенный ресурс, страница может всё равно выглядеть “нормально” невооружённым глазом. Закэшированная оболочка способна скрывать поломанный origin. Монитор же может проверять origin напрямую или маршрут, который CDN не кэширует надолго.

Географические различия тоже имеют значение. Файрвол может разрешать трафик с IP вашего офиса и блокировать диапазон IP проверки. Проблема маршрутизации может затронуть один континент на 12 минут и не задеть остальные. Такой разный взгляд на ситуацию раздражает, но он реален. Никакие общие слова не меняют маршрут пакета.

Иногда всё ещё проще: браузер автоматически повторяет запросы, а монитор — нет. Страница, которая наконец загружается после 3 неудачных попыток, всё равно может вызвать alert, если проверка истекла по тайм-ауту на первой попытке. Это не значит, что Astrina “слишком строгая”. Это значит, что сервис балансирует на грани отказа.

Может ли частичный сбой вызвать alert, даже если основной сайт работает?

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

Представьте e-commerce-сайт с 4 слоями: главная страница, API товаров, платёжный шлюз и сервис остатков. Если главная страница закэширована, а API товаров возвращает пустые результаты, посетитель всё ещё может попасть на страницу и увидеть баннер. Astrina может проверить endpoint API и сразу сработать. Сайт “жив” в бытовом смысле, но ключевая функция не работает.

Один сломанный asset тоже может иметь значение. Если монитор проверяет, что герой-изображение или JavaScript-бандл присутствует, отсутствие файла может провалить проверку содержимого, хотя HTML загружается. Одного отсутствующего файла может быть достаточно. Это не драма; это рабочая реальность.

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

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

Какие детали ответа стоит проверить в первую очередь?

Начните с полей, которые показывают, что именно сломалось, а не что вам хотелось бы увидеть. В первую очередь проверьте статус-код, время ответа, совпадение тела, состояние сертификата и цепочку редиректов. Если в alert указано место проверки, посмотрите и его: география может объяснить проблему, зависящую от маршрута.

Читайте эти поля по порядку. 500 — это одна проблема, а 200 с неправильным телом — совсем другая. Тайм-аут — это ещё иная ситуация. Если видите цепочку из 4 переходов, спросите себя, должен ли монитор следовать по всем 4 или лучше наблюдать более простой endpoint. Чем больше переходов, тем больше мест для сбоя.

Местоположение проверки заслуживает отдельного внимания. Результат из Франкфурта может отличаться от результата из Сингапура, если CDN-узел или upstream-маршрут нестабилен. Эта деталь часто объясняет, почему один оператор видит outage, а другой — нет. И тот и другой говорят правду со своей стороны.

Если alert включает заголовки ответа, обратите внимание на связанные с кэшем. Ответ из кэша может какое-то время скрывать поломку origin. Ответ со статусом “stale” или “miss” может показать реальное состояние. Мелкие подсказки важны.

Когда это, скорее всего, ложное срабатывание, а когда — реальная проблема с доступностью?

Ложное срабатывание обычно узкое и воспроизводится одним небольшим способом. Реальная проблема с доступностью обычно затрагивает больше одной проверки или её становится легче воспроизвести. Такое различие экономит время. И оно помогает не “чинить” монитор, когда проблема в самом сервисе.

Сначала ищите нестабильную зависимость. Если alert появляется один раз, исчезает и не возвращается в течение следующих 30 минут, возможно, это был кратковременный upstream-сбой. Если он срабатывает каждые 2 минуты на одной и той же конечной точке, проверка может быть слишком строгой или сервис действительно нестабилен. Паттерны важнее историй.

Слишком строгая проверка часто выглядит так: страница рендерится, но правило по содержимому ожидает точную фразу, которая изменилась в релизе на прошлой неделе. Команда продукта заменила “Sign in” на “Log in”, и монитор начал падать на несовпадении тела ответа. Сайт онлайн. Проверка устарела.

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

Есть и случай “зависит от того, кого спрашиваешь”. Пользователи за корпоративным VPN могут попадать на стабильный маршрут, а проверка — на сломанный. Сначала это может выглядеть как ложное срабатывание, но чаще всего это реальная проблема с доступностью как минимум для одной аудитории. Сайт, который доступен для 80% посетителей, нельзя считать полностью доступным.

Что менять, если сайт “up”, а Astrina всё равно срабатывает?

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

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

Также стоит пересмотреть путь редиректов. 302 на страницу входа может быть приемлем для пользователей, но не для монитора. В таком случае отслеживайте endpoint, который действительно отражает состояние сервиса, а не публичный маршрут. Это вопрос конфигурации, а не философии.

Если проблема во времени ответа, выберите более лёгкий путь. Полная главная страница с 12 assets — плохой индикатор здоровья, если вам нужен всего один быстрый ответ. Более лёгкий endpoint даёт более точный ответ и меньше ложных тревог. Быстрые проверки живут дольше, чем “умные”.

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

И наконец, ещё одна проверка: сравнивайте то, что говорит alert, с точным URL, а не с названием бренда. Если alert срабатывает на /api/health, а главная страница работает, это ожидаемое поведение. Если alert срабатывает именно на главной странице, тогда проблему стоит изучить глубже, потому что главная страница, которая отдаёт страницу, но проваливает проверки содержимого, TLS или маршрутизации, всё равно является реальным инцидентом для Astrina.