Монитор получил тайм-аут, а у администратора страница открылась. Из этого сочетания возможны как минимум три вывода: маршрут точки проверки кратко оборвался, сайт недоступен части аудитории или условие успеха устарело. Для классификации нужны данные двух запросов в один и тот же период.
Классифицируйте событие до настройки порогов
Сначала выпишите, что именно монитор посчитал ошибкой: DNS timeout, невозможность соединения, сбой TLS, HTTP-статус, отсутствие текста или превышение времени ответа. Добавьте URL, время, точку, число попыток и сырой ответ. Формулировка «сайт упал» стирает главное различие между слоями.
Используйте таблицу как начальный навигатор:
| Наблюдение | Предварительная классификация | Следующая проверка |
|---|---|---|
| Одна точка ошиблась, две другие сразу успешны | Возможен сбой маршрута или самой точки | IP, трасса, история точки |
| IPv4 работает, IPv6 стабильно нет | Частичная реальная недоступность | AAAA и маршрут IPv6 |
| Браузер видит страницу, монитор получает 403 | Различие правил доступа | Ответ и журнал WAF |
| Статус и страница верны, изменился искомый текст | Устаревшее условие | Выбрать устойчивый маркер |
| Несколько точек получают одинаковый 5xx | Серверный инцидент | Прокси, приложение, зависимости |
Ложным можно назвать событие, если проверяемое пользовательское свойство всё время было исправно, а ошибка возникла в самом измерении или его неверном условии. Региональный отказ, поломка IPv6 и блокировка реальной группы клиентов остаются частичными сбоями.
Состав устойчивой проверки и повторов описан в руководстве по uptime-мониторингу.
DNS может привести клиентов к разным адресам
Сотрудник и монитор используют разные резолверы. Из-за TTL, географического DNS, поэтапной миграции или кэша они могут получить разные A и AAAA записи. Сравнивайте результат, сохранённый во время тревоги, с ожидаемым пулом адресов. Проверка через несколько часов уже не восстановит прежний ответ резолвера.
Опубликованная AAAA-запись требует отдельного теста IPv6. Один клиент предпочитает IPv6, другой быстро переходит на IPv4. У владельца сайт откроется, а посетители с рабочим IPv6-маршрутом попадут на неисправный узел. Удалять такую тревогу как шум опасно.
CDN закономерно направляет регионы на разные edge-серверы. Ошибка одного узла имеет ограниченный масштаб, однако затрагивает настоящих пользователей этого пути. Для подтверждения сравните несколько точек, полученные IP и заголовки, позволяющие определить edge.
Запишите в событии четыре значения: резолвер, A, AAAA и адрес, к которому клиент подключился фактически. Они часто объясняют расхождение ещё до просмотра приложения.
Сеть и TLS различаются у клиентов
Общий текст timeout может означать задержку DNS, TCP-соединения, TLS-рукопожатия, первого байта или всего ответа. Если монитор показывает этапы, сравните каждый с обычной историей. Если показывает только итог, повторите диагностический запрос инструментом, который разделяет времена.
Слишком короткий предел реагирует на нормальный холодный кэш и редкие сетевые задержки. Слишком длинный увеличивает время обнаружения деградации. Порог выбирают по распределению обычных значений и допустимой задержке для пользователей. Самый быстрый запуск для этого не подходит.
Клиенты TLS отличаются набором доверенных центров, версиями протокола, SNI и способностью достраивать промежуточную цепочку. Браузер иногда использует сертификат из кэша, а чистый агент показывает неполную цепь сервера. Это указывает на совместимость с частью клиентов. Сравните выданный сертификат, имя хоста и конкретный узел; практические команды есть в статье про ошибки SSL-сертификатов.
Отключение проверки сертификата допустимо как короткий диагностический эксперимент. В постоянной проверке оно скрывает пользовательскую ошибку TLS.
WAF видит у монитора другого посетителя
IP дата-центра, частота запросов, отсутствие cookie и User-Agent могут включить правила защиты. Монитор получит 403, 429 или страницу проверки браузера, а сотрудник с домашнего адреса — обычный ответ. Откройте журнал WAF за точное время и сопоставьте идентификатор события, правило и действие.
Если проверяющая система должна иметь технический доступ, используйте ограниченный и проверяемый способ: известный IP, подписанный запрос или отдельный безопасный endpoint. Разрешение для любого запроса с определённым User-Agent легко подделать и создаёт дыру в защите.
Суммируйте частоту всех систем наблюдения. Несколько агентов, работающих независимо, способны превысить общий rate limit. При этом полное исключение внешнего пути из WAF лишит проверку способности увидеть те же ограничения, которые получают пользователи. Обычно нужны два сигнала: внутренний health check для компонента и внешний запрос через публичную защиту.
HTTP-успех зависит от ожидаемого поведения
Браузер автоматически проходит редиректы. Монитор может остановиться на первом 301 либо дойти до страницы входа с кодом 200. Сохраните каждый шаг, конечный домен и статус. Справочник по значениям ответов доступен в руководстве по HTTP-статусам.
Определение успеха запишите для конкретного URL. Примеры:
- старый HTTP-адрес должен одним переходом вести на основной HTTPS-домен;
- публичная карточка должна вернуть 200 и код тестового товара;
- закрытая страница кабинета должна перенаправить на согласованный вход;
- API здоровья должен вернуть 200 и поле с ожидаемым состоянием.
Контрольная строка ломается при редакторской правке, локализации и A/B-тесте. Выбирайте элемент, который меняется вместе с функцией: технический атрибут, название стабильного тестового объекта или заголовок раздела. Динамическая цена и рекламный слоган дадут лишние сообщения.
Простой HTTP-агент читает исходный ответ и не выполняет JavaScript. Для элемента, который появляется только в браузере, потребуется синтетический браузерный тест или серверный признак. Полная контрольная сумма HTML редко подходит динамической странице.
Настройте подтверждение по типу сбоя
Повтор должен отвечать на конкретный вопрос. Второй запрос той же точки через 20 секунд отсеивает короткую потерю пакетов. Запрос из другого региона оценивает масштаб. Отдельные IPv4 и IPv6 проверки выявляют различие протоколов. Ожидание текста отличает рабочую страницу от заглушки.
Не применяйте одну схему ко всем ошибкам. Для полного отсутствия TCP два быстрых подтверждения могут быть достаточны. Пограничное время ответа полезнее оценивать по окну и проценту медленных запросов. Изменение редакционного текста сначала сверяют с журналом публикаций.
После расследования меняйте минимальную часть условия: тайм-аут, число попыток, маркер или ожидаемый переход. Проверьте новое правило на нормальном ответе и на контролируемой ошибке. Простое увеличение всех порогов уменьшит количество сообщений вместе с чувствительностью.
Учтите маршрут конкретного монитора
Uptime Monitor reChecker при сетевой неудаче повторяет запрос с принудительным IPv4. Поэтому сломанный IPv6 может не стать алертом; отдельные времена DNS, TCP и TLS сервис тоже не показывает. Запишите эту особенность рядом с событием и проверяйте IPv6 и доверие сертификату независимыми средствами.
В карточке события отделите четыре вещи: сохранённый сигнал, пользовательский эффект, установленную причину и правку конфигурации. Если ошибка исчезла до повторов, оставьте статус «причина не установлена» и данные для сравнения. Через месяц сгруппируйте события по этим статусам: повторяющийся маршрут или устаревающий маркер станет виден без повышения всех порогов.