Как следить за агентом: логи, трейсы и метрики LLM-приложений

Обычное приложение падает с понятной ошибкой в логе. Агент на большой языковой модели ведёт себя иначе: он не падает, а тихо делает не то. Вызвал не тот инструмент, зациклился на пяти шагах вместо двух, получил из базы мусор и уверенно построил на нём ответ. Стектрейса нет, есть только счёт за токены и недовольный пользователь. Отсюда за последние два года вырос отдельный класс инструментов — LLM observability, то есть наблюдаемость за поведением моделей и агентов. Разберём, что именно они показывают, чем отличаются четыре популярных решения и когда хватит одного OpenTelemetry без специализированного сервиса.

Что вообще нужно видеть в работе агента

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

• Трейс запуска — дерево из шагов: какой промпт ушёл в модель, что она ответила, какой инструмент вызвала, что вернул инструмент, и так до финального ответа.
• Токены и стоимость — сколько токенов на входе и выходе на каждом шаге, во сколько это обошлось в деньгах.
• Латентность по шагам — где именно ушло время: в модели, в вызове внешнего API или в retrieval.
• Ошибки и ретраи — таймауты, отказы инструментов, повторные попытки.
• Оценка качества — фидбэк пользователя (палец вверх/вниз) и автоматические проверки ответов.

Ключевое отличие от привычного трейсинга — единица наблюдения. В микросервисах это HTTP-запрос. В агенте это trace из вложенных span¹, где каждый span — либо вызов модели (generation), либо вызов инструмента, либо retrieval-шаг.

¹ Trace и span

Trace — полная запись одного запуска от входа до ответа. Span — отдельный шаг внутри него со своими временем начала, длительностью и атрибутами. Термины пришли из распределённого трейсинга и стандартизированы в OpenTelemetry.

Открытый стандарт: OpenTelemetry и GenAI-семантика

OpenTelemetry (OTel) — вендоронезависимый стандарт сбора трейсов и метрик, к которому умеет подключаться почти любой бэкенд наблюдаемости. В 2024 году в OTel начали формировать GenAI semantic conventions — набор соглашений о том, как называть атрибуты span'ов для LLM: gen_ai.request.model, gen_ai.usage.input_tokens, gen_ai.usage.output_tokens и подобные. Конвенции на момент написания в статусе экспериментальных, детали ещё меняются — сверяйтесь с актуальной документацией.

Практический смысл: если ваш агент инструментирован через OTel, вы не привязаны к одному вендору. Данные можно слать в Langfuse, в Phoenix, в собственный Grafana Tempo или в облачную APM-систему — меняется только экспортёр, а код инструментирования остаётся. Специализированные LLM-платформы всё чаще принимают трейсы именно по OTel-протоколу (OTLP).

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

Четыре инструмента, которые реально используют

Рынок LLM observability на начало 2025 года держится на нескольких проектах. Три из них имеют открытый исходный код и вариант self-hosted, один — облачный от авторов LangChain.

Точные тарифы облачных версий LangSmith и Langfuse меняются, и привязывать их к конкретной цифре здесь бессмысленно — проверяйте актуальные планы на официальных страницах. У всех троих специализированных решений есть бесплатный тариф для старта и self-hosted вариант, который стоит только вашей инфраструктуры.

Как это выглядит на практике

Идея у всех похожа: вы оборачиваете вызовы модели и инструментов декоратором или колбэком, а SDK отправляет span'ы в бэкенд. В LangChain это обычно колбэк-хендлер, в произвольном коде — декоратор над функцией. В интерфейсе вы потом видите дерево запуска: где модель выбрала инструмент, что он вернул, сколько токенов ушло и где просела латентность.

Отдельный слой — оценка (evaluation). Вы собираете датасет типичных запросов, прогоняете через агента и оцениваете ответы: правилами, отдельной моделью-судьёй или разметкой человеком. Это превращает observability из посмертного разбора в регрессионное тестирование: перед выкатом нового промпта видно, стало лучше или хуже на контрольной выборке.

Кому это пригодится, а кому нет

Пригодится, если:

• У вас агент с несколькими шагами и вызовом инструментов, и вы не понимаете, почему на части запросов он ведёт себя странно.
• Счёт за токены растёт, и нужно найти, какой шаг или какой пользовательский сценарий его раздувает.
• Вы часто меняете промпты и хотите видеть, не сломала ли правка то, что работало вчера.
• Продукт в продакшене, и нужен фидбэк пользователей, привязанный к конкретным трейсам.

Скорее не нужно, если:

• У вас один прямой вызов модели без цепочек и инструментов — тогда хватит обычного логирования запрос-ответ и счётчика токенов.
• Это разовый прототип на выходные, который не поедет в прод.
• Все запросы идут через одного облачного провайдера, чья консоль уже показывает нужную вам аналитику расходов.

Что решить перед внедрением

1. Стандарт инструментирования. По возможности — OpenTelemetry/OTLP, чтобы не переписывать код при смене платформы.
2. Облако или self-host. Если в трейсы попадают персональные данные или коммерческая тайна, взвесьте self-hosted вариант: промпты и ответы модели уходят на сервис целиком.
3. Сэмплирование. На высоком трафике писать каждый трейс дорого по хранилищу — заранее решите, какую долю запусков сохранять и сохранять ли проблемные целиком.
4. Ретеншн и приватность. Сколько хранить трейсы с пользовательским вводом и как их маскировать.

Главный совет — не откладывать трейсинг до первого крупного инцидента. Инструментировать агента дешевле на старте, когда шагов мало, чем разматывать продакшен-баг по логам, в которых нет ни промптов, ни дерева вызовов.