AlertSite — тот же тип случая, что уже разбирался с Chirp и AccessStatus, только с чётко установленным крупным оператором: это synthetic-мониторинг сервис компании SmartBear (известной также по Swagger/OpenAPI, TestComplete, ReadyAPI). Enterprise-инструмент для мониторинга сайтов, API и приложений с более чем 350 глобальных точек — почти всегда подключается сознательно самой организацией для контроля SLA.
1. Что такое AlertSite на самом деле
AlertSite — synthetic-мониторинг платформа SmartBear: имитирует реальные пользовательские сценарии (переходы по сайту, вызовы REST/SOAP/GraphQL API) с более чем 350 точек присутствия по всему миру, чтобы обнаружить проблему раньше, чем её заметят реальные посетители. Инструмент используется крупными организациями для контроля выполнения SLA — соглашений об уровне обслуживания — и стоит от 1000 до 200000 долларов в зависимости от масштаба лицензии.
Отличительная черта AlertSite — многоуровневая верификация перед отправкой алерта: при обнаружении сбоя система повторяет проверку с той же точки, затем — со второй точки, и только если сбой подтверждён с нескольких локаций, отправляет уведомление с деталями (HTTP-статус, ошибка, скриншот состояния браузера). Это снижает число ложных срабатываний и, соответственно, число «лишних» повторных запросов к сайту.
| Параметр | Значение |
| Название | AlertSite |
| Оператор | SmartBear — известная enterprise-компания, также разработчик Swagger/OpenAPI, TestComplete, ReadyAPI |
| Роль | Synthetic-мониторинг доступности, производительности и функциональности сайтов/API/приложений для контроля SLA |
| User-Agent / паттерн | alertsite |
| Кто обычно инициирует | Сама организация-заказчик — enterprise-инструмент, требующий осознанной, платной подписки |
| Масштаб инфраструктуры | 350+ глобальных мониторинговых узлов, плюс возможность частных узлов внутри корпоративной сети клиента |
| Паттерн поведения | Регулярные проверки конкретных страниц/эндпоинтов, узкий и повторяющийся охват — не системный обход сайта; допускает повторные проверки с других локаций при обнаружении сбоя |
| robots.txt | Официально не считается ботом, гарантированно соблюдающим директивы — правило в файле скорее выражает пожелание, для гарантии нужна серверная блокировка |
| Категория (Known Agents) | Developer Helper |
| Пометка TrafficVeil | Легитимный / Прочие краулеры и сервисы |
2. Зачем AlertSite приходит на сайт
- регулярная проверка доступности и производительности конкретных страниц или API-эндпоинтов в рамках контроля SLA организацией-заказчиком;
- повторная проверка с другой географической точки при обнаружении сбоя — часть механизма верификации перед отправкой алерта, что может выглядеть как несколько запросов подряд с разных IP;
- если организации предоставлен доступ — мониторинг может охватывать и защищённые/staging-разделы; без такого доступа бот видит только публичные страницы.
Типичный кейс: в логах фиксируется регулярный, узкий по охвату паттерн запросов к одним и тем же страницам с интервалом, близким к cron-расписанию — ожидаемое поведение подключённого enterprise-мониторинга, а не аномалия.
3. Нагрузка и риски
Нагрузка обычно минимальна и предсказуема — узкий охват конкретных эндпоинтов, регулярный интервал. Прямого риска для контента нет, цель технической проверки статуса не связана со сбором данных.
Главный практический риск — тот же, что у Chirp и AccessStatus: путаница при смене владельца или подрядчика организации. Если подписка на AlertSite осталась активной от прежней команды, регулярные проверки могут восприниматься как непонятный фоновый шум, хотя по факту это чей-то, возможно уже неактуальный, SLA-мониторинг.
4. Как найти AlertSite в логах
# Базовый поиск
grep -i "alertsite" /var/log/nginx/access.log
# Топ URL — ожидаемо узкий набор конкретных эндпоинтов
grep -i "alertsite" /var/log/nginx/access.log | awk '{print $7}' | sort | uniq -c | sort -rn | head
# Топ IP за этим UA — ожидаемо много разных точек присутствия из-за 350+ глобальных узлов
grep -i "alertsite" /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head
# Регулярность интервалов — характерный признак synthetic-мониторинга
grep -i "alertsite" /var/log/nginx/access.log | awk '{print $4}' | cut -d: -f1,2 | sort | uniq -cВерификация. Строку UA подделать может любой скрипт. Официального списка IP-диапазонов не найдено — учитывая распределённую инфраструктуру из 350+ точек, единого узкого ASN может не быть в принципе; для решения allow/deny смотрите связку UA + узкий, регулярный паттерн обхода конкретных эндпоинтов:
IP="1.2.3.4"
whois -h whois.cymru.com " -v $IP"
dig +short -x "$IP"5. robots.txt для AlertSite
# Жёсткий запрет — сломает мониторинг SLA, если он используется сознательно
User-agent: alertsite
Disallow: /
# Разрешить всё — рекомендуемый вариант по умолчанию
User-agent: alertsite
Allow: /Поскольку AlertSite официально не считается гарантированно соблюдающим robots.txt, правило само по себе лишь выражает пожелание — для реального ограничения доступа нужна блокировка на уровне сервера.
6. Блокировка вручную и через TrafficVeil
Nginx:
if ($http_user_agent ~* "alertsite") {
return 403;
}Apache (.htaccess):
RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} alertsite [NC]
RewriteRule ^ - [F,L]TrafficVeil:
- прежде чем блокировать — уточните у команды/клиента, не подключён ли AlertSite для контроля SLA сознательно;
- если используется — allow, дополнительно ограничивать не требуется, нагрузка минимальна по природе enterprise-инструмента;
- если сайт сменил владельца/подрядчика и подписка осталась от прежней команды — правильнее отвязать мониторинг через сам сервис SmartBear, а не только блокировать технически;
- после изменения сверьте логи и, если применимо, убедитесь, что нужный вам SLA-мониторинг продолжает работать.
7. Что делать: короткий алгоритм
- Первый шаг: выяснить, подключён ли сайт к AlertSite сознательно — это быстрее и надёжнее технической диагностики;
- Подключён и нужен — allow, не трогать;
- Подписка неактуальна или осталась от прежней команды — отвязать через SmartBear, а не блокировать вслепую;
- Точно посторонний и нежелательный — Disallow + запрет в TrafficVeil, риска для контента при этом нет;
- Не блокируйте по маске
User-agent: *, чтобы не задеть Googlebot/YandexBot заодно.
8. С кем не путать AlertSite
| Бот / сосед | Кластер | Комментарий |
| Chirp | Прочие краулеры и сервисы (см. отдельную статью) | Та же логика «скорее всего, ваш собственный мониторинг», но от другого оператора (Binary Canary) |
| AccessStatus | Прочие краулеры и сервисы (см. отдельную статью) | Та же категория задачи (HTTP-статус мониторинг), но без установленной конкретной компании |
| UptimeRobot | Не в базе TrafficVeil, но стоит знать | Более массовый, часто бесплатный аналог для малого бизнеса — в отличие от enterprise-ориентированного AlertSite |
| SentryUptimeBot | Не в базе TrafficVeil, но стоит знать | Часть платформы Sentry, тот же тип задачи |
9. Стратегия allow/deny для AlertSite
| Ситуация | Действие |
| SLA-мониторинг подключён сознательно и нужен | Allow — это собственная (или клиентская) enterprise-инфраструктура мониторинга |
| Неясно, чья это подписка | Уточнить у команды/клиента, прежде чем принимать решение |
| Подписка осталась от прежней команды/подрядчика | Отвязать через сам сервис SmartBear |
| Точно посторонний, мониторинг не нужен | Disallow + запрет в TrafficVeil |
| Подозрение на подделку UA | Проверять узкий, регулярный охват конкретных эндпоинтов — нетипичное поведение повод для дополнительной проверки IP/ASN |