LLM observability: как мониторить AI-агента в production

Инцидент есть. Логи тоже есть. В них пять prompt, три tool call и строка `success=true`. Сделка в CRM почему-то не создалась.

Это плохая наблюдаемость. Мы записали активность AI, но не можем восстановить бизнес-операцию. LLM observability для меня начинается с возможности восстановить одну бизнес-операцию от входа до фактического внешнего результата.

Для агента мне нужен trace от входного события до конечного state: какой запрос пришёл, какой decision был принят, какой tool вызван, что вернул внешний сервис, были ли retries и какой side effect действительно сохранился. Остальное вторично.

Начните с одного correlation ID

User request, async event, model call и внешние API быстро разъезжаются по разным сервисам. Без общего identifier склеивать их приходится по времени и догадкам.

Я бы создавал correlation/process ID на входе и передавал его через orchestration, tool gateway и внутренние API. Внешний provider request ID можно сохранять как отдельный атрибут, но он не заменяет наш process ID.

Тогда один trace отвечает на простой вопрос: что происходило с конкретной бизнес-операцией.

Проверяемые источники: OpenTelemetry — OpenTelemetry Semantic Conventions

Trace, metrics и audit log не нужно смешивать

Trace показывает причинную цепочку одной операции. Metrics агрегируют поведение: latency, error rate, token usage, tool failures. Audit log отвечает на вопросы контроля: кто или что совершило действие, с какими полномочиями и какой объект изменило.

Можно строить их из общих событий, но требования разные. Audit запись должна быть устойчивой и пригодной для расследования. Trace может иметь sampling. Metrics вообще не хранят каждую операцию.

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

Проверяемые источники: OpenTelemetry — Inside the LLM Call: GenAI Observability with OpenTelemetry · OpenTelemetry — OpenTelemetry Semantic Conventions

MEDIA FRAME · PLACEHOLDERИллюстрация будет добавлена позже

Model call логируется как компонент, а не как вся система

Для model invocation полезны provider/model identifier, latency, status, token usage или другая доступная cost signal, версия prompt/config и ссылка на разрешённый input context. Полное содержимое prompt хранить всегда — плохой default.

OpenTelemetry развивает GenAI semantic conventions и observability patterns для model operations. Я бы использовал стандартные attributes там, где они подходят, и добавлял доменные поля отдельно.

Главное — не делать model response единственным outcome. После него агент ещё может вызвать tool, policy может отклонить действие, а внешний API — упасть.

Проверяемые источники: OpenTelemetry — Inside the LLM Call: GenAI Observability with OpenTelemetry · OpenTelemetry — OpenTelemetry Semantic Conventions

Tool call должен заканчиваться фактическим outcome

`tool=createDeal` мало полезно. Мне нужны sanitized параметры или их digest, target system, idempotency key, attempt, latency, response status и external object ID после успеха.

Если tool асинхронный, trace должен связать enqueue и completion. Если был retry — попытки остаются дочерними spans, а логический operation outcome один.

Для MCP или другого tool protocol полезно фиксировать server/tool identifier и protocol/version metadata. Но доменный результат — например `deal_id=9021` — всё равно важнее протокольного success.

Проверяемые источники: Model Context Protocol — Model Context Protocol Specification 2026-07-28 · OpenTelemetry — OpenTelemetry Semantic Conventions

Секреты и лишний PII в observability не помогают диагностике

Access token в log помогает примерно один раз. Потом начинается incident другого типа.

Я бы маскировал credentials всегда, ограничивал customer content до реально нужных фрагментов и предпочитал identifiers полным payload. Для расследования можно иметь отдельный защищённый доступ к исходным данным, а не дублировать их во всех telemetry systems.

Не нужно сохранять скрытые внутренние рассуждения модели. Для диагностики достаточно разрешённого входа, конфигурации, структурированного решения, tool calls и наблюдаемого outcome.

Проверяемые источники: OWASP GenAI Security Project — Agentic AI — Threats and Mitigations

Дашборд должен показывать failure path, а не количество запросов

Я бы начал с tool failure rate, retries, timeout rate, end-to-end latency, доли manual fallback, незавершённых operations и cost на корректный outcome. Token count сам по себе мало говорит о здоровье процесса.

Alert лучше привязывать к пользовательскому или бизнес-эффекту. Например: выросла доля операций без terminal state, circuit breaker открыт больше допустимого времени, tool errors превысили baseline. Просто «LLM latency +20%» иногда вообще не требует ночного звонка.

После инцидента trace должен позволить за несколько минут ответить: что произошло, где остановилось и какой внешний state остался. Если для этого нужно читать тридцать несвязанных логов, observability пока декоративная.

Проверяемые источники: OpenTelemetry — Inside the LLM Call: GenAI Observability with OpenTelemetry · OpenTelemetry — OpenTelemetry Semantic Conventions

Sampling нельзя применять одинаково к успехам и ошибкам

На большом трафике хранить каждый подробный trace дорого. Sampling нормален. Но я бы почти всегда сохранял failures, policy denials, manual fallbacks и unusually slow operations с большей вероятностью, чем обычный success.

При tail sampling решение можно принять после того, как известен outcome. Тогда редкая ошибка не исчезнет только потому, что trace случайно не попал в выборку на входе.

Метрики при этом остаются полными агрегатами. Sampling trace не должен превращать error rate в художественную оценку.

Проверяемые источники: OpenTelemetry — Inside the LLM Call: GenAI Observability with OpenTelemetry · OpenTelemetry — OpenTelemetry Semantic Conventions

Короткие вопросы перед production

Что логировать у AI-агента?

Correlation ID, версию конфигурации, model/tool calls, latency, retries, policy decision и конечный business outcome. Полный prompt и payload нужны далеко не всегда.

Нужно ли хранить chain of thought модели?

Нет. Для production-диагностики опирайтесь на доступный входной контекст, структурированные решения, вызовы инструментов и наблюдаемые результаты. Скрытые рассуждения не являются нормальным audit contract.

Чем audit log отличается от trace?

Trace нужен для причинной диагностики одной операции. Audit log фиксирует значимые действия и полномочия для контроля. У них может быть общий источник событий, но разные требования к хранению и полноте.

Хороший trace не рассказывает мне, что агент «думал долго». Он показывает, что пришло, какой контракт сработал, какой tool что изменил и где закончился процесс. Если это видно без археологии по логам — мониторинг делает свою работу.

Смежные контуры, которые стоит прогнать отдельно для «LLM observability»: Как вести журнал действий AI-агента · Какие KPI показывать на дашборде AI-системы · Как перенести AI-автоматизацию с прототипа в рабочую систему.