Саммари доклада с Infraconf 2026. Часть 2 про практику
Продолжаю саммари доклада — теперь про практические шаги. Вот у вас появились агенты в продакшене. А что именно можно сделать прямо уже хоть завтра, чтобы начать их мониторить?
В докладе я предлагал смотреть на подход к этой теме как на некую пирамиду зрелости - начинаем с простого и движемся к комплексному. Итак, снизу вверх:
1. Экологически чистые материалы (aka говно и палки)
Если у вас уже есть какие-то AI-агенты, мой первый совет банален до неприличия: разберитесь, куда они вообще пишут логи, если пишут. А если не пишут — пусть начинают, включите их в SDK этих агентов.
Да, логи могут быть слишком verbose. Да, они могут быть кривые, косые, улетать в stdout или в какой-нибудь файлик, НО лучше хоть какие-то логи, чем вообще никакие. Потому что в момент сбоя такие логи хотя бы дают шанс понять, что вообще пошло не так. А если даже таких логов нет, то на что надеяться?
Плюсы: легко реализовать, появляется хоть какая-то телеметрия
Минусы: очень тяжело дебажать, не получите алерты и метрики
2. Автоинструментация через OpenTelemetry + привычные инструменты мониторинга
Следующий уровень - подключить ваших агентов к привычным инструментам вроде Grafana или Jaeger и включить автоинструментацию OpenTelemetry, чтобы агент начал сам отдавать базовые сигналы из коробки. Автоинструментация - это когда вы подключаете SDK, например, от OpenTelemetry и включаете автоматический сбор телеметрии. Дальше SDK само под капотом собирает метрики, логи и трейсы без изменений в коде. На то оно и АВТОинструментация.
Из практики тут есть важный нюанс: в свежих OTel-инструментациях трекинг больших текстов (промтов, ответов модели т.д.) отключен по умолчанию, и если его не включить руками, то самые ценные данные для дебага вы просто не увидите. За это поведение отвечает переменная среды OTEL_INSTRUMENTATION_GENAI_CAPTURE_MESSAGE_CONTENT
Плюсы: используете знакомые инструменты мониторинга, появляются все базовые сигналы (метрики, логи и трейсы)
Минусы: привычные инструменты не адаптированы под AI-контекст - тяжело дебажить, автоматическая инструментация не покроет бизнес-логику.
3. Специализированные инструменты
Следующий уровень - использовать специальные штуки для мониторинга AI-агентов. В докладе я приводил в пример Langfuse: это open source-платформа, в которой есть трейсы, evals, версионирование промптов и прочие полезные штуки для agentic-сценариев. Облачная версия нам сейчас недоступна, но self-hosted вариант у них вполне живой и отлично работает. Подключаете SDK к своему агенту, поднимаете Langfuse на своей инфре - и вот у вас отличный инструмент для базового мониторинга агентов.
Плюсы: open source, специализированный продуманный инструмент
Минусы: vendor-lock на SDK и формат Langfuse.
Итак, вершина пирамиды.
4. Monium от Яндекса
Да, это тот самый продукт, менеджером которого я являюсь. И, да, в утверждении про вершину пирамиды есть доля иронии:)
Но если говорить серьзно, то в Monium сейчас два главный плюса для задачи мониторинга агентов:
- отсутсвие vendor-lock, полностью OpenTelemetry-native формат. Это значит, что нет зависимости от вендора, как в случае в Langfuse - данные текут стандартном формате, а значит на решение легко заехать, и также легко съехать, если не зашло.
- хорошая адаптация UI для просмотра трейсов с большими текстами (промпты, ответы модели). Можно ломать глаза, рассматривая json-ы в спанах, а можно в адаптированном UI сразу смотреть на историю сообщений, входные и выходные параметры тулов и детали в более человеческом виде.
Больше я о нем не говорил в докладе, и тут тоже не оч хочу. Кому интересно, вот тут можно посмотреть лендос.
Штош, вот такое саммари доклада.
Продолжаю саммари доклада — теперь про практические шаги. Вот у вас появились агенты в продакшене. А что именно можно сделать прямо уже хоть завтра, чтобы начать их мониторить?
В докладе я предлагал смотреть на подход к этой теме как на некую пирамиду зрелости - начинаем с простого и движемся к комплексному. Итак, снизу вверх:
1. Экологически чистые материалы (aka говно и палки)
Если у вас уже есть какие-то AI-агенты, мой первый совет банален до неприличия: разберитесь, куда они вообще пишут логи, если пишут. А если не пишут — пусть начинают, включите их в SDK этих агентов.
Да, логи могут быть слишком verbose. Да, они могут быть кривые, косые, улетать в stdout или в какой-нибудь файлик, НО лучше хоть какие-то логи, чем вообще никакие. Потому что в момент сбоя такие логи хотя бы дают шанс понять, что вообще пошло не так. А если даже таких логов нет, то на что надеяться?
Плюсы: легко реализовать, появляется хоть какая-то телеметрия
Минусы: очень тяжело дебажать, не получите алерты и метрики
2. Автоинструментация через OpenTelemetry + привычные инструменты мониторинга
Следующий уровень - подключить ваших агентов к привычным инструментам вроде Grafana или Jaeger и включить автоинструментацию OpenTelemetry, чтобы агент начал сам отдавать базовые сигналы из коробки. Автоинструментация - это когда вы подключаете SDK, например, от OpenTelemetry и включаете автоматический сбор телеметрии. Дальше SDK само под капотом собирает метрики, логи и трейсы без изменений в коде. На то оно и АВТОинструментация.
Из практики тут есть важный нюанс: в свежих OTel-инструментациях трекинг больших текстов (промтов, ответов модели т.д.) отключен по умолчанию, и если его не включить руками, то самые ценные данные для дебага вы просто не увидите. За это поведение отвечает переменная среды OTEL_INSTRUMENTATION_GENAI_CAPTURE_MESSAGE_CONTENT
Плюсы: используете знакомые инструменты мониторинга, появляются все базовые сигналы (метрики, логи и трейсы)
Минусы: привычные инструменты не адаптированы под AI-контекст - тяжело дебажить, автоматическая инструментация не покроет бизнес-логику.
3. Специализированные инструменты
Следующий уровень - использовать специальные штуки для мониторинга AI-агентов. В докладе я приводил в пример Langfuse: это open source-платформа, в которой есть трейсы, evals, версионирование промптов и прочие полезные штуки для agentic-сценариев. Облачная версия нам сейчас недоступна, но self-hosted вариант у них вполне живой и отлично работает. Подключаете SDK к своему агенту, поднимаете Langfuse на своей инфре - и вот у вас отличный инструмент для базового мониторинга агентов.
Плюсы: open source, специализированный продуманный инструмент
Минусы: vendor-lock на SDK и формат Langfuse.
Итак, вершина пирамиды.
4. Monium от Яндекса
Да, это тот самый продукт, менеджером которого я являюсь. И, да, в утверждении про вершину пирамиды есть доля иронии:)
Но если говорить серьзно, то в Monium сейчас два главный плюса для задачи мониторинга агентов:
- отсутсвие vendor-lock, полностью OpenTelemetry-native формат. Это значит, что нет зависимости от вендора, как в случае в Langfuse - данные текут стандартном формате, а значит на решение легко заехать, и также легко съехать, если не зашло.
- хорошая адаптация UI для просмотра трейсов с большими текстами (промпты, ответы модели). Можно ломать глаза, рассматривая json-ы в спанах, а можно в адаптированном UI сразу смотреть на историю сообщений, входные и выходные параметры тулов и детали в более человеческом виде.
Больше я о нем не говорил в докладе, и тут тоже не оч хочу. Кому интересно, вот тут можно посмотреть лендос.
Штош, вот такое саммари доклада.