Ложные срабатывания мониторинга: почему бывают и как их убрать

Мониторинг показывает ложные сбои, потому что робот видит сайт не так, как ваш посетитель: он приходит с другого IP, из другой сети, без cookie и без браузера, с жёстким таймаутом и одним критерием «код ответа». Любое расхождение между этим взглядом и реальностью превращается в тревогу: пакет потерялся между точкой и хостингом — «сайт упал»; WAF решил, что робот подозрителен, — «сайт упал»; страница отдалась за 16 секунд вместо 15 — «сайт упал». Сайт при этом жив, а вы уже бежите к серверу.

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

Два термина, которые встретятся ниже: «точка» — сервер, с которого выполняется проверка; «ложная тревога» — уведомление о сбое, при котором обычный пользователь сайт открыл бы.

Откуда берутся ложные тревоги

Сводная таблица причин, по которой удобно проходить при разборе очередного «сайт упал, но открывается».

Одна точка и сеть по дороге

Между точкой мониторинга и вашим сервером десяток автономных систем. Потери на любом стыке выглядят для робота как недоступность сайта, хотя из другого города всё открывается. Одна точка не отличает «упал сервер» от «упал канал у провайдера точки», поэтому она не может быть источником уведомлений о простое, только источником данных.

Как проверить: у настоящего сбоя ошибка одинаковая со всех точек и меняется только время ответа. У сетевого — одна точка даёт таймаут, остальные отвечают за обычные 300–400 мс. Быстрая ручная диагностика:

mtr -rwc 50 example.ru

Если потери начинаются не на вашем сервере, а на транзитном хопе и не доходят до последнего, это чужая проблема по пути, а не ваш простой.

Слишком короткий таймаут

Дефолт 10–15 секунд разумен для главной страницы, но не для отчёта, который собирает данные из трёх баз, и не для сайта на слабом хостинге в час пик. Страница отдаётся за 17 секунд, монитор рвёт соединение на 15-й, в логе nginx запрос будет с кодом 499 (клиент ушёл раньше ответа):

203.0.113.10 - - [15/Sep/2026:09:12:41 +0300] "GET /report/monthly HTTP/1.1" 499 0 "-" "notifar.io monitor/1.0 (+https://notifar.io/docs/bot)"

Код 499 в логе рядом с User-Agent робота — почти всегда таймаут монитора, а не сбой. Дальше вопрос уже к производительности страницы, а не к монитору.

Антибот, WAF и Cloudflare

Защита от ботов не отличает робота мониторинга от парсера: нет JS, нет cookie, нестандартный User-Agent, запросы строго по расписанию. Результат — 403 от WAF, 429 от rate-limit или 503 с JS-челленджем. При «управляемом челлендже» Cloudflare код ответа может быть 403 с заголовком cf-mitigated: challenge, а тело — страница «Проверяем ваш браузер», а не ваш сайт.

$ curl -s -o /dev/null -D - -A 'notifar.io monitor/1.0 (+https://notifar.io/docs/bot)' https://example.ru/ | grep -iE '^(HTTP|cf-mitigated|server)'
HTTP/2 403
cf-mitigated: challenge
server: cloudflare

Отдельный случай — гео-фильтры. Сайт для российской аудитории нередко закрыт для всех IP вне РФ, и точки в Европе получают 403 или молчание. Бывает и наоборот: ресурс, недоступный из России, для точек в Москве и Казани будет «лежать» всегда. В обоих случаях тревога отражает не состояние сайта, а политику доступа.

Ложное «всё хорошо» с кодом 200

Обратная ошибка: сайт «упал», а мониторинг молчит. Заглушка хостинга «аккаунт заблокирован», страница «Ведутся технические работы», редирект на форму логина после протухшей сессии, капча — всё это отдаётся с кодом 200. Проверка только по коду считает это нормой, а через неделю выясняется, что робот всё время смотрел на страницу входа. Ложных тревог тут нет, но мониторинг обесценен сильнее: вы уверены, что всё под контролем, и это неправда.

DNS-флаппинг при переезде

При смене IP часть резолверов держит старую A-запись до истечения TTL. Точки мониторинга сидят за разными резолверами, поэтому час-два после переезда половина из них ходит на старый сервер, где уже выключен nginx. Тревоги будут не «все точки», а «две из пяти», и в результатах проверки у точек будет разный IP:

$ dig +short example.ru @77.88.8.8
198.51.100.7
$ dig +short example.ru @1.1.1.1
203.0.113.42

Пока ответы расходятся, разночтения между точками — норма, а не сбой.

HEAD вместо GET и кеш CDN

HEAD экономит трафик, но у него две проблемы: ответ на HEAD по стандарту (RFC 9110) не содержит тела, значит, ключевую фразу проверить нельзя; а многие бэкенды и WAF на HEAD отвечают 405 или 403, хотя GET отдают нормально. Проверять GET надёжнее, а разницу в трафике при интервале 5 минут заметить невозможно.

Кеш CDN, наоборот, может держать ошибку после того, как origin уже починили: если правила разрешают кешировать 5xx, робот ещё несколько минут видит 502 с заголовком age: 240, хотя curl напрямую на IP сервера отдаёт 200. Это не совсем ложная тревога — посетители тоже видят 502, — но её причина не там, где вы ищете.

Как отличить ложную тревогу от настоящей

Три вопроса, которые в большинстве случаев решают дело без захода на сервер.

Одна точка или все? Сбой, который подтвердила одна точка из пяти, — сетевой или гео-случай, пока не доказано обратное. Сбой со всех точек одновременно — почти наверняка настоящий. Если под рукой только уведомление с одной точки, прогоните адрес через проверку доступности с разных точек: расхождение между городами видно сразу.

Какой код и какой текст ошибки? Таймаут — это сеть, перегрузка или тяжёлая страница; 502 — упал бэкенд; 403 с точек только одной страны — гео-фильтр; 429 — rate-limit; SSL handshake failed — сертификат или TLS-настройки, а не доступность.

Где потеряно время? Если монитор отдаёт время по этапам, смотрите, на каком застряло. Вручную это делает curl:

curl -o /dev/null -s -w 'dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total} code=%{http_code}\n' https://example.ru/

Значения накопительные — от старта запроса до конца этапа, поэтому смотрите разницу между соседними: connect − dns — TCP, tls − connect — рукопожатие, ttfb − tls — работа бэкенда, total − ttfb — передача тела.

Первые три этапа чаще всего про сеть и ложные тревоги (кроме случаев, когда виноваты ваши NS или фаервол), четвёртый и пятый — почти всегда ваши.

Как убрать: настройки монитора

Подтверждение с нескольких точек. Схема «2 из N»: сбой открывается, только когда его видят как минимум две точки из выбранных. Одна точка с потерями в сети тогда никого не разбудит, а настоящий простой подтвердится за один интервал. В мониторинге доступности это параметр confirm_locations; три точки с подтверждением от двух — рабочий минимум для сайта, о простое которого хочется узнавать.

Порог по числу ошибок подряд. Две неудачные проверки подряд срезают короткие сетевые всплески; в большинстве сервисов это значение по умолчанию, проверьте, что его не сбросили в единицу. Цена — уведомление приходит на один интервал позже. При интервале в минуту это 60 секунд задержки против нескольких ложных тревог в неделю.

Таймаут под страницу. Посмотрите в истории проверок реальное время ответа за неделю и поставьте таймаут в два-три раза больше 95-го перцентиля. Для главной страницы это обычно 10–15 с, для отчётов и поиска — 30. Отдельно можно завести порог времени ответа: пусть монитор считает страницу «медленной», а не «упавшей», если она отдалась за 8 секунд вместо 2.

Интервал. Минута нужна для платёжной страницы или API, о простое которого узнают клиенты. Для корпоративного сайта достаточно 5 минут: меньше проверок — меньше шансов попасть под rate-limit и поймать одиночный сетевой глюк.

Ключевая фраза вместо кода. Требуйте наличие фразы, которая есть только на рабочей странице: «Корзина», название компании в футере, номер телефона. Страница логина, капча и заглушка хостинга её не содержат, а значит, код 200 их не спасёт. Обратный вариант — фраза, которой быть не должно: «Ошибка базы данных», «Technical works».

Ожидаемые коды для страниц за защитой. Если админка или API за WAF всегда отдают роботу 403 и вас устраивает сам факт ответа, добавьте 403 в список ожидаемых кодов. Тогда монитор будет ловить настоящее: таймаут, 5xx, отказ соединения.

География точек под аудиторию. Сайт, закрытый для не-РФ, проверяйте с российских точек, а европейские не включайте в подтверждение. Ресурс, недоступный из России, — наоборот. Точка, которая по политике доступа всегда получает 403, не добавляет информации, только шум.

Как убрать: на стороне сервера

Белый список IP точек в WAF. Самый надёжный способ подружить мониторинг с защитой — пропускать робота по IP, а не по User-Agent, который любой может подделать. Адреса точек Нотифарио выдаются по запросу, порядок описан на странице о роботе. В nginx с limit_req исключение делается через geo:

geo $monitor_ip {
    default        0;
    203.0.113.10   1;   # точка мониторинга, IP получен по запросу (см. /docs/bot)
    198.51.100.20  1;
}

map $monitor_ip $limit_key {
    0  $binary_remote_addr;
    1  "";                 # пустой ключ — лимит не применяется
}

limit_req_zone $limit_key zone=perip:10m rate=10r/s;

Пустой ключ в limit_req_zone означает, что запрос не учитывается в лимите: это документированное поведение модуля ngx_http_limit_req_module (https://nginx.org/ru/docs/http/ngx_http_limit_req_module.html). В Cloudflare тот же результат даёт правило WAF «Skip» по IP-списку.

Окна обслуживания. Деплой в 03:00, ночной бэкап с остановкой базы, перезагрузка после обновления ядра — всё это известно заранее. Пауза мониторинга на это время убирает «сбои», о которых вы знаете и без него, и не портит статистику uptime.

TTL перед переездом. За сутки до смены IP снизьте TTL A-записи до 300 секунд, после переезда держите старый сервер включённым, пока dig через несколько публичных резолверов не начнёт возвращать новый адрес. Тогда флаппинга не будет ни у точек, ни у посетителей.

Не кешировать 5xx. В nginx-кеше это proxy_cache_valid 200 301 302 10m; без 5xx в списке; для CDN — проверить правило «cache error responses» и выключить его.

Стоимость ложных тревог

У ложной тревоги две цены. Первая — время: пять минут на «открыть сайт, посмотреть логи, убедиться, что всё в порядке». При трёх тревогах в неделю — час в месяц.

Вторая дороже. После десятого «сайт упал», за которым ничего не последовало, уведомления перестают читать. Телеграм-чат с алертами замьючен, SMS воспринимается как спам, звонок сбрасывают. Настоящий простой в этот момент выглядит ровно так же, как предыдущие десять ложных, и его пропускают на час-два. Именно так мониторинг, который «слишком часто врёт», становится хуже отсутствия мониторинга: он создаёт уверенность, что кто-то следит.

Цель — не «поймать всё», а чтобы каждое уведомление было поводом действовать. Больше двух пустых тревог в месяц — повод менять настройки из разделов выше, а не порог терпения.

Коротко

• Ложная тревога — расхождение между тем, как сайт видит робот (другой IP, без браузера, жёсткий таймаут), и тем, как его видит посетитель.
• Главные источники: одна точка проверки и потери в сети, короткий таймаут, WAF и гео-фильтры, rate-limit, редирект на логин с кодом 200, DNS при переезде, плановые работы, HEAD, кеш 5xx на CDN.
• Различать по трём вопросам: одна точка или все, какой код и текст ошибки, на каком этапе (dns, connect, tls, ttfb) потеряно время.
• В мониторе: подтверждение «2 из N», порог в две ошибки подряд, таймаут по реальному 95-му перцентилю, ключевая фраза вместо кода, 403 как норма для страниц за защитой, точки под географию аудитории.
• На сервере: белый список IP точек в WAF и limit_req, окна обслуживания на деплой и бэкап, низкий TTL перед переездом, запрет кеширования 5xx.
• Цена ложных тревог — не пять минут на проверку, а пропущенный настоящий сбой, когда уведомления уже никто не читает.