Что делать, если в Amazon Bedrock AgentCore не видны данные трассировки в 2026 году?

Симптом: вызов AgentCore завершается, но в CloudWatch нет полезной трассировки. Быстрый путь: сначала проверьте аккаунт, регион, диапазон времени и CloudWatch Transaction Search, затем настройки телеметрии ресурса, назначение логов и права; для агента вне AgentCore Runtime отдельно проверьте OpenTelemetry.

Эта инструкция нужна разработчикам, которые расследуют ошибки AgentCore Runtime, платформенным инженерам, настраивающим CloudWatch, и техническим руководителям, которым нужен воспроизводимый порядок диагностики. Если вы только выбираете среду для первого развёртывания агента, здесь речь не о настройке системы с нуля, а о поиске причины отсутствующих диагностических данных.

Сначала определите, чего именно не хватает

Фраза «в CloudWatch пусто» объединяет разные неисправности. Вызов мог не дойти до Runtime; Runtime мог обработать запрос, но не передать ожидаемые журналы; метрики могли публиковаться, а spans — отсутствовать; наконец, данные могут существовать, но быть скрыты выбранным представлением, фильтром или областью поиска. У этих случаев разные следующие действия, поэтому начните не с изменения IAM, а с фиксации симптома.

Разделите проверку на независимые вопросы:

• Был ли вызван нужный Runtime и правильный endpoint?
• Есть ли подтверждение выполнения запроса — например, ответ приложения или ошибка, которую видно вызывающей стороне?
• Ищете ли вы логи, метрики или трассировку? Это разные типы телеметрии, а не взаимозаменяемые названия одного журнала.
• Выбраны ли правильные аккаунт AWS, регион, Runtime и временной интервал?
• Совпадают ли фактическая конфигурация ресурса и представление CloudWatch, в котором вы ищете данные?

В документации AgentCore описаны разные виды наблюдаемости, включая логи, метрики и трассировки. Поэтому отсутствие одного типа данных не позволяет автоматически заключить, что остальные тоже не публикуются. Сначала сопоставьте ожидаемый тип телеметрии с описанием наблюдаемости AgentCore в AWS.

Практический пример: вызов агента возвращает ошибку, но журналы Runtime доступны. Значит, проблема не сводится к полной недоступности CloudWatch; нужно выяснить, где теряются spans или почему выбранный экран их не показывает. Если же нет ни журналов, ни ожидаемых метрик, сначала проверяйте конфигурацию ресурса, фактический пункт назначения и права на публикацию. Эти ветки нельзя объединять в одну гипотезу «сломался CloudWatch».

Уточните границы поиска до изменений конфигурации

Сверьте аккаунт и регион с местом, где создан нужный AgentCore Runtime. Проверьте идентификатор ресурса и endpoint: при наличии нескольких окружений легко исследовать тестовый Runtime, в то время как запрос отправляется в другой. Установите временной интервал по времени фактического вызова, а не по моменту, когда вы открыли консоль.

Затем проверьте выбранное представление данных. Spans Runtime ищутся не обязательно там же, где вы привыкли просматривать журналы. AWS указывает расположение Runtime spans в отдельной инструкции по просмотру трассировок AgentCore. Это важная проверка: правильные данные в другом разделе интерфейса выглядят как потерянные, хотя конфигурация могла не меняться.

Диагностика данных трассировки Amazon Bedrock AgentCore в 2026 году

Проверьте включение CloudWatch Transaction Search отдельно от конфигурации телеметрии самого ресурса. Это не одна настройка: одна сторона отвечает за доступность поиска транзакций в CloudWatch, другая — за то, создаёт ли конкретный ресурс нужные данные и куда их отправляет. Требования и порядок включения Transaction Search описаны в документации AWS по его настройке.

В проверке держите отдельно три уровня:

• Уровень аккаунта и CloudWatch. Убедитесь, что Transaction Search включён и его настройка применена в том аккаунте, где вы выполняете запрос. Не делайте вывод по состоянию соседнего аккаунта или другого региона.
• Уровень ресурса AgentCore. Проверьте, включена ли требуемая телеметрия для того Runtime, Memory или Gateway, который участвует в конкретном запросе.
• Уровень просмотра. Найдите spans и связанные данные в предназначенном для них представлении, задав корректный временной диапазон и фильтры.

После включения или изменения настроек не считайте пример ожидания из документации гарантией одинаковой задержки во всех аккаунтах, регионах и сценариях. Проверьте фактическое состояние настройки и повторите контролируемый вызов; если данные не появились, зафиксируйте время изменения и теста, а затем продолжайте диагностику по уровню ресурса. Руководство по началу работы с наблюдаемостью AgentCore помогает сверить последовательность включения и проверки.

Если в интерфейсе или старой инструкции указан прежний пункт назначения, сопоставьте его с актуальным поведением, а не копируйте настройки по памяти. AWS отражает изменения назначения телеметрии в заметках о выпусках AgentCore. Это особенно важно для окружений, созданных раньше текущей версии документации: устаревший путь в инструкции способен увести поиск не туда.

Проверьте телеметрию именно того ресурса, который участвует в вызове

AgentCore Runtime, Memory и Gateway могут быть задействованы в одном рабочем процессе, но это не означает, что у них общая конфигурация телеметрии или одно назначение журналов. Составьте цепочку запроса: какой ресурс получил вызов, какой компонент создал нужное событие и какой пункт назначения должен его принять. Если Runtime вызвался, а операция Memory не дала ожидаемого следа, проверяйте конфигурацию Memory отдельно, а не только настройки Runtime.

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

Для Runtime отдельно проверьте метрики: их наличие не подтверждает, что трассировка настроена и доступна в Transaction Search. AWS описывает Runtime telemetry в документации по метрикам AgentCore Runtime. Сравните тип наблюдаемого сигнала с тем, который вы ищете. Если метрики есть, но trace не находится, переходите к настройке spans и представлению поиска; если отсутствуют и метрики, и журналы, вернитесь к настройкам ресурса, назначению и разрешениям.

Для проверки используйте такую последовательность действий:

• Зафиксируйте точный Runtime, endpoint и регион, куда отправляется запрос.
• Запишите, какой именно ресурс AgentCore участвует в проблемном шаге: Runtime, Memory или Gateway.
• Откройте актуальную конфигурацию этого ресурса и найдите включённые типы телеметрии.
• Сверьте назначение каждого типа данных с настройкой и документацией AWS.
• Выполните один контролируемый запрос и сохраните его время, идентификатор корреляции, если он предусмотрен приложением, и наблюдаемый результат.
• Ищите в правильном представлении CloudWatch, сначала без излишне узких фильтров.
• Только после этого меняйте права или конфигурацию, по одному параметру за раз.

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

Сопоставьте симптом с проверкой

Используйте таблицу как маршрут, а не как утверждение о гарантированной причине: одинаковый симптом может возникать из-за разных настроек. Для проверки Runtime дополнительно сопоставьте найденные признаки с руководством AWS по устранению неисправностей AgentCore Runtime. Документация по разрешениям AgentCore Runtime поможет проверить требования к правам, но не заменяет проверку назначения данных и области поиска.

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

Примите решение по условиям, а не по догадке

• Если нужный ресурс и регион совпадают, а проблема только в поиске spans, сначала проверьте Transaction Search и представление трассировки; не меняйте права Runtime без признака ошибки публикации.
• Если отсутствуют журналы и метрики конкретного ресурса, проверьте его конфигурацию телеметрии и назначение; если отправка настроена, переходите к правам.
• Если Runtime-телеметрия видна, но нет событий пользовательского кода, а агент развёрнут не как управляемый Runtime, проверяйте OpenTelemetry SDK, инструментализацию фреймворка и переменные окружения.
• Если данные доступны в аккаунте-источнике, но не там, где вы их ищете, сначала подтвердите межаккаунтный путь и доступ читателя; не включайте повторно сбор на Runtime, пока не определено место назначения.
• Если данные появились после снятия фильтра, верните ограничения по одному и сохраните те, которые не исключают запрос.

Если агент размещён не в AgentCore Runtime

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

Сравните один и тот же тестовый запрос в локальном и облачном окружениях. Используйте одинаковую версию приложения, тот же путь выполнения и сопоставимые параметры инструментации; зафиксируйте, какие события появляются в каждом случае. Если локальная трассировка создаётся, но в облаке её нет, исследуйте экспорт, сетевой путь и переменные окружения. Если spans отсутствуют в обоих местах, сначала проверяйте SDK и инструментализацию приложения, а не настройки AgentCore Runtime, которым этот агент не управляется.

Разделяйте встроенную телеметрию управляемого Runtime и телеметрию пользовательского кода. Успешный сбор первой не означает, что автоматически появятся подробные spans внутренних вызовов сторонней библиотеки или бизнес-логики. Точный набор доступных сигналов и требования к настройке сопоставляйте с официальными инструкциями по конфигурированию AgentCore Observability. Названия переменных, параметры экспортёра и разрешения проверяйте по текущей документации, а не переносите из старого шаблона развёртывания.

Чтобы воспроизведение было полезным, сохраните запись с такими полями:

• дата и время теста с часовым поясом;
• AWS-аккаунт, регион, идентификатор ресурса и endpoint;
• способ запуска вызова и его результат;
• какие типы данных вы искали: журналы, метрики или spans;
• включён ли Transaction Search и в каком аккаунте;
• ожидаемый пункт назначения телеметрии для каждого ресурса;
• применённые фильтры и временной диапазон поиска;
• изменения конфигурации и прав перед повторной проверкой;
• наличие или отсутствие чувствительных данных в полезной нагрузке.

Не добавляйте в такую запись токены, секреты и полный текст пользовательского запроса, если для расследования достаточно обезличенного примера. Если вам требуется согласовать порядок проверки среды и обращения с диагностическими данными, используйте справочный центр kvmboot, а при вопросе, требующем уточнения, обратитесь через контактную страницу kvmboot.

Частые вопросы

Нужно ли начинать с прав, если CloudWatch пуст?

Не обязательно. Сначала установите, какой компонент должен был создать данные, и правильно ли выбраны аккаунт, регион, ресурс и диапазон времени. Затем проверьте Transaction Search, настройки телеметрии и назначение. Права становятся приоритетной веткой, когда конфигурация предполагает отправку данных, но публикация не проходит, либо когда данные существуют, но недоступны выбранному читателю.

Почему видны метрики, но не трассировки?

Метрики и spans — разные виды телеметрии. Наличие метрик подтверждает лишь то, что соответствующий сигнал доступен в выбранной области поиска; оно не доказывает, что для ресурса включено создание и отправка spans. Сверьте конфигурацию Runtime, настройку Transaction Search и представление, предназначенное для трассировок. Для собственного агента отдельно проверьте OpenTelemetry-инструментализацию.

Где искать trace, если журналы Runtime уже доступны?

Не предполагайте, что трассировки показываются в том же разделе, что и журналы. Сверьте документированное представление AgentCore Runtime spans, затем проверьте аккаунт, регион, временной интервал и фильтры. Если trace всё ещё не находится, выясните, включена ли его отправка для конкретного ресурса, и настроен ли CloudWatch Transaction Search в нужном аккаунте.

Как убедиться, что данные не потеряны при работе через несколько аккаунтов?

Сначала зафиксируйте аккаунт, в котором работает ресурс, и аккаунт, в котором выполняется поиск. Подтвердите пункт назначения телеметрии и доступ пользователя, который читает данные; затем проверьте настройки межаккаунтного сценария по документации AWS. Поиск в аккаунте-получателе не найдёт данные, направленные в другой пункт назначения, даже если сам вызов Runtime прошёл успешно.

Если AgentCore уже работает в AWS, его преимущества — близость к облачным сервисам и возможность настраивать управляемую телеметрию; ограничения для диагностики тоже конкретны: настройки распределены между ресурсом и CloudWatch, права могут усложнять поиск, а без правильного аккаунта и региона данные легко принять за отсутствующие. Для воспроизведения клиентской части агента отдельная удалённая среда macOS может быть удобнее, чем менять производственный Runtime ради локального эксперимента. Аренда Mac через kvmboot уместна как временный тестовый контур, но не заменяет CloudWatch и не исправит ошибочную конфигурацию AgentCore; если же вам нужна постоянно работающая серверная нагрузка или физические интерфейсы, выбирайте среду под эти требования, а не арендуйте Mac по умолчанию. Сравнить доступный вариант можно на странице аренды Mac kvmboot.