Анализ логов ИИ-краулеров в ClickHouse: построение собственной аналитической платформы для мониторинга ботов

16 мин чтенияОбновлено 02.10.2026

Эволюция поискового сканирования: почему классические счетчики бесполезны для ИИ-ботов

В эпоху трансформации поисковых интерфейсов и активного развития систем генеративного поиска структура веб-трафика претерпела фундаментальные изменения. Наряду с традиционными поисковыми роботами на веб-ресурсы ежедневно приходят десятки автоматизированных агентов нового поколения: краулеры поисковых LLM-платформ, агентские поисковики и автономные сборщики данных. Среди них ключевую роль играют такие агенты, как GPTBot, OAI-SearchBot, ClaudeBot, PerplexityBot, Google-Extended, Meta-ExternalAgent, Applebot-Extended и Bytespider.

С точки зрения архитектуры взаимодействия с сайтом этих ботов необходимо четко разделять на три функциональные категории:

Краулеры предварительного обучения (Pre-training / Data-mining): обходят веб с целью массового сбора текстовых массивов для обучения базовых моделей. Они генерируют колоссальную нагрузку, запрашивают глубокие страницы архивов и каталогов, но не обеспечивают прямой поисковый трафик в моменте.
Поисковые краулеры реального времени (RAG & Search Bots): обслуживают генеративные поисковые системы и алгоритмы синтеза ответов (SearchGPT, Perplexity, AI Overviews). Их цель — оперативное извлечение свежих фактов, актуальных цен, товарных остатков и экспертных материалов для включения в сгенерированные ответы пользователям со ссылками на первоисточник.
Пользовательские агенты прямого действия (On-demand Fetchers): инициируют запросы в момент, когда пользователь языковой модели вставляет конкретный URL в диалоговое окно для анализа или суммаризации.

Главная аналитическая ловушка для большинства владельцев сайтов заключается в попытке отслеживать этот трафик стандартными инструментами веб-аналитики (Яндекс Метрика, Google Analytics и аналогичные клиентские счетчики). Автоматизированные боты либо вовсе не запускают JavaScript-код, либо намеренно блокируют исполнение аналитических скриптов для экономии времени и вычислительных ресурсов. В результате в стандартных маркетинговых отчетах активность ИИ-краулеров оказывается «невидимой».

Единственным объективным и полным источником истины являются серверные журналы доступа (access logs) пограничных маршрутизаторов и веб-серверов. Однако классический стек логирования на базе Elasticsearch, Logstash и Kibana (ELK) при масштабировании на десятки миллионов строк в сутки сталкивается с серьезными архитектурными барьерами: колоссальным потреблением оперативной памяти инвертированными индексами, высокими затратами на хранение и медленным выполнением аналитических агрегаций по сложным URL-структурам.

Контроль над сканированием сайта ИИ-краулерами — фундамент Generative Engine Optimization (GEO). Без собственной платформы сбора логов невозможно понять, какие материалы попадают в индекс генеративных систем, а какие создают паразитную нагрузку на инфраструктуру.

Архитектура платформы: потоковый конвейер Nginx/Envoy → Vector → ClickHouse → Grafana

Для создания высокопроизводительной, отказоустойчивой и экономичной платформы мониторинга оптимально использовать современный конвейер потоковой аналитики, состоящий из четырех специализированных компонентов:

Слой сбора событий (Nginx / Envoy): веб-серверы и балансировщики нагрузки, сконфигурированные на запись расширенных журналов доступа в структурированном формате JSON с буферизацией дискового ввода-вывода.
Слой доставки и потоковой трансформации (Vector): ультралегковесный и высокопроизводительный агент на базе Rust, который читает логи в реальном времени, парсит структуру, классифицирует ботов, нормализует URL и пакетирует данные для передачи в хранилище.
Слой аналитического хранения (ClickHouse): ориентированная на колонки аналитическая СУБД, способная сжимать журналы в 5–10 раз по сравнению с несжатым текстом и выполнять агрегационные запросы по миллиардам записей за миллисекунды.
Слой визуализации и мониторинга (Grafana): интерфейс аналитических панелей для инженеров, специалистов по инфраструктуре и экспертов по SEO/GEO, обеспечивающий мониторинг в реальном времени и алертинг по ключевым аномалиям.

Настройка источников: структурированное логирование в Nginx и Envoy

Стандартный формат combined access log непригоден для глубокого анализа, так как не фиксирует время отклика бэкенда, детали TLS-рукопожатий, специфические заголовки маршрутизации и виртуальные хосты. Первым шагом является перевод логирования на структурированный формат JSON.

Конфигурация структурированного JSON в Nginx

В блоке http конфигурационного файла Nginx объявляется расширенный формат с экранированием символов и набором метрик производительности:

Временные метки: точное время в стандарте ISO 8601 (time_iso8601) и эпоха в миллисекундах (msec).
Сетевые идентификаторы: реальный IP-клиента (remote_addr), заголовок цепочки прокси (http_x_forwarded_for) и доменное имя (host / server_name).
Параметры запроса: HTTP-метод (request_method), полный URI с параметрами (request_uri), протокол (server_protocol) и исходный User-Agent (http_user_agent).
Показатели производительности и отклика: HTTP-статус ответа (status), размер отправленного тела в байтах (body_bytes_sent), общее время обработки запроса сервером (request_time) и время задержки бэкенда (upstream_response_time).
Служебные заголовки: Referer (http_referer) и статус кэширования (upstream_cache_status).

Для предотвращения деградации производительности дисковой подсистемы при всплесках трафика директива access_log настраивается с параметрами буферизации: buffer=64k flush=5s. Это позволяет операционной системе группировать записи в памяти и сбрасывать их на накопитель блоками, не вызывая блокировок рабочих процессов Nginx.

Особенности логирования в Envoy Proxy

В инфраструктурах на базе Envoy Proxy настройка доступа выполняется в секции access_log соответствующего слушателя (Listener). Используется форматтер json_format с полями start_time, response_code, duration, response_tx_duration, downstream_remote_address, request_headers_user_agent и request_headers_path. В высоконагруженных микросервисных средах вместо записи в файл может применяться прямая передача логов в Vector по gRPC-протоколу Access Log Service (ALS).

Пайплайн Vector: фильтрация, верификация User-Agent и потоковая доставка

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

Потоковая обработка на Vector Remap Language (VRL)

С помощью встроенного языка VRL агент Vector реализует конвейер трансформации для каждой строки лога:

Безопасный парсинг JSON: извлечение структурированных полей и мгновенная отбраковка поврежденных записей без остановки сервиса.
Нормализация и очистка URL: выделение базового пути документа (clean_path) без динамических параметров пагинации, сессионных токенов и трекинговых меток (utm, fbclid, gclid), что критически важно для последующей группировки страниц в базе.
Категоризация контента: разметка типа запрашиваемого документа на основе расширения или путей (HTML-страницы, JSON/API-эндпоинты, XML-карты сайта sitemap.xml, файл директив robots.txt, медиафайлы).

Классификация и идентификация краулеров

Vector выполняет сопоставление строки User-Agent по сигнатурам известных поисковых ботов и распределяет трафик по семействам:

Платформы OpenAI: маркеры GPTBot (сбор обучающих данных), OAI-SearchBot (индексация для поиска в реальном времени), ChatGPT-User (прямые переходы пользователей).
Платформы Anthropic: маркеры ClaudeBot и сопутствующие исследовательские сборщики.
Платформы Perplexity: маркер PerplexityBot для поискового сбора фактов и цитирования.
Платформы Google: маркеры Google-Extended (управление обучением) и GoogleOther.
Платформы Meta: маркеры Meta-ExternalAgent и Meta-ExternalFetcher.
Другие платформы: маркеры Bytespider, Applebot-Extended, CCBot и региональные поисковые сканеры.

Борьба со спуфингом: верификация подлинности ботов

Одной из наиболее опасных проблем при анализе бот-трафика является фальсификация User-Agent (User-Agent Spoofing). Десятки коммерческих скраперов, спам-ботов и парсеров контента намеренно маскируются под официальных роботов OpenAI или Anthropic, чтобы обойти базовые ограничения брандмауэров.

Для отсечения фальшивок архитектура платформы предусматривает верификацию по алгоритму Forward-Confirmed Reverse DNS (FCrDNS) и сопоставление с опубликованными IP-диапазонами:

Сверка с CIDR-диапазонами: официальные провайдеры публикуют диапазоны IP-адресов своих краулеров. Vector сопоставляет IP-адрес запроса со справочником подсетей с помощью быстрых бинарных деревьев CIDR.
Верификация через rDNS: выполнение обратного DNS-запроса (PTR-запись) для получения имени хоста с последующим прямым DNS-запросом к полученному домену для подтверждения совпадения исходного IP.
Маркировка статуса: в поток добавляется признак is_verified_bot со значениями: подтвержденный бот (1), неподтвержденный / поддельный бот (0). Это позволяет в аналитике изолировать настоящих ИИ-краулеров от мошеннических парсеров.

Надежность буферизации и пакетная вставка (Batching)

ClickHouse категорически не приемлет вставки одиночных строк (построчные инсерты быстро перегружают файловую систему метаданными слияний). Vector решает эту задачу с помощью встроенного буфера:

Дисковый буфер (On-disk buffer): сохраняет поток событий на локальный диск в случае недоступности ClickHouse (при перезагрузках или сетевых неполадках), исключая потерю телеметрии.
Пакетная группировка (Batching): накапливает события до достижения порога в 50 000–100 000 записей или сбрасывает данные по таймауту 1–2 секунды. Такой режим обеспечивает минимальную нагрузку на ClickHouse и максимальную скорость записи.

Схема данных ClickHouse: колоночная оптимизация для миллиардов записей

Эффективность аналитической платформы напрямую зависит от правильного проектирования структуры таблиц, типов данных и выбора ключа первичной сортировки в ClickHouse.

Структура целевой таблицы логов

Для хранения детальных событий создается таблица на базе движка MergeTree со следующими типами данных:

timestamp (DateTime64(3, 'UTC')): метка времени с точностью до миллисекунд.
bot_family (LowCardinality(String)): семейство робота (OpenAI, Anthropic, Perplexity, Google, Meta, Unknown). Использование LowCardinality ускоряет фильтрацию и сжимает строковые словари до байтовых индексов.
bot_name (LowCardinality(String)): конкретный User-Agent идентификатор (GPTBot, ClaudeBot, PerplexityBot).
bot_type (LowCardinality(String)): функциональный тип (Search, Training, User-Action).
is_verified (UInt8): флаг подтверждения подлинности IP-адреса.
remote_ip (IPv6): универсальный компактный тип для хранения адресов IPv4 и IPv6 (16 байт на запись).
method (LowCardinality(String)): метод HTTP-запроса (GET, POST, HEAD).
host (LowCardinality(String)): доменное имя сайта.
path (String): нормализованный путь к странице без GET-параметров.
path_prefix (LowCardinality(String)): первый логический сегмент пути (например, /blog, /catalog, /articles) для быстрого построения срезов по разделам.
query_string (String): исходная строка параметров запроса.
status (UInt16): числовой HTTP-код ответа сервера.
bytes_sent (UInt64): объем переданного трафика в байтах.
request_time (Float32): общее время обработки запроса сервером в секундах.
upstream_time (Float32): время генерации ответа бэкендом в секундах.
user_agent (String): полная исходная строка заголовка User-Agent.

Ключ сортировки (ORDER BY) и партиционирование

В ClickHouse первичный ключ определяет физический порядок хранения данных на диске. Оптимальный ключ для таблицы бот-логов:

ORDER BY (bot_family, toDate(timestamp), status, path_prefix, path, timestamp)

Такой порядок гарантирует, что запросы аналитиков, фильтрующие данные по конкретному семейству ботов за выбранный период времени, считывают компактный диапазон данных без полного сканирования таблицы.

Партиционирование настраивается по месяцам: PARTITION BY toYYYYMM(timestamp). Это предотвращает появление миллионов мелких партиций и позволяет мгновенно удалять устаревшие исторические месяцы при необходимости. Дополнительно настраивается директива TTL: TTL timestamp + INTERVAL 90 DAY для автоматической ротации детальных логов.

Материализованные представления (Materialized Views) для мгновенных отчетов

Построение графиков за месяцы и годы по сырым логам требует обработки сотен гигабайт данных. Для обеспечения моментального отклика дашбордов Grafana создаются материализованные представления:

Почасовые агрегаты (hourly summary): таблица на движке SummingMergeTree, хранящая сумму запросов, суммарный трафик, число ошибок по кодам ответов с группировкой по toStartOfHour(timestamp), bot_name, is_verified, status. Размер такой таблицы в тысячи раз меньше исходного лога, а запросы строятся за доли миллисекунды.
История ревизитов страниц (page recrawl state): таблица на движке AggregatingMergeTree, отслеживающая для каждого URL дату первого визита, дату последнего визита и общее число обходов через агрегатные функции minState, maxState и countState.

Дашборды в Grafana: визуализация, мониторинг аномалий и краулинговый аудит

Интеграция ClickHouse с Grafana через официальный плагин позволяет развернуть единый аналитический центр для мониторинга активности роботов.

Ключевые панели мониторинга

Полноценный дашборд разделяется на специализированные аналитические блоки:

Интенсивность и объем сканирования (Crawl Volume & Velocity): линейные графики запросов в секунду (RPS) с детализацией по ботам. Позволяют моментально заметить всплеск активности при выкатке новых поисковых индексов или агрессивном парсинге.
Распределение HTTP-кодов: стек-диаграмма ответов 200, 301, 304, 403, 404, 429 и 5xx. Резкий рост кодов 429 свидетельствует о срабатывании лимитов запросов, а появление 500/502/504 сигнализирует о перегрузке бэкенда краулерами.
Карта ревизитов (Re-crawl Frequency): гистограмма распределения интервалов между визитами ботов на ключевые страницы. Показывает, насколько регулярно поисковые LLM-боты возвращаются за обновлением информации (раз в сутки, раз в неделю или реже).
Идентификация спуфинга (Fake Bots Monitor): панель, отображающая процент и абсолютное число запросов, где User-Agent совпадает с известными ИИ-ботами, но IP-адрес не прошел верификацию.
Нагрузка на сервер и перцентили задержки: графики p50, p95 и p99 времени отклика (TTFB) отдельно для краулеров и живых пользователей. Позволяют оценить, замедляет ли бот-трафик работу сайта для реальных клиентов.

Практические SQL-запросы для панелей Grafana

Для построения графика динамики верифицированных запросов по семействам ботов используется запрос:

SELECT toStartOfInterval(timestamp, INTERVAL 5 MINUTE) AS time, bot_family, count() AS requests FROM bot_access_logs WHERE timestamp >= $__fromTime AND timestamp <= $__toTime AND is_verified = 1 GROUP BY time, bot_family ORDER BY time

Для отслеживания страниц, подвергающихся наиболее частым ревизитам поисковыми ботами в реальном времени:

SELECT path, bot_name, count() AS hits, max(timestamp) AS last_visit FROM bot_access_logs WHERE timestamp >= now() - INTERVAL 24 HOUR AND bot_type = 'Search' AND status = 200 GROUP BY path, bot_name ORDER BY hits DESC LIMIT 50

Стратегическое применение данных в SEO и GEO

Собранные в ClickHouse данные открывают принципиально новые возможности для оптимизации видимости сайта в поисковых и генеративных системах.

Оптимизация краулингового бюджета (Crawl Budget)

Анализ логов регулярно выявляет нерациональное расходование ресурсов поисковых ботов. Типичные проблемы:

Сканирование бесконечной пагинации и дублей: боты тратят десятки тысяч запросов на обход страниц сортировок, фильтров и служебных ссылок вместо индексации ключевых экспертных статей и карточек товаров.
Задержка в индексации нового контента: сопоставление даты публикации статьи с меткой первого визита OAI-SearchBot или PerplexityBot показывает фактический лаг включения страницы в генеративный индекс.
Нерегулярность обхода обновлений: если боты не возвращаются на обновленные страницы в течение недель, это указывает на низкий приоритет ресурса или проблемы с внутренней перелинковкой и картой сайта.

Управление доступом через robots.txt и HTTP-заголовки

На основе аналитики логов компания может гибко настроить политику взаимодействия с платформами искусственного интеллекта:

Селективная блокировка датасет-майнеров: закрытие доступа краулерам предварительного обучения (например, GPTBot) при сохранении полного доступа для поисковых ботов реального времени (OAI-SearchBot, PerplexityBot). Это позволяет защитить авторский контент от неконтролируемого обучения моделей, не теряя переходы из генеративных поисковых ответов.
Контроль соблюдения директив: проверка логов после изменения правил в robots.txt позволяет достоверно убедиться, что конкретные боты действительно прекратили сканирование закрытых разделов.
Оптимизация заголовка X-Robots-Tag: точечная отдача директив noindex для неинформативных страниц непосредственно в HTTP-ответе, экономя время сканирования.

Защита инфраструктуры и адаптивный Rate Limiting

Если генеративные краулеры вызывают деградацию бэкенда, вместо жесткой блокировки настраивается адаптивное ограничение частоты запросов:

Выделение верифицированных поисковых ботов в отдельный пул с мягким лимитом (например, не более 5–10 запросов в секунду на IP).
Агрессивное кэширование ответов для роботов на уровне Nginx (microcaching на 10–60 секунд), снижающее нагрузку на процессор и базы данных до нуля.
Немедленная изоляция и блокировка поддельных ботов (spoofed crawlers), создающих паразитную нагрузку без какой-либо поисковой пользы.

Чеклист развертывания платформы

Для успешного внедрения собственной аналитической платформы рекомендуется следовать пошаговому плану:

Стандартизация формата логов: настроить выгрузку access log в формате структурированного JSON на всех граничных узлах Nginx или Envoy с включением метрик времени задержки и буферизацией записи.
Развертывание ClickHouse: создать базу данных, настроить оптимизированную таблицу логов с эффективными типами данных (LowCardinality, IPv6, DateTime64) и ключом сортировки по семейству ботов и дате.
Настройка материализованных представлений: внедрить таблицы предрассчитанных часовых агрегатов и агрегатов ревизитов для мгновенного выполнения аналитических запросов.
Установка и конфигурация Vector: развернуть пайплайн сбора логов, добавить логику фильтрации VRL, классификацию краулеров, механизм сверки подсетей и пакетную вставку через дисковый буфер.
Подключение Grafana: установить плагин ClickHouse, импортировать аналитические дашборды для мониторинга RPS, кодов ответа, частоты ревизитов и аномалий.
Настройка системы оповещений: активировать алерты в командный мессенджер при росте кодов ошибок 429 и 5xx или при резких всплесках неавторизованного сканирования.
Интеграция с процессами SEO/GEO: наладить еженедельный аудит эффективности обхода сайта для оперативной корректировки robots.txt, структуры перелинковки и краулингового бюджета.

Cobalt Media проведет предварительный аудит, определит приоритетные направления роста и подготовит прозрачную оценку работ без обещаний гарантированного места в выдаче.

по теме

Стоимость SEO-продвижения Бесплатный SEO-Аудит