UptimeBot: краулер сервиса Uptime.com для synthetic monitoring — стоит ли блокировать

UptimeBot — один из немногих ботов, чьё происхождение легко проверяется по одной детали в самой строке User-Agent: полная версия содержит прямую ссылку на сайт оператора — Mozilla/5.0 (compatible; Uptimebot/1.0; +http://www.uptime.com/uptimebot). Это бот сервиса синтетического мониторинга Uptime.com (юрлицо — Uptime, LLC), который клиенты используют, чтобы узнавать о падении сайта раньше, чем это заметят реальные посетители.

Как устроен синтетический мониторинг

Synthetic monitoring — это подход, при котором вместо ожидания жалоб от живых пользователей система сама имитирует обращение к сайту через равные интервалы (обычно раз в минуту или несколько минут) и фиксирует, ответил ли сервер, с какой задержкой и с каким кодом статуса. DevOps- и SRE-команды используют такие сервисы, чтобы обнаруживать простои и деградацию производительности до того, как это скажется на конверсии или репутации, и получать алерты в Slack, email или на пейджер дежурного инженера. UptimeBot — рабочий инструмент именно этого цикла: он методично, но экономно опрашивает целевую страницу, обычно одну и ту же, заданную клиентом сервиса при настройке монитора.

Параметры бота

Использование HEAD вместо GET — важная деталь: технически это означает, что бот не нагружает сервер отдачей полного HTML при каждой проверке, а лишь спрашивает «жив ли сервер и что он отвечает», что заметно снижает реальную стоимость такого мониторинга по сравнению с полноценным обходом страницы.

Опасен ли этот бот

Сам по себе UptimeBot не представляет угрозы: не пытается получить доступ к закрытым разделам, не собирает контент для чужих датасетов и не участвует в поисковой индексации. Единственная реальная проблема — не техническая, а организационная: если сайт мониторит несколько разных сервисов (например, свой корпоративный + сторонний, который используют партнёры или инвесторы для отслеживания доступности), суммарная частота обращений может быть выше, чем нужно, и засорять логи при разборе реального трафика. Но по объёму нагрузки на сервер этот тип бота — один из самых лёгких среди всех, что попадают в логи: как правило, это единичный HEAD-запрос к одной странице раз в несколько минут, а не системный обход.

Как найти бота в логах

# Базовый поиск
grep -i "uptimebot" /var/log/nginx/access.log

# Какую именно страницу проверяет бот
grep -i "uptimebot" /var/log/nginx/access.log | awk '{print $7}' | sort | uniq -c | sort -rn | head

# Интервалы обращений в течение суток
grep -i "uptimebot" /var/log/nginx/access.log | awk '{print $4}' | cut -d: -f1 | sort | uniq -c

Регулярность обращений — сама по себе диагностический признак: если интервалы между запросами стабильны (например, строго раз в минуту), это соответствует ожидаемому поведению synthetic-мониторинга; хаотичная частота с того же UA — повод присмотреться к возможной подмене идентификатора.

Стоит ли блокировать

Прежде чем банить бота по умолчанию, стоит выяснить, чей это монитор:

• если мониторинг настроен командой сайта — это тот самый health-check, ради которого сервис и был подключен; блокировка лишит команду раннего предупреждения о простое;
• если мониторинг настроил кто-то посторонний (партнёр, инвестор, бывший подрядчик с забытым доступом) — обращения безвредны, но и пользы владельцу сайта не приносят; блокировка ничего не портит;
• на позиции в поисковой выдаче Google, Bing или Яндекса присутствие или отсутствие UptimeBot не влияет.

Как настроить доступ

Если это ваш собственный мониторинг — лучше не блокировать бота вслепую, а добавить IP или User-Agent в allowlist, чтобы health-check продолжал получать честный ответ сервера:

User-agent: Uptimebot
Allow: /

Если мониторинг чужой и нежелателен — стандартный запрет в robots.txt с дублированием на сервере:

User-agent: Uptimebot
Disallow: /

if ($http_user_agent ~* "uptimebot") {
    return 403;
}

Важная оговорка для этого конкретного бота: по наблюдениям из открытых источников, UptimeBot в принципе может не запрашивать robots.txt перед проверкой — поэтому для гарантированного результата стоит сразу рассчитывать на серверное правило, а не только на файл политики.