OpenSearch, Elastic или Kibana и подобные им инструменты — уже давно стандарт для поиска и визуализации логов, ведь они удобны, у них мощная поисковая система. Но сложный анализ — агрегации, парсинг, выявление сложных закономерностей — заставляет их встроенные средства работать на пределе возможностей. Особенно если структура логов далека от идеала.

Меня зовут Игорь Щегловитов, я работаю экспертом по тестированию в QC облачной инфраструктуры и веб-порталов. Раньше наша команда решала такие задачи кастомными утилитами на C#, которые выгружали логи из ELK и анализировали их локально. Однако каждое новое требование превращалось в мини-проект: доработать код, написать новые парсеры, скрипты агрегации и фильтрации. Работа замедлялась, техдолг рос.

Я решил использовать связку AI-агентов с кастомными промптами, собственный сервисный слой (MCP) для доступа к логам и LLM-модель, чтобы превращать пользовательские запросы в автоматический алгоритм анализа. Так, кейсы вроде «Посчитай уникальных пользователей за сутки» или «Проанализируй ошибки за период» решаются без ручного кодинга.

Ниже мой кейс: расскажу, как это сделал, поделюсь ссылкой на гитхаб, так что, если хотите упростить себе анализ логов, — эта статья для вас.

Контекст на берегу: у нас в «Лаборатории Касперского» для работы с чувствительными данными развернута собственная LLM с OpenAI-совместимым API, то есть можно подключать и использовать в автоматизации сторонние AI-агенты.

Проблема контекстного окна

Главное ограничение при работе с LLM — контекстное окно, лимит текста или токенов, которые модель может учитывать при обработке запроса. У нашей LLM предел — 128 000 токенов, примерно 90–100 тысяч слов, но на практике качество и скорость ответа заметно падают, уже когда окно заполнено на 70–80%.

В логах объем данных огромен, за сутки — сотни гигабайтов. Поэтому классический подход «скормить все данные модели» не работает даже теоретически: ни одно контекстное окно такой объем не вместит.

Связка AI-агентов, MCP и LLM

Если использовать связку из AI-агентов, MCP и LLM, задача решается поэтапно, без попыток обработать все и сразу, объем данных, попадающих в LLM, минимизируется. В общих чертах процесс выглядит так:

• Анализ структуры лога. Через сервис MCP выгружается всего один пример лога, который отправляется LLM. Модель определяет, как из него извлечь интересующие поля, например userId, exception и тому подобные, используя RegExp, JSONPath или другие техники.

• Массовая выгрузка логов. Агент формирует запросы к OpenSearch через Scroll API, скачивает логи за нужный интервал и сохраняет локально в виде файлов JSON.

• Генерация скрипта анализа. На основе структуры лога и задачи LLM генерирует Python-скрипт, который обработает скачанные данные вне контекстного окна модели.

• Выполнение анализа и вывод результата. Генерируемый скрипт анализирует локальный массив логов, а итог отправляется пользователю, например, в виде stdout или файла.

• Оркестрация сложных задач. Когда нужно выгрузить и объединить несколько разных наборов логов или провести последовательные/параллельные этапы анализа, специальная роль Orchestrator разбивает задачу на цепочку подзадач.

Так выглядит sequence diagram, взаимодействие компонентов:

sequenceDiagram
  participant User as Пользователь
  participant Orchestrator as Roo Code: Orchestrator
  participant LogAnalyzer as Roo Code: LogAnalyzer
  participant MCP as MCP
  participant OS as OpenSearch
  participant LLM as LLM 
  participant PyDev as Roo Code: Python Developer
  participant Runner as Python Runner
  participant Artifacts as JSON/Отчеты

  User->>Orchestrator: Задача (например, уникальные userId за сутки)
  Orchestrator->>LogAnalyzer: Подзадача #1 (определить схему лога)
  LogAnalyzer->>MCP: Запросить 1 пример лога (DQL, индекс, интервал)
  MCP->>OS: Search (sample)
  OS-->>MCP: 1 лог
  MCP-->>LogAnalyzer: Пример лога
  LogAnalyzer->>LLM: Пример + инструкции (как извлекать поля)
  LLM-->>LogAnalyzer: Схема/регэксп/JSON‑ключи

  LogAnalyzer->>MCP: Scroll по шаблону (массовая выгрузка)
  MCP->>OS: Scroll API
  OS-->>MCP: Пакеты логов
  MCP-->>Artifacts: Сохранить в JSON

  Orchestrator->>PyDev: Подзадача #2 (написать анализ)
  PyDev->>LLM: Запрос на генерацию скрипта (цели + пример схемы)
  LLM-->>PyDev: Python‑скрипт (агрегации/фильтры)
  PyDev->>Runner: Запуск скрипта на локальных JSON
  Runner-->>Artifacts: Результаты (stdout/файлы)
  Orchestrator-->>User: Ответ/файлы/метрики

Roo Code: почему именно он и зачем в нем роли

Я попробовал несколько рекомендованных в компании AI-агентов, из которых выбрал Roo Code — open-source-платформу для создания и оркестрации AI-агентов.

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

LogAnalyzer отвечает за разбор структуры логов, построение схемы и подготовку выборки. PythonDeveloper принимает на вход схему и цели анализа и генерирует Python-скрипт для обработки логов. Orchestrator координирует выполнение цепочки подзадач, их разбиение и сбор результатов. Подробнее о кастомных ролях рассказано здесь.

В Roo Code роли реализуются через кастомные промпты и инструкции. Например, для LogAnalyzer я добавил явное правило: «Если задача связана с анализом логов — переключайся на роль LogAnalyzer, используй RegExp/JSONPath». Для PythonDeveloper — «Пиши минимальный, понятный и оптимальный Python-скрипт, который читает данные из JSON и выводит результат в stdout».

MCP: мост между AI-агентом и логами

MCP (Model Context Protocol) — это сервис-прокси, который расширяет возможности AI-агента, предоставляя ему доступ к внешним источникам данных. В моем случае MCP реализует API для поиска и скачивания логов из OpenSearch.

Я просмотрел несколько готовых MCP-сервисов для ElasticSearch/OpenSearch, например elasticsearch-mcp, но они были избыточны для моей задачи. Мне требовался максимально простой интерфейс: уметь по запросу скачивать логи за период по индексу и фильтру, возвращать их в чистом виде без лишней метаинформации, иметь возможность быстро получать примеры логов для структурного анализа.

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

Итоги и перспективы

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

Конечно, есть куда расти: хочу добавить визуализацию результатов, расширить типы поддерживаемых логов, интегрировать дополнительные источники, например Prometheus или сторонние API. Но уже сейчас связка LLM + Roo Code + MCP заметно упростила работу членам нашей команды.

Если у вас есть вопросы или опыт внедрения похожих решений — буду рад обсудить в комментариях!