AgentCore Observability у мультихмарному середовищі: що насправді робить ADOT

Якщо ви запускаєте агентів Strands, LangGraph або CrewAI у продакшені, є великий шанс, що вони розміщені не в одному місці. Одні — в EKS, інші — в Lambda, ще частина — у GCP-проєкті вашої команди з даних, а один незручний пілот досі працює на VM під чиїмось столом. AWS щойно опублікувала схему підключення телеметрії з усіх цих середовищ до єдиного дашборду, і варто уважно її вивчити, перш ніж брати на себе зобов'язання.

Проблема

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

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

Обмеження, яке насправді змінилося, знаходиться на боці вендора. AgentCore Observability підтримує Strands, LangGraph і CrewAI як першокласні фреймворки, але лише якщо агенти працюють на AgentCore runtime. Це вузька поверхня розгортання. Більшість команд, з якими я спілкуюся, мають принаймні одного агента, що працює поза цим контуром — часто через вимоги до затримки, резидентності даних або вже зроблені інвестиції в платформу. Тому AWS тепер говорить цим командам: використовуйте шлях OpenTelemetry, і ми будемо інгестувати дані.

Джерело не розкриває ціну інгестії за запит для CloudWatch OTLP endpoint у цьому посібнику, а це важливо, оскільки агентні навантаження можуть генерувати десятки спанів на один хід користувача. Ми не знаємо ефективну вартість за агент-годину за цією схемою, але верхня межа — це те, скільки коштує інгестія CloudWatch Logs і X-Ray при вашому обсязі спанів, і це число потрібно змоделювати, перш ніж вмикати все для цілого флоту.

Варіанти на вибір

Сьогодні існує, по суті, чотири способи інструментувати мультихмарний флот агентів, і цей патерн AWS — один із них.

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

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

Варіант 3: Нативна телеметрія фреймворку. LangGraph має LangSmith. CrewAI має власне трасування. Strands генерує спани у форматі OpenTelemetry через пакет strands-agents[otel], дотримуючись семантичних конвенцій gen AI, включаючи кроки міркування, виклики інструментів і виклики моделей із використанням токенів. Найдешевше налаштовувати для кожного фреймворку окремо, але ви отримуєте N дашбордів для N фреймворків, що є саме тією проблемою фрагментації, яку ви намагалися вирішити.

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

Справжній вибір — між патерном AWS і vanilla OTel. Якщо ваш центр ваги вже знаходиться в AWS і ви хочете специфічні для AgentCore представлення агентного міркування, це коротший шлях. Якщо ваш центр ваги — GCP або Azure, і ви звертаєтесь до AWS лише для доступу до моделей Bedrock, платити CloudWatch як вашому бекенду observability — це дивне рішення, яке потрібно явно обґрунтувати. Джерело не розкриває, чи прийматиме дашборд 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 індексував їх під дашбордом AI observability gen AI. Помиліться тут — і ваша телеметрія прийде, але не з'явиться на дашборді, заради якого ви все це будували. Виглядатиме як помилка інгестії, хоча насправді це помилка маршрутизації.

Авто-інструментація патчить 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 вказані як підтримувані, але точність авто-інструментації для цих фреймворків є відкритим питанням, що варте перевірки у вашому власному середовищі.