Uptimedoctor: сингапурский мониторинг с минутными проверками — не путать с UptimeBot

За именем uptimedoctor стоит конкретная и легко проверяемая компания — сингапурский сервис Uptime Doctor, основанный в 2013 году. В отличие от разобранного ранее UptimeBot (принадлежащего нью-йоркскому Uptime.com), это отдельный, самостоятельный игрок того же рынка synthetic-мониторинга — со своей инфраструктурой точек присутствия на шести континентах и собственной моделью, включающей щедрый бесплатный тариф.

Чем именно занимается Uptime Doctor

Сервис проверяет доступность сайтов с внешних точек по всему миру, работая круглосуточно и без выходных — по заявлению компании, инфраструктура непрерывно следит за первыми признаками проблем на шести континентах. Отличительная черта именно этого провайдера — бесплатный тариф с проверкой раз в минуту для пяти сайтов, что заметно щедрее, чем у многих конкурентов, ограничивающих бесплатный доступ куда более редкими интервалами опроса. Именно поэтому uptimedoctor нередко встречается в логах небольших проектов и личных сайтов — порог входа для владельца минимален.

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

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

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

Технически uptimedoctor безобиден: он не пытается получить доступ к закрытым разделам и не собирает контент — только фиксирует доступность и время ответа заданной точки, обычно главной страницы или health-check эндпоинта. Единственный практический риск — не безопасность, а фоновая нагрузка: при минутном интервале опроса, характерном именно для бесплатного тарифа этого провайдера, суммарный объём запросов за месяц от одного-единственного монитора получается заметно больше, чем у сервисов с более редкой проверкой — что стоит учитывать, если сайт одновременно отслеживают несколько разных инструментов мониторинга.

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

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

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

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

Строго регулярные, минутные интервалы обращений к одному и тому же URL — ожидаемый и легко узнаваемый паттерн именно для этого сервиса; хаотичная частота с того же UA — повод усомниться в подлинности запроса и свериться с ASN IP-адреса через whois.

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

Как и с любым мониторинговым ботом, ключевой вопрос — чей это чекер:

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

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

Если это ваш мониторинг — разрешить явно, чтобы health-check продолжал получать честный ответ сервера:

User-agent: uptimedoctor
Allow: /

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

User-agent: uptimedoctor
Disallow: /

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

Если задача не полностью заблокировать, а лишь снизить частоту минутных проверок при подозрении на чужой лишний мониторинг, промежуточный вариант — rate-limit вместо жёсткого запрета, пока не выяснится, чей это чекер на самом деле:

limit_req_zone $binary_remote_addr zone=uptimedoctor:10m rate=10r/m;
location / {
    if ($http_user_agent ~* "uptimedoctor") {
        limit_req zone=uptimedoctor burst=20 nodelay;
    }
}