Дата публикации
ai_products

MCP вместо дашбордов: как AI‑агенты учатся читать телеметрию ядра напрямую

Что нового

MCP (Model Context Protocol) превращается в интерфейс между AI‑агентами и инфраструктурой, а не просто в «прослойку» над дашбордами.

За одну неделю марта 2026 произошло три показательных события:

  1. Datadog выпустила MCP‑сервер.

    • Сервер подключает AI‑агентов к уже существующим дашбордам и метрикам Datadog.
    • Агент через MCP может:
      • читать метрики и логи;
      • запрашивать данные с дашбордов;
      • инициировать автоматические реакции (например, remediation‑скрипты).
    • По сути, Datadog официально признала MCP стандартным способом общения AI‑агентов с observability‑платформой.

  2. Qualys опубликовала отчёт по безопасности MCP‑серверов.

    • Команда TotalAI назвала MCP‑серверы «новым shadow IT для AI».
    • 53% проверенных MCP‑серверов используют статические секреты для аутентификации.
    • Qualys рекомендует добавить к MCP‑инфраструктуре наблюдаемость: логирование discovery‑событий, мониторинг вызовов, алерты по аномалиям.

  3. Cloud Native Now разобрала eBPF‑подход Microsoft Retina для Kubernetes‑сетей.

    • Retina работает как DaemonSet в кластере.
    • Снимает сетевую телеметрию через eBPF без изменений в приложениях.
    • Даёт причины дропов на уровне ядра.
    • Чётко разводит понятия:
      • мониторинг — заранее заданные вопросы;
      • observability — возможность задавать вопросы, о которых никто не думал при проектировании.

На этом фоне команда Ingero предлагает идти дальше: MCP‑сервер не должен просто оборачивать существующую observability‑платформу. Он сам может стать основным слоем наблюдаемости, напрямую подключённым к tracepoint’ам ядра и GPU.

Ключевой сдвиг: AI‑агент получает доступ не к агрегированным метрикам, а к сырым событиям ядра и CUDA, и сам решает, что и как агрегировать.

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

Два подхода к observability через MCP

Подход 1. Обёртка над существующей платформой (как у Datadog)

Схема:

  • Уже есть стек: метрики, логи, трейсы, дашборды.
  • Поверх этого появляется MCP‑сервер.
  • AI‑агент через MCP:
    • дёргает API дашбордов;
    • получает уже агрегированные и индексированные данные;
    • запускает автоматические действия.

Этот вариант хорошо подходит, если стек наблюдаемости уже отлажен, а задача — добавить AI‑автоматизацию.

Подход 2. MCP‑нативная наблюдаемость (как у Ingero)

Здесь MCP — не адаптер, а основной интерфейс к телеметрии.

Что делает Ingero:

  • Ставит eBPF‑агент в пользовательском пространстве.
  • Вешает uprobes на CUDA Runtime и Driver API.
  • Снимает все вызовы CUDA, контекст‑свитчи ядра, аллокации памяти.
  • Складывает события в SQLite‑базу.
  • Отдаёт доступ к этим данным через 7 MCP‑инструментов:
    • get_trace_stats — сводка по трейсу: количество CUDA‑событий, число причинно‑следственных цепочек, общее GPU‑время;
    • get_causal_chains — причинно‑следственные цепочки с объяснением на естественном языке, почему выросла латентность;
    • run_sql — произвольные SQL‑запросы к сырым событиям (например, show me all cudaMemcpyAsync calls over 100ms);
    • get_stacks — стеки вызовов для проблемных событий;
    • плюс ещё три вспомогательных инструмента (для навигации по базе и выбора диапазонов/фильтров).

MCP‑сервер в этой архитектуре — не «прокси к дашборду», а точка входа к сырым trace‑событиям ядра и GPU.

Пример: расследование регрессии TTFT у vLLM

Команда Ingero разбирала регрессию TTFT (Time To First Token) у vLLM:

  • первый токен генерировался в 14,5 раза дольше, чем базовая линия;
  • trace‑база зафиксировала:
    • 12 847 событий CUDA;
    • 4 причинно‑следственные цепочки;
    • полное GPU‑время;
    • все CUDA‑вызовы, контекст‑свитчи ядра и аллокации памяти.

Когда Claude подключился к MCP‑серверу и загрузил эту базу, он смог:

  • запросить get_trace_stats и увидеть общую картину;
  • через get_causal_chains прочитать человеческое описание цепочек, приведших к всплеску латентности;
  • через run_sql найти, например, все cudaMemcpyAsync дольше 100 мс;
  • через get_stacks посмотреть стеки вызовов для подозрительных событий.

Claude нашёл корень проблемы меньше чем за 30 секунд:

  • вычисление logprobs блокировало decode‑цикл;
  • на критическом пути это дало замедление в 256 раз;
  • в агрегированных метриках это не проявлялось — только в детальной причинно‑следственной цепочке между конкретными CUDA‑вызовами.

Классический MCP‑адаптер к дашборду в таком сценарии не помог бы: нужная детализация теряется на этапе агрегации.

Встроенная наблюдаемость за самим MCP‑сервером

Qualys справедливо обеспокоилась безопасностью MCP‑серверов:

  • 53% используют статические секреты;
  • предлагается логировать discovery‑события MCP и отслеживать паттерны вызовов.

У MCP‑серверов, которые имеют доступ к GPU‑инфраструктуре, риски другие:

  • по таймингам CUDA‑вызовов можно вытащить детали архитектуры модели;
  • по паттернам памяти — косвенно судить о размерах и структуре тензоров;
  • это чувствительная информация для любой команды, которая тренирует или сервит модели.

Ingero решает это так:

  • каждый вызов MCP‑инструмента сам попадает в trace;
  • та же eBPF‑инфраструктура, которая пишет GPU‑события, пишет и взаимодействие AI‑агента с MCP‑сервером;
  • нет отдельного «слоя логирования» — observability для MCP встроена в тот же пайплайн.

По сути, рекомендация Qualys «добавить наблюдаемость к MCP‑серверу» выполняется автоматически, потому что MCP‑сервер и есть инструмент наблюдаемости.

Что это значит для вас

Кому интересно MCP‑нативное observability

Инженерам по производительности и SRE:

  • Когда p99 «поплыл», а дашборды молчат о причине, нужен доступ к сырым событиям ядра и CUDA.
  • MCP‑нативный подход даёт возможность задавать AI‑агенту вопросы уровня:
    • «Почему конкретный GPU‑запрос занял в 14,5 раза больше времени?»
    • «Какие процессы конкурировали за CPU в момент просадки?»
  • Это не замена Prometheus/Grafana, а инструмент точечной диагностики.

ML‑инженерам и разработчикам фреймворков:

  • Отладка vLLM, PyTorch, CUDA‑ядра, dataloader’ов — всё это истории про «что именно делал GPU и CPU в конкретный момент».
  • С Ingero можно загрузить трейс и просто спросить у Claude через MCP:
    • «Что вызвало просадку производительности GPU в этом трейсе?»
    • «Где узкое место: память, PCIe, вычисления?»

Безопасникам и инженерам по комплаенсу:

  • MCP‑серверы становятся новым каналом доступа к инфраструктуре.
  • Если команда тестирует AI‑агентов с правами на observability, нужно понимать:
    • какие данные утекают через MCP;
    • как логируются запросы и ответы;
    • какие секреты используются для аутентификации.
  • Подход Ingero даёт встроенную «чёрную коробку» всех действий агента.

Когда MCP‑обёртки над дашбордами всё ещё полезны

  • Если у вас уже есть Datadog, Prometheus, Grafana, New Relic и настроенные алерты, MCP‑адаптер — быстрый способ:
    • дать AI‑агенту доступ к существующим метрикам;
    • автоматизировать рутинные реакции (рестарт сервисов, скейлинг и т.п.).
  • Для высокоуровневых вопросов вроде:
    • «Какой p99 у сервиса X за последний час?»
    • «У каких сервисов сейчас самый высокий error rate?» достаточно агрегированных данных.

Где MCP‑нативный подход не нужен

  • Если у вас нет GPU‑нагрузки, сложных сетевых сценариев или жёстких требований к латентности, eBPF‑трейсинг может быть избыточен.
  • Для малого проекта с одним‑двумя микросервисами проще жить с классическими логами и базовыми метриками.
  • MCP‑нативный observability‑слой имеет смысл там, где:
    • цена простоя или деградации высокая;
    • инфраструктура сложная (Kubernetes, GPU‑пулы, плотные кластеры);
    • уже используется AI‑агент (Claude, локальные модели) как ассистент инженеров.

Доступность и ограничения

  • Ingero — open source, лицензии:
    • Apache 2.0 для пользовательского пространства;
    • GPL‑2.0/BSD‑3 для eBPF в ядре.
  • Один бинарник, без внешних зависимостей, заявленная нагрузка — менее 2% overhead.
  • Формально проект доступен на GitHub. Для России может потребоваться VPN, если доступ к GitHub или отдельным AI‑клиентам ограничен.

Место на рынке

По отношению к Datadog и классическим APM/observability

  • Datadog использует MCP как адаптер к уже существующей платформе:
    • AI‑агент видит агрегированные метрики, логи, трейсы;
    • работает с теми же данными, что и дашборды.
  • Ingero использует MCP как основной интерфейс к eBPF‑трейсам:
    • AI‑агент получает сырые события ядра и CUDA;
    • сам строит агрегаты, цепочки причин и выводы.

По сути, это два разных слоя:

  • Datadog — про «что происходит в системе в целом».
  • Ingero — про «почему конкретный запрос/ядро/процесс ведёт себя странно».

Чётких цифр сравнения по производительности или цене с Datadog, Prometheus, New Relic или другими системами в исходных данных нет. Но по уровню детализации Ingero работает на более низком уровне — tracepoint’ы ядра и CUDA, а не агрегированные таймсерии.

По отношению к Microsoft Retina и eBPF‑агентам

  • Microsoft Retina уже использует eBPF для сетевой наблюдаемости в Kubernetes:
    • DaemonSet в кластере;
    • сбор сетевой телеметрии без изменений в приложениях;
    • причины дропов на уровне ядра.
  • Ingero применяет похожий принцип к GPU и системным вызовам и сразу заворачивает это в MCP.

Авторы ожидают, что MCP‑нативный паттерн распространится дальше:

  • Сетевая наблюдаемость:
    • вместо MCP‑обёртки над Prometheus — eBPF‑агент, который отдаёт AI‑агенту данные о пакетах и дропах напрямую (Retina уже половина пути).
  • Безопасность:
    • вместо MCP‑обёртки над SIEM — MCP‑сервер, который трассирует системные вызовы и отдаёт события безопасности в реальном времени.
  • Стоимость:
    • вместо чтения биллингового API — инструментация реального выделения ресурсов и прямая выдача этих данных AI‑агенту.

Общий тренд: AI‑агенту дают сырой телеметрический поток, а не только готовые дашборды.

Установка

Проект Ingero открыт, исходники и примеры расследований доступны. Можно воспроизвести разбор проблемы с PyTorch dataloader’ом или GPU‑регрессией у себя локально.

Сценарий из исходника использует базу pytorch-dataloader-starvation.db.

git clone https://github.com/ingero-io/ingero.git
cd ingero && make build
./bin/ingero mcp --db investigations/pytorch-dataloader-starvation.db

Этот запуск поднимает MCP‑сервер, который работает поверх SQLite‑базы с трейсом расследования.

Как запустить и подключить AI‑клиент

Общая конфигурация MCP

Сначала нужно создать конфиг MCP‑клиента. В примере он лежит в /tmp/ingero-mcp-dataloader.json:

{ "mcpServers": { "ingero": { "command": "./bin/ingero", "args": ["mcp", "--db", "investigations/pytorch-dataloader-starvation.db"] } } }

Этот файл говорит MCP‑клиенту:

  • запускать бинарник ./bin/ingero;
  • передавать ему аргументы mcp --db investigations/pytorch-dataloader-starvation.db;
  • использовать этот процесс как MCP‑сервер с именем ingero.

Вариант 1. Локально через Ollama

Если вы используете локальные модели через Ollama, можно подключить Ingero так:

# Установить ollmcp (MCP‑клиент для Ollama)
pip install ollmcp

# Запустить расследование с локальной моделью (данные не покидают машину)
ollmcp -m qwen3.5:27b -j /tmp/ingero-mcp-dataloader.json

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

Вариант 2. Через Claude Code (CLI)

Если вы используете CLI‑клиент для Claude, подключение выглядит так:

claude --mcp-config /tmp/ingero-mcp-dataloader.json

После запуска можно ввести команду:

/investigate

Далее — задавать уточняющие вопросы, например:

  • «what was the root cause?»
  • «which processes were competing for CPU time?»

Вариант 3. Claude Desktop

Можно добавить MCP‑конфиг Ingero в настройки Claude Desktop и работать в привычном интерфейсе. Пример запроса:

What caused the GPU performance issues in this trace?

MCP‑сервер Ingero отдаёт 7 инструментов, дальше Claude сам решает, какие использовать.

Что ещё полезно знать

  • Ingero распространяется под лицензиями Apache 2.0 (user‑space) и GPL‑2.0/BSD‑3 (eBPF в ядре).
  • Один бинарник, без внешних зависимостей, заявленный overhead — менее 2%.
  • Проект ориентирован на разработчиков, которые уже комфортно работают с eBPF, CUDA и AI‑клиентами с поддержкой MCP (Claude, Ollama через ollmcp и т.д.).
  • Для продакшн‑использования важно продумать:
    • модель доступа к MCP‑серверу (никаких статических секретов);
    • хранение trace‑баз (там могут быть чувствительные данные о моделях и инфраструктуре);
    • интеграцию с существующими системами алертинга и логирования.

Идея в том, что AI‑агент перестаёт быть просто «чатом поверх логов» и превращается в полноценного участника observability‑стека, который видит ту же глубину телеметрии, что и eBPF‑агент.

Читайте также

#claude-code#qwen#microsoft#github#ollama#mcp#kubernetes
🔗 Источник: https://ingero.io/mcp-observability-interface-ai-agents-kernel-tracepoints/
← Все новости