Зачем следить за LLM из ядра?
Представьте, что ваш продакшн-агент на базе Claude 4 или GPT-5 внезапно начал сжигать $500 в час на API-вызовы. Вы подозреваете MCP-сервер, но как это доказать? Классические методы мониторинга требуют лазить по коду, вставлять логгеры, переписывать клиенты. А что если можно просто подключиться к ядру Linux и слушать все, что происходит? Это не магия, это eBPF.
1Как eBPF-трассировщик видит всё без спроса
Инструмент вроде llm-ebpf-tracer (актуальная версия 2.1 на март 2026) цепляется за системные вызовы connect, send, recv. Он не просто смотрит на сокеты - он умеет заглядывать внутрь TLS-сессий. Да, тот самый HTTPS-трафик к api.openai.com или api.anthropic.com. Для этого используется технология eBPF USDT (User Statically-Defined Tracing) или uprobes, которые цепляются за функции шифрования в OpenSSL или BoringSSL.
Звучит как взлом? Это легально только если вы мониторите свои собственные системы. Не пытайтесь прицепить этот трассировщик к соседскому продакшену (даже если очень хочется).
2Что именно он ловит: от GPT-5 до MCP
Трассировщик автоматически классифицирует трафик по сигнатурам. Запрос к GPT-5 Turbo? Поймал. Вызов Claude 4 Opus? Есть. Запрос через LiteLLM-роутер? Определит и покажет, какой бекенд был выбран. Но главная фишка - отслеживание Model Context Protocol. Каждый вызов к MCP-серверу (например, через интеграцию в llama.cpp) тоже попадает в логи: какой инструмент был вызван, сколько данных передано, как долго длился запрос.
- Метрики задержек: p50, p95, p99 для каждого эндпоинта LLM API
- Распределение токенов: prompt vs completion tokens для каждого провайдера
- Стоимость вызовов в реальном времени (использует актуальные цены на март 2026)
- MCP-статистика: вызовы инструментов, ошибки, латенси
Сравнение: eBPF против старых методов
Вот где начинается веселье. Большинство команд до сих пор используют один из трех подходов, и все они раздражают.
| Метод | Нужно менять код? | Накладные расходы | Поддержка MCP |
|---|---|---|---|
| Библиотеки OpenTelemetry (Python, JS) | Да, везде | Средние (+5-15% CPU) | Только если вручную инструментировать |
| Прокси-сервер (мидлварь) | Нет, но меняется сеть | Высокие (+ задержка, SPOF) | Частично, если MCP идет через HTTP |
| Модификация клиентских библиотек | Да, и поддерживать костыли | Низкие | Нет |
| eBPF-трассировщик | Нет, вообще | Минимальные (1-3% CPU) | Полные, на любом стеке |
Прокси-серверы - это прошлый век. Они ломают TLS end-to-end, добавляют точки отказа и не видят MCP-вызовы, которые идут через Unix-сокеты или gRPC. Библиотеки? Попробуйте добавить OpenTelemetry в legacy-систему на 50 микросервисов. Я подожду.
Когда библиотеки трассировки подводят
Возьмем типичный стек: Flask-приложение вызывает Anthropic API, а также общается с MCP-сервером для доступа к базе данных. Чтобы отслеживать это через Langfuse или аналоги, нужно обернуть три разные библиотеки. Одна ошибка - и вы теряете часть трассировки. eBPF-трассировщик просто смотрит на системные вызовы. Ему все равно, на чем написано приложение - Rust, Go, Python, даже двоичный файл на C.
Примеры из жизни: где это работает
3Продакшн-хаос с микросервисами
У одной команды было 12 сервисов, каждый звонил в OpenAI, Anthropic и использовал MCP для доступа к внутренним API. Счета за облако росли экспоненциально. За день с eBPF-трассировщиком они обнаружили, что один сервис в фоновом режиме делал вызовы к GPT-5 каждые 30 секунд «на всякий случай». Без изменения кода они увидели полную картину и срезали затраты на 40%.
4Отладка медленных вызовов к Claude 3.5
Пользователи жаловались, что агент «задумывается» по 20 секунд. Инструмент показал, что задержка была не в API Claude, а в MCP-вызове к инструменту поиска в документации, который сам делал запросы к внешнему API. Без этого мониторинга команда бы месяцами искала проблему в коде агента.
Актуальность на 12.03.2026: последняя версия трассировщика поддерживает GPT-5 Turbo (релиз январь 2026), Claude 4.5 (февраль 2026), Llama-4 Scout и все известные MCP-транспорты (HTTP, Unix sockets, gRPC). Экспорт идет напрямую в OpenTelemetry Collector, откуда данные можно отправить в Jaeger, Prometheus или коммерческие платформы.
Кому это нужно (а кому нет)
Этот инструмент - не для всех. Если у вас один скрипт на Python, который раз в день вызывает ChatGPT, не усложняйте. Но есть категории, где без eBPF уже нельзя.
DevOps-инженеры и SRE
Вы отвечаете за работу продакшн-агентов? Вам нужен мониторинг, который не сломается после очередного обновления клиентской библиотеки. eBPF работает на уровне ядра, поэтому обновления приложений его не касаются. Плюс, вы получаете метрики для алертинга: «если затраты на GPT-5 превысили $1000 за час - бей тревогу».
Разработчики AI-агентов
Вы строите сложные агенты с использованием MCP для безопасности? Вам критично понимать, какие инструменты вызываются чаще всего, где узкие места. Трассировщик покажет полный граф вызовов: от промпта пользователя до ответа LLM и действий через MCP. Это бесценно для отладки.
Кому не подойдет: пользователям Windows (только Linux с ядром 5.8+), тем, у кого нет прав на установку eBPF-программ (нужен root или CAP_BPF), командам с параноидальной политикой безопасности (некоторые CISO боятся всего, что работает в ядре).
Будущее: eBPF как стандарт для AI-observability
К 2027 году, по моему прогнозу, каждый крупный поставщик LLM-инфраструктуры будет включать eBPF-агент в свои дистрибутивы. Зачем? Потому что традиционные методы не справляются с динамичностью AI-стэка. Новые модели выходят каждые полгода, протоколы вроде MCP развиваются (посмотрите на скрытые угрозы MCP), а продакшен не может ждать, пока вы перепишете инструментацию.
Совет напоследок: если вы только начинаете внедрять LLM в продакшен, не закладывайте в архитектуру жесткую привязку к библиотекам мониторинга. Оставьте заднюю дверь в виде eBPF. Когда в 3 часа ночи сломается агент, использующий MCP-context-proxy, вы скажете себе спасибо.
