Claude научился отправлять телеметрию работы агентов напрямую в системы мониторинга через открытый стандарт OpenTelemetry. 14 октября 2026 года Anthropic открыла публичную бету этой возможности для Claude Platform. Теперь вызовы Messages API, сессии Claude Managed Agents и события клиентских SDK можно собирать в Grafana, Datadog или Langfuse рядом с логами серверов. Но при первом подключении многих ждет сюрприз: графики задержек и токенов оживут, а текст запросов, ответов модели и шагов инструментов в дашборде так и не появится.
Куда исчезает текст запросов и ответов
Когда агент запутывается в инструкциях или падает с ошибкой, инженеру важно видеть, что модель получила на вход и что ответила. Системы мониторинга показывают этот путь как трейс — цепочку отдельных шагов, называемых спанами. Каждый спан фиксирует действие: обращение к внешнему сервису, вызов локальной программы или генерацию текста нейросетью.
По умолчанию Anthropic включила строгий режим передачи только метаданных. В систему уходят лишь технические параметры: идентификаторы сессии, время, статус, число токенов и выбранные названия агентов, инструментов и серверов MCP. Ни системный промпт, ни сообщения пользователя, ни ответы модели в спаны не попадают, чтобы закрытые данные случайно не осели в чужих логах.
Чтобы увидеть живой текст, в настройках экспорта включают полную передачу содержимого. Но переключатель сработает не у всех. Если организация связана соглашениями вроде HIPAA, FERPA или K-12, платформа принудительно заблокирует выгрузку текстов через настройки консоли. В таком случае централизованный экспорт будет отдавать исключительно сухие цифры, какую бы галочку вы ни поставили в панели управления.
Лимиты объема и обрезанные сообщения
Даже если организация включила передачу полного содержимого, вступают в силу сетевые лимиты. По умолчанию сервис ограничивает объем текста в одном спане отметкой в 0.75 мегабайта. Этого хватает примерно на двести тысяч токенов английского текста: лимит выбран так, чтобы входящие запросы не отклоняли стандартные прокси-серверы и приемники телеметрии с порогом в один мегабайт.
Для контекстного окна до миллиона токенов потребуется около четырех мегабайт, которые нужно указывать в расширенных параметрах. Когда объем превышает порог, сервис обрезает данные и ставит флаг усечения. У входящих запросов первыми удаляются системная инструкция и ранние реплики диалога, а у результатов инструментов отсекается конец. Прикрепленные картинки и документы в телеметрию не попадают вовсе — сохраняется только указание их типа.
Практику работы с агентскими сценариями и разборы свежих инструментов мы публикуем в нашем Telegram-канале.
Два пути настройки и ловушка двойного счета
В документации описано два независимых способа собирать телеметрию. Первый — трейсинг на уровне библиотек SDK для Python, TypeScript, Go, Java, C#, PHP и Ruby. Он настраивается прямо в коде приложения регистрацией провайдера телеметрии до первого вызова и следит за клиентской стороной: обращениями к API, работой локальной песочницы и запуском инструментов на вашей машине.
Второй путь настраивается в консоли администратором организации. Он перехватывает серверную сторону: внутренние шаги модели, сессии управляемых агентов и серверные инструменты. Оба источника можно объединить сквозным заголовком W3C в единый трейс. Исключением остается запуск на AWS: там серверные спаны пока не поддерживают сквозной заголовок и начинают отдельные цепочки.
Объединение двух потоков таит ловушку при подсчете затрат. Библиотека SDK и серверный интерфейс создают собственные спаны для каждого запроса к модели с одинаковым именем. Если дашборд просто суммирует токены по всем записям, статистика покажет двукратный перерасход. Чтобы видеть реальные цифры, аналитику нужно строить строго по одному источнику — либо по серверным спанам, либо по клиентским.
Сетевые требования и доставка без гарантий
Сервис отправляет данные по протоколу OTLP поверх HTTPS строго на 443 порт и требует публичный домен. Стандартный коллектор OpenTelemetry обычно слушает порт 4318 без шифрования, поэтому напрямую данные не примет — перед ним нужен обратный прокси с сертификатом. Путь для трейсов платформа добавит сама, указывать его вручную в адресе не требуется.
Доставка работает по принципу наилучшей попытки. При сбоях платформа повторит отправку с коротким таймаутом, но потерянные спаны восстановить нельзя. Использовать трейсы для сверки счетов за токены не стоит — для финансовой отчетности в документации прямо советуют опрашивать интерфейс статистики использования. Кроме того, при повторах спан может прийти дважды, поэтому мониторинг должен отсекать дубли по идентификаторам.
Нативный экспорт в открытый стандарт заметно упрощает наблюдение за автономными агентами. Поведение нейросетей теперь видно в тех же дашбордах, где работает остальной стек сервисов. Но до запуска в боевых условиях стоит заранее проверить режим выгрузки текста, подготовить защищенный порт и настроить правила фильтрации повторных записей.
