LLM Наблюдение на AWS: аудит мест назначения AgentCore Span

Практический ответ на вопрос LLM наблюдения на AWS — это не «открыть панель управления CloudWatch». Сначала докажите, куда Amazon Bedrock AgentCore должен доставлять промежутки, затем выполните поиск в каждом пункте назначения, который все еще может содержать доказательства, проверьте идентичность сеанса и трассировки, отклоните устаревшие наблюдения и присоедините трассировку к отдельной квитанции для получения предполагаемого внешнего результата. Этот порядок имеет значение, поскольку пункт назначения AgentCore может измениться. В текущей документации AWS говорится, что поддерживаемые новые агенты могут отправлять промежутки в группу журналов для каждого агента, тогда как старые конфигурации могут использовать общую группу aws/spans . Версии ADOT до 0.18.0 игнорируют настройку единого назначения. Изменение настройки не приводит к перемещению старых интервалов. Таким образом, запрос только к сегодняшней группе журналов может привести к ложному диагнозу «отсутствие телеметрии», даже если отсутствующие данные находятся именно там, где их предыдущая конфигурация указала. В этом руководстве создается аудит без содержания для этой границы. Он использует идентификатор ресурса, версию, место назначения, временные метки, идентификаторы корреляции, состояние выполнения и получение логического результата. Он не требует подсказок, ответов, аргументов инструмента или секретов. Найдите улики, прежде чем объявить их пропавшими Наблюдаемость AgentCore предоставляет встроенные метрики для ресурсов AgentCore и сохраняет метрики, интервалы и журналы в Amazon CloudWatch. Важно отметить, что встроенные метрики — это не то же самое, что трассировки приложений. AWS документирует диапазоны ресурсов памяти по умолчанию, а детали трассировки времени выполнения агента и шлюза зависят от инструментов. Это порождает три отдельных вопроса: 1. Включен ли путь наблюдения AWS? Должен быть включен поиск транзакций CloudWatch, а местом назначения сегмента трассировки должны быть журналы CloudWatch. 2. Где должны располагаться текущие промежутки? Ответ зависит от настройки единого места назначения, поддержки региона, возраста агента, роли выполнения и версии ADOT. 3. Где могут оставаться исторические диапазоны? Любое место назначения, использованное до переключения, остается частью окна расследования, поскольку AWS не переносит существующие данные диапазонов. Руководство по настройке AgentCore дает особенно полезную операционную границу: унифицированная доставка для каждого агента требует aws opentelemetry distro =0.18.0 . Более ранние версии игнорируют конфигурацию и доставляют диапазоны в общую группу. Для того же руководства требуется разрешение на установку соответствующей политики ресурсов CloudWatch Logs. Используйте эти факты, чтобы вычислить ожидаемый пункт назначения перед запросом: Наблюдение Ожидаемая текущая область поиска Заключение оператора Поиск транзакций отключен Никто пока не заслуживает доверия Исправить настройку; не делайте вывод о здоровье агента Сегменты трассировки не направляются в журналы CloudWatch. Никто пока не заслуживает доверия Исправьте необходимое условие назначения Единый запрос, ADOT ниже 0.18.0 Общий aws/spans Пустая группа для каждого агента является ошибкой области запроса. Разрешена единая активная и ролевая политика. Группа журналов времени выполнения каждого агента Проверьте диапазоны тока там Пункт назначения изменен во время периода проверки. Текущая и предыдущие группы Найдите оба; старые пролёты остаются там, где они приземлились Эта таблица намеренно не представляет собой единственную проверку наличия телеметрии. Отсутствие записи в группе для каждого агента может означать сбой установки, блокировку доставки, старую версию ADOT или правильную историческую запись в общей группе. Этим государствам нужен другой ремонт. Сохраняйте запись о переходе в пункт назначения Не делайте активную настройку своим единственным источником истины. Сохраните небольшую запись перехода рядом с Runbook: Запись не содержит подсказок или ответов. Это отвечает на вопрос планирования запроса, который панель мониторинга не может восстановить позже: какие пункты назначения перекрывают окно инцидента? Запустите аудит AgentCore с учетом миграции Аудит, использованный в этой статье, оценивает одиннадцать фиксированных случаев. Его входной контракт намеренно мал: Порядок его решения более важен, чем его синтаксис: Запуск классификатора по прибору дал: Случаи включают отключенный поиск транзакций, неправильное место назначения трассировки, старый ADOT, запрошенный только в группе для каждого агента, пропущенные исторические данные после переключения, недостаточные полномочия доставки, отсутствующий текущий диапазон, устаревшие доказательства, нарушенную корреляцию, законное ожидание утверждения, ложное завершение и здоровый результат с учетом миграции. Это проверка принятия решения, а не доказательство существования действующей учетной записи AWS. Адаптируйте его входные данные на основе вашей собственной конфигурации и канареечных запросов. Сохраняйте порядок: в противном случае общий вердикт telemetry missing может скрыть гораздо более важный факт, что оператор искал не в том месте. Сохранение идентичности сеанса, отслеживания идентичности и актуальности AWS описывает наблюдаемость AgentCore как иерархию: сеанс содержит трассировки, а трассировка содержит интервалы. телеметрическая документация делает эту иерархию явной. Это полезно только в том случае, если идентификатор сохраняется на пути запроса. Для вызовов среды выполнения AgentCore, оснащенных ADOT, в руководстве по настройке описаны две детали распространения: отправьте X Amzn Bedrock AgentCore Runtime Session Id , чтобы идентификатор сеанса достиг нисходящей телеметрии; вызывать среду выполнения с помощью traceId=<traceId , когда необходимо распространить идентификатор трассировки. Запишите, присутствуют ли эти идентификаторы, а не их конфиденциальный контекст полезной нагрузки. Промежуток без присоединяемого сеанса все еще может доказать, что код выполнен, но он не может поддерживать временную шкалу инцидентов на уровне сеанса. Классифицируйте это как correlation broken , нездорово. Свежесть требует такого же явного контракта. След, найденный на прошлой неделе, не доказывает, что доставка работает сейчас. Определять: Выберите максимальный возраст из ожидаемой частоты рабочего процесса и допуска к инцидентам. Пять минут вполне разумно для ежеминутной канарейки; для ночной партии это неразумно. Храните порог с вердиктом, чтобы «свежий» оставался доступным для проверки. Ожидание также требует доказательств. Если трассировка показывает ограниченную зависимость утверждения от владельца и запуск можно возобновить, верните waiting . Не отмечайте его как зависший только потому, что не появился новый диапазон инструментов. Если запись об утверждении отсутствует, противоречива или срок ее действия истек, верните uncertain или выполните эскалацию в соответствии с Runbook. Требовать получение результата после трассировки Полная трассировка отвечает на вопрос: «Завершился ли инструментированный путь выполнения?» Он не обязательно отвечает на вопрос: «Выполнена ли запланированная работа?» Разница видна в типичных неисправностях: инструмент загрузки возвращает объект до того, как пункт назначения зафиксирует объект; сообщение API принимает запрос, но сообщение так и не достигает намеченного канала; агент записывает локальный файл, в то время как требуемый артефакт находится в удаленном хранилище; последний вызов модели завершается успешно после того, как нисходящая транзакция уже откатилась; ожидание утверждения неправильно преобразуется в успех терминала. Предписывающие рекомендации AWS рекомендует сопоставить доказательства LLM с последующим воздействием. Реализация с минимальной конфиденциальностью может сделать это с получением результата: Квитанция должна быть произведена с помощью самой строгой доступной детерминированной проверки: объекта HEAD , базы данных, считанной по стабильному ключу, общедоступной выборки API, контрольной суммы или целевого теста. Он не должен содержать тело объекта, приглашение, ответ или секрет. Держите два вердикта отдельно: Следы доказательств Получение результата Состояние Отсутствует или устарел Любой Доказательств наблюдаемости недостаточно. Полный Отсутствующий false complete Ожидание зарегистрированного одобрения Пока не ожидается waiting Полный и свежий Присутствует и проверено healthy за этот проверенный результат Последняя строка ограничена. Это доказывает фиксированную канарейку и пункт назначения, а не каждый маршрут, каждую задачу или качество семантического вывода. Принять аудит без сбора контента Полезная производственная квитанция требует достаточного количества данных, чтобы различить уровни отказов: идентификаторы ресурсов агента и конечных точек в отредактированной или хешированной форме; Регион и время наблюдения; Поиск транзакций и статус места назначения; Версия ADOT и настройка единого назначения; текущий и предыдущий классы назначения; выполнялся ли поиск окна расследования в обоих направлениях; новейшее подходящее канареечное время; наличие идентификатора сеанса и идентификатора трассировки; состояние выполнения и состояние ограниченного утверждения; стабильная идентичность операции и детерминированный статус результата получения. Не используйте в этой квитанции текст подсказки, ответы модели, аргументы инструментов, учетные данные, необработанные заголовки и полезные данные клиента. Если для конкретного инцидента требуется более глубокая проверка контента, авторизуйте и определите ее область отдельно. Аудит также имеет ограничения. Он не доказывает покрытие инструментами каждого маршрута приложения, полноту выборки, сохранение CloudWatch, восстановление экспорта или качество семантического ответа. Это доказывает, что выбранный путь доказательства настроен и доступен для поиска, канарейка свежа и коррелирована, а выбранный внешний результат имеет собственную квитанцию. Этого достаточно, чтобы предотвратить дорогостоящую ошибку категории: смену агента из за того, что оператор выполнил поиск неправильного пункта назначения. Sidewisp сейчас находится на этапе закрытого предварительного доступа. Его предполагаемая роль — превратить такие данные, как покрытие пунктов назначения, актуальность, корреляция, состояние ожидания и проверка результатов, в четкое представление о состоянии здоровья. Адаптеры мониторинга Production AgentCore и CloudWatch в настоящее время не поставляются, поэтому эта статья представляет собой шаблон работы, который вы можете применить уже сейчас, а не утверждение, что Sidewisp уже проводит этот аудит.