Мультиоблачная наблюдаемость AgentCore: что на самом деле делает ADOT

Если вы запускаете агентов на Strands, LangGraph или CrewAI в продакшне прямо сейчас, велика вероятность, что они не собраны в одном месте. Одни живут в EKS, другие в Lambda, третьи в GCP-проекте, которым владеет ваша команда по данным, а один злополучный пилот до сих пор крутится на виртуальной машине под чьим-то столом. AWS только что опубликовал схему подключения для сбора телеметрии со всех этих источников в единый дашборд — и стоит внимательно её изучить, прежде чем вы на неё ориентируетесь.

В чём проблема

Amazon Bedrock AgentCore Observability, как описывает Amazon Web Services (AWS), обеспечивает нативную трассировку, мониторинг и аналитику для агентов — но нативная поддержка распространяется только на агентов, развёрнутых в рантайме AgentCore внутри AWS Cloud. Всё остальное — EKS, ECS, Lambda, on-prem, GCP и Azure — требует ручной инструментации, чтобы телеметрия попала в тот же дашборд. Этот пробел и закрывает данная статья.

Инженерная проблема в основе всего этого знакома каждому, кто пытался централизовать наблюдаемость в нескольких облаках. Агентские фреймворки генерируют спаны разной формы. Strands, LangGraph и CrewAI по-своему понимают, как выглядит «шаг рассуждения» или «вызов инструмента». Вызовы моделей через boto3 добавляют ещё один уровень. Без единых семантических соглашений ваш дашборд в итоге оказывается тремя дашбордами в одном плаще, и вы не можете ответить на базовые вопросы о стоимости или безопасности в разных окружениях.

Ограничение, которое действительно сдвинулось, находится на стороне вендора. AgentCore Observability поддерживает Strands, LangGraph и CrewAI как первоклассные фреймворки — но только если агенты работают на рантайме AgentCore. Это узкая поверхность развёртывания. Большинство команд, с которыми я общаюсь, имеют хотя бы одного агента за пределами этой модели — зачастую по причинам задержки, резидентности данных или уже сделанных платформенных инвестиций. Поэтому AWS теперь говорит таким командам: используйте путь через OpenTelemetry, и мы примем данные.

Источник не раскрывает поустановочную цену за запрос на CloudWatch OTLP endpoint в этом руководстве — а это важно, потому что агентские нагрузки могут генерировать десятки спанов за один пользовательский запрос. Мы не знаем реальной стоимости одного агент-часа по этой схеме, но верхняя граница — это то, во сколько обходится приём данных CloudWatch Logs и X-Ray при вашем объёме спанов. Эту цифру нужно просчитать, прежде чем включать всё это на весь флот.

Доступные варианты

Сегодня существует четыре основных способа инструментировать мультиоблачный флот агентов, и описываемый AWS-паттерн — один из них.

Вариант 1: паттерн AWS, описанный здесь. Запустите aws-opentelemetry-distro (минимальная версия 0.10.0) в процессе с вашим агентом, используйте opentelemetry-instrument для внедрения автоинструментации в Python-рантайм и экспортируйте через SigV4 на CloudWatch OTLP endpoint. ADOT автоматически патчит boto3 для вызовов Bedrock и патчит фреймворк Strands для спанов рассуждений агентов. Вы получаете дашборд AgentCore, и всё маршрутизируется через CloudWatch как основу приёма и хранения. Требует девяти конкретных IAM-разрешений в scopes bedrock, logs, xray и cloudwatch.

Вариант 2: чистый OpenTelemetry в нейтральный бэкенд. Направьте агентов на self-hosted или SaaS OTel-коллектор (Grafana Tempo, Honeycomb, Datadog, Signoz), используя те же семантические соглашения OTel для генеративного ИИ. Вы теряете специфические для AgentCore виды дашборда, но не платите за приём в CloudWatch для агентов, которые и так живут вне AWS, и сохраняете портативность бэкенда наблюдаемости. Компромисс: нет нативного представления «цепочки рассуждений агента», если ваш вендор его не реализовал.

Вариант 3: нативная телеметрия фреймворка. LangGraph имеет LangSmith. У CrewAI есть собственная трассировка. Strands генерирует спаны в формате OpenTelemetry через пакет strands-agents[otel] по семантическим соглашениям для генеративного ИИ, включая шаги рассуждений, вызовы инструментов и вызовы моделей с информацией о токенах. Самый дешёвый вариант настройки для каждого фреймворка, но в итоге у вас N дашбордов для N фреймворков — именно та проблема фрагментации, которую вы пытались решить.

Вариант 4: ничего централизованного, логирование локально. До сих пор дефолтный выбор удивительно большого числа команд. Нормально для прототипа, неприемлемо в продакшне, как только агенты начинают делать вызовы инструментов, затрагивающих платежи, пользовательские данные или сторонние API.

Реальный выбор — между паттерном AWS и чистым OTel. Если ваш центр тяжести уже на AWS и вы хотите специфические для AgentCore представления цепочки рассуждений агента — это более короткий путь. Если ваш центр тяжести в GCP или Azure и вы обращаетесь в AWS только за доступом к моделям Bedrock, платить CloudWatch за роль бэкенда наблюдаемости — странный выбор, который нужно явно обосновать. Источник не раскрывает, будет ли когда-либо дашборд AgentCore принимать телеметрию из бэкендов, не являющихся CloudWatch, — а это важно, потому что ответ на этот вопрос определяет, является ли это мостом или воронкой.

Что реально делать инженерным командам

Моя точка зрения: если вы уже используете модели Bedrock для инференса, принятие этого паттерна для ваших не-AWS-агентов — разумный ближайший шаг, но относитесь к истории с учётными данными как к ключевому решению, а не к сантехнике SigV4.

В руководстве используются AWS_ACCESS_KEY_ID и AWS_SECRET_ACCESS_KEY как переменные окружения — нормально для демонстрации на ноутбуке и неприемлемо для продакшн-флота, работающего на узлах GCP и on-prem-хостах. Сам пост рекомендует IAM Roles Anywhere для продакшна, что позволяет on-prem-нагрузкам получать временные учётные данные с помощью сертификатов X.509. Это правильное решение, и оно должно быть вашей настройкой с первого дня, а не миграцией на девяностый день. Развернуть PKI для выпуска этих сертификатов — реальная работа, и если у вас её нет, это и есть настоящий проект, а не установка ADOT.

Для самой инструментации установка — это одна строка: pip install "aws-opentelemetry-distro>=0.10.0" boto3 "strands-agents[otel]". Добавьте девять IAM-разрешений, выполните одноразовую команду aws xray update-trace-segment-destination --destination CloudWatchLogs --region us-east-1 для включения Transaction Search, проверьте вызовом get-destination (ожидается {"Destination": "CloudWatchLogs", "Status": "ACTIVE"}) — и вы подключены.

Перед развёртыванием на весь флот сделайте расчёт стоимости. Инструментируйте одного репрезентативного агента, прогоните его с реалистичной нагрузкой неделю, посмотрите счёт CloudWatch по этой группе логов и умножьте. Если цифра выглядит плохо — вернитесь к сэмплированию или перейдите на Вариант 2. Предсказуемый результат: команды, развернувшие этот паттерн без стратегии сэмплирования, увидят нелинейный рост счёта CloudWatch по мере роста числа вызовов агентов уже в первый расчётный период. Если этого не произойдёт — либо у вас низкий трафик, либо вам повезло с дефолтными настройками сэмплирования.

Подводные камни и граничные случаи

Несколько вещей, на которые стоит обратить внимание в описанной настройке.

Заголовок OTEL_EXPORTER_OTLP_LOGS_HEADERS — это то, что направляет логи в конкретную группу логов AgentCore, чтобы CloudWatch индексировал их в дашборде наблюдаемости ИИ. Ошибитесь здесь — и ваша телеметрия поступит, но не появится в дашборде, ради которого вы всё это затеяли. Это будет выглядеть как ошибка приёма, хотя на самом деле это ошибка маршрутизации.

Автоинструментация патчит boto3 и фреймворк Strands конкретно. Если ваш агент использует кастомный HTTP-клиент для обращения к Bedrock, или форк Strands, или оборачивает LangGraph способом, который автоинструментация ADOT не распознаёт — вы получите частичные трейсы. Источник явно описывает патчинг для Strands и упоминает LangGraph и CrewAI как поддерживаемые фреймворки, но руководство демонстрирует только Strands с Claude Haiku. Мы не знаем, насколько полна автоинструментация для LangGraph и CrewAI относительно Strands — этот пробел стоит измерить, прежде чем стандартизировать.

Требуется Python 3.10 или выше. Если у вас агенты привязаны к 3.9 по причинам совместимости — это блокирующее обновление.

Наконец, исходящий HTTPS до эндпоинтов AWS — обязательное условие. В регулируемых on-prem-окружениях, где исходящий трафик проксируется или ограничивается, ожидайте проверку безопасности, прежде чем ADOT сможет обращаться к CloudWatch OTLP endpoint. Такая проверка обычно занимает больше времени, чем изменение кода.

Ключевые выводы

• AgentCore Observability теперь имеет задокументированный путь для агентов, работающих на EKS, ECS, Lambda, on-prem, GCP и Azure через автоинструментацию ADOT и SigV4 на CloudWatch OTLP endpoint.
• Установка проста (aws-opentelemetry-distro>=0.10.0, boto3, strands-agents[otel], плюс девять IAM-разрешений), но история с учётными данными — это реальная работа: используйте IAM Roles Anywhere с сертификатами X.509, а не долгоживущие ключи доступа.
• Включите CloudWatch Transaction Search один раз на аккаунт с помощью задокументированной команды X-Ray и убедитесь, что видите Status: ACTIVE, прежде чем инструментировать что-либо.
• Рассчитайте стоимость приёма данных CloudWatch относительно реального объёма спанов до развёртывания на весь флот. Агентские нагрузки генерируют много спанов за один запрос, а источник не раскрывает поспановую цену для этого пути.
• Руководство демонстрирует только Strands с Claude Haiku. LangGraph и CrewAI заявлены как поддерживаемые, но полнота автоинструментации для этих фреймворков — открытый вопрос, который стоит проверить в собственном окружении.