Мониторинг LLM-агентов в продакшене: что ловить и как

Почему обычного APM здесь мало

Классический мониторинг веб-сервиса отвечает на вопрос «жив ли эндпоинт»: латентность, коды ответов, потребление CPU. Для LLM-агента этих метрик недостаточно, потому что HTTP-запрос вернул 200 OK, а внутри агент десять раз вызвал один и тот же инструмент, пришёл к неверному выводу и потратил в четыре раза больше токенов, чем закладывалось в юнит-экономику.

Агент — это цикл: модель получает контекст, решает вызвать инструмент, получает результат, снова думает. Один пользовательский запрос разворачивается в дерево из десятков вызовов модели и внешних API. Мониторить надо не только вход и выход, но и всё, что происходит между ними — иначе отладка сводится к чтению логов вручную по одному инциденту за раз.

Три уровня наблюдаемости

• Трейс¹ — полный путь одного запроса: от сообщения пользователя до финального ответа, со всеми промежуточными шагами.
• Спан — один шаг внутри трейса: вызов модели, обращение к вектор-базе, запуск инструмента. У спана есть длительность, вход, выход и статус.
• Метрика — агрегат поверх множества трейсов: медианная стоимость запроса, доля зацикливаний, p95 латентности.

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

Метрики агента делятся на четыре группы. Первые три вы можете собрать без разметки данных, четвёртая требует либо человека, либо второй модели-судьи.

Стоимость и токены

Самая недооценённая метрика. Считайте не среднюю стоимость запроса, а распределение: среднее скрывает хвост, где 2% запросов уходят в длинный цикл и стоят в десять раз дороже остальных. Логируйте на каждый вызов модели: количество входных и выходных токенов, модель, цену. Отдельно — число шагов в трейсе. Резкий рост среднего числа шагов почти всегда означает, что агент застрял.

Латентность по спанам

Общее время ответа бесполезно, пока вы не разложили его на составляющие. Медленно из-за модели, из-за медленного внешнего API или из-за того, что агент делает лишние итерации — это три разные проблемы с тремя разными решениями. Смотрите латентность отдельно по типам спанов.

Надёжность инструментов

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

Качество ответов

Самое сложное. Автоматически без разметки его не измерить полностью, но частичные сигналы собрать можно: доля ответов, где сработал fallback; доля, где пользователь переспросил или нажал «не помогло»; проверки формата, если ответ должен быть валидным JSON или содержать обязательные поля.

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

Инструменты

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

Прокси-подход (как у Helicone) даёт мониторинг ценой одной строки конфига, но добавляет сетевой хоп на пути каждого запроса. SDK-подход (Langfuse, Phoenix) требует инструментировать код, зато не влияет на латентность и даёт больше контроля над тем, что попадает в трейс.

Минимальная инструментация на Python

Библиотеки экспортируют трейсы через декоратор или контекстный менеджер. Общий паттерн — обернуть каждый шаг агента в спан и прикрепить к нему метаданные:

from langfuse.decorators import observe, langfuse_context

@observe()
def call_tool(name: str, args: dict) -> str:
    result = registry[name](**args)
    langfuse_context.update_current_observation(
        metadata={"tool": name, "ok": result is not None}
    )
    return result

@observe()
def agent_step(messages: list) -> dict:
    resp = client.chat.completions.create(
        model="gpt-4o-mini", messages=messages
    )
    # usage прилетает в ответе провайдера — логируйте его
    langfuse_context.update_current_observation(
        usage_details={
            "input": resp.usage.prompt_tokens,
            "output": resp.usage.completion_tokens,
        }
    )
    return resp

Точные имена методов и полей меняются между версиями SDK — сверяйтесь с актуальной документацией выбранного инструмента, приведённый код показывает принцип, а не готовый к копированию продакшен-модуль.

Алерты, которые реально спасают

Дашборд, на который никто не смотрит, инцидент не предотвратит. Настройте алерты на аномалии, а не на пороги «навсегда»:

1. Стоимость запроса выше p99 за прошлую неделю — ловит зацикливания и раздувшийся контекст раньше, чем это заметит финансовый отдел.
2. Число шагов в трейсе выше нормы — прямой признак того, что агент не сходится.
3. Рост доли ошибок конкретного инструмента — деградация внешнего API до того, как она обрушит качество ответов.
4. Всплеск fallback-ответов — модель перестала справляться, возможно, из-за смены версии на стороне провайдера.

Про приватность

Трейсы содержат полный вход и выход модели, а значит — потенциально персональные данные пользователей и внутренние документы компании. Прежде чем включать полное логирование, решите: маскируете ли вы PII на входе в систему наблюдаемости, где физически хранятся трейсы и кто к ним имеет доступ. Self-host снимает часть этих вопросов ценой эксплуатации инфраструктуры.

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

¹ Трейс (trace) — запись полного пути одного запроса через систему, состоящая из вложенных спанов. Термин пришёл из распределённого трейсинга (Jaeger, Zipkin) и был адаптирован под LLM-приложения.