PRTGCloudBot: облачный сенсор мониторинга Paessler

PRTGCloudBot — один из самых чётко задокументированных ботов в этой энциклопедии: официальная база знаний Paessler AG (компания с более чем 500 000 пользователей системы мониторинга PRTG) прямо описывает, что это за агент и зачем он приходит. Черновичное описание («проверяет URL при установке виджета, webhook или tracking-кода») не совсем точно — на самом деле это сенсор облачного мониторинга доступности, а не проверка интеграции виджета. В каталоге TrafficVeil бот отмечен как легитимный в категории «Прочие краулеры и сервисы».

Что такое PRTGCloudBot на самом деле

PRTGCloudBot — User-Agent сенсоров, которые измеряют доступность и время загрузки веб-страниц из разных точек мира через облачную инфраструктуру PRTG Cloud. Бот появляется, когда пользователь PRTG Network Monitor настраивает мониторинг веб-сервера через сенсоры Cloud HTTP v2 или Cloud Ping. Официальная строка UA выглядит так: Mozilla/5.0 (compatible; PRTGCloudBot/1.0; +https://www.paessler.com/prtgcloudbot; for_[licensehash]) — где licensehash уникален для конкретной настройки мониторинга и может меняться между сканированиями и локациями, поэтому не стоит ожидать одного фиксированного значения.

PRTGCloudBot обращается к сайту с интервалом, который определяет сам пользователь PRTG при настройке сенсора, — и делает это при каждом плановом скане, поэтому регулярность визитов напрямую отражает настройки конкретного клиента, а не общую политику Paessler.

Как работает PRTGCloudBot

Идентифицируется в access.log по паттерну User-Agent prtgcloudbot. Выполняет автоматические HTTP(S)-запросы к конкретным URL, которые указал пользователь PRTG при настройке сенсора, — как правило, это узкий набор адресов (главная страница или конкретная посадочная), а не системный обход всего каталога. Паттерн трафика зависит от типа сенсора: Cloud HTTP v2 проверяет доступность и время загрузки страницы, Cloud Ping — простую сетевую доступность.

Нагрузка на сервер

По классификации крупных каталогов ботов, инструменты такого типа (developer helpers / мониторинг) обычно не создают заметной нагрузки — они обращаются к конкретным страницам или эндпоинтам, а не сканируют сайт целиком. Признаки, на которые стоит обратить внимание:

• узкий, стабильный набор URL — один или несколько конкретных адресов, заданных пользователем PRTG;
• регулярность, соответствующая интервалу сканирования, настроенному в PRTG;
• отсутствие cookie и признаков сессии.

Обнаружение в логах

# Все запросы
grep -i "prtgcloudbot" /var/log/nginx/access.log

# Количество запросов за сегодня
grep -i "prtgcloudbot" /var/log/nginx/access.log | grep "$(date '+%d/%b/%Y')" | wc -l

# Уникальные IP
grep -i "prtgcloudbot" /var/log/nginx/access.log | awk '{print $1}' | sort -u

# Частота по дням
grep -i "prtgcloudbot" /var/log/nginx/access.log | awk '{print $4}' | cut -d: -f1 | sort | uniq -c

Верификация: полная строка UA содержит уникальный licensehash — если у вас есть основания сомневаться в подлинности, сравните формат заголовка с официальным образцом из документации Paessler. Для дополнительной проверки:

IP="1.2.3.4"
whois -h whois.cymru.com " -v $IP"
dig +short -x "$IP"

robots.txt

# Полная блокировка
User-agent: prtgcloudbot
Disallow: /

# Точечное ограничение
User-agent: prtgcloudbot
Disallow: /admin/
Disallow: /cart/
Disallow: /account/
Allow: /

# Разрешить полностью
User-agent: prtgcloudbot
Allow: /

Ключевой вопрос здесь простой: настраивала ли ваша команда мониторинг через PRTG. Если да — блокировка сломает мониторинг доступности именно вашего сайта; если нет — скорее всего, это чужая настройка (партнёр, клиент), и решение стоит принимать по обычной логике allow/deny.

Управление на уровне сервера

Nginx

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

# Мягкий вариант — rate limit
limit_req_zone $binary_remote_addr zone=prtgcloudbot:10m rate=15r/m;

location / {
    if ($http_user_agent ~* "prtgcloudbot") {
        limit_req zone=prtgcloudbot burst=30 nodelay;
    }
}

Apache (.htaccess)

RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} prtgcloudbot [NC]
RewriteRule ^ - [F,L]

Через TrafficVeil

• откройте список известных ботов в панели домена или /system/bots;
• найдите prtgcloudbot / PRTGCloudBot;
• если мониторинг настраивала ваша команда — allow; если источник неизвестен — уточните, прежде чем блокировать;
• при необходимости используйте массовые операции allow/deny без правки origin;
• проверьте логи: запросы должны уходить в блок/лимит согласно выбранной политике, если решили ограничить доступ.

Рекомендации по оптимизации

• Учитывая официально подтверждённую мониторинговую природу бота, блокировать его стоит только если мониторинг точно не ваш и не приносит пользы;
• не блокируйте поисковые роботы Google/Yandex случайно, если рядом настраиваете широкие правила;
• сначала измерьте долю запросов бота в логах/аналитике TrafficVeil, потом принимайте решение;
• для всплесков чаще достаточно rate-limit вместо полного 403;
• если это ваш собственный мониторинг — рассмотрите allowlist по IP или диапазону вместо полного открытия по UA, если TrafficVeil это поддерживает.

Сравнение с похожими ботами

Сводная таблица стратегии