MCP как интерфейс наблюдаемости: подключение ИИ-агентов к точкам трассировки ядра

Протокол контекста модели (MCP) становится интерфейсом между ИИ-агентами и данными инфраструктуры. В марте 2026 года три значимых события подчеркнули эту тенденцию: Datadog выпустил MCP-сервер, подключающий данные мониторинга в реальном времени к ИИ-агентам для автоматического обнаружения и устранения проблем, Qualys опубликовал анализ безопасности, назвав MCP-серверы «новой теневой ИТ для ИИ», а Microsoft Retina продемонстрировала мониторинг сети Kubernetes на основе eBPF.

Два подхода к мониторингу через MCP

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

• Подход 1: Обёртывание существующих платформ — стратегия Datadog берёт уже собранные и агрегированные метрики, логи и трассировки и предоставляет к ним доступ через инструменты MCP. ИИ-агент запрашивает API дашборда, получает предварительно обработанные данные и действует на их основе. Это подходит командам со зрелыми стеками мониторинга, желающим добавить автоматизацию на основе ИИ поверх существующей системы.
• Подход 2: Создание нативной для MCP системы мониторинга — вместо обёртывания существующей платформы создать агент eBPF, который отслеживает системные вызовы через uprobes, сохраняет результаты в SQLite и предоставляет доступ ко всему через инструменты MCP. Интерфейс MCP становится основным интерфейсом, а не адаптерным слоем.

Нативный мониторинг MCP на практике

В статье подробно рассматривается конкретный пример трассировки регрессии TTFT в vLLM, где время получения первого токена было в 14,5 раз больше базового. База данных трассировок зафиксировала каждый вызов API CUDA, переключение контекста ядра и выделение памяти. Когда Claude подключается к MCP-серверу и загружает эту базу данных, он может использовать четыре конкретных инструмента:

• get_trace_stats — Просмотр полной сводки трассировки: 12 847 событий CUDA, 4 причинно-следственные цепочки, общее время GPU
• get_causal_chains — Чтение причинно-следственных цепочек, объясняющих, почему произошёл скачок задержки, на простом английском языке
• run_sql — Выполнение пользовательских запросов к необработанным данным событий (например, «покажи мне все вызовы cudaMemcpyAsync длительностью более 100 мс»)
• get_stacks — Исследование стеков вызовов для любого отмеченного события

Claude определил первопричину менее чем за 30 секунд: вычисление logprobs блокировало цикл декодирования, создавая замедление в 256 раз на критическом пути. Эта первопричина не была видна в агрегированных метриках, только в необработанных причинно-следственных цепочках между конкретными вызовами API CUDA.

Вопросы безопасности

Qualys обнаружил, что более 53% MCP-серверов полагаются на статические секреты для аутентификации, и рекомендовал добавить мониторинг для MCP-серверов: логирование событий обнаружения возможностей, отслеживание паттернов вызовов и оповещение об аномалиях. Для MCP-серверов, имеющих доступ к инфраструктуре GPU, поверхность атаки включает информацию о времени, структуры памяти и детали архитектуры модели.

В реализации Ingero каждый вызов инструмента MCP отслеживается с использованием той же инфраструктуры eBPF, которая фиксирует события GPU, создавая единый конвейер мониторинга, а не отдельный слой логирования.