Наблюдение OpenTelemetry LLM: закрепите схему перед зеленым цветом

Наблюдение OpenTelemetry LLM полезно только в том случае, если телеметрия имеет заявленное значение. Прежде чем рассматривать трассировку GenAI как операционное свидетельство, закрепите версию семантического соглашения, проверьте обязательные поля для каждой операции, отклоните несанкционированный захват контента, докажите наличие ожидаемых операций, а затем отдельно оцените свежесть, рабочее состояние и внешний результат. Этот порядок имеет значение в июле 2026 года. Веб сайт OpenTelemetry теперь указывает на соглашения GenAI, выделенный репозиторий. В исходной версии, проверенной для этой статьи, 434c91dcc34ed038e3048c07720ddfed2c6bddfc , хранилище README по прежнему указывает URL адрес схемы как TODO., а документ генеративного клиентского диапазона имеет пометку Разработка . Это не повод избегать OpenTelemetry. Это повод сделать совместимость явной. Панель мониторинга, содержащая диапазоны GenAI, по прежнему может объединять старого производителя, текущего сборщика и запрос, написанный для третьей формы атрибута. Безопасным значением по умолчанию является небольшой профиль принятия с указанием версий рядом с конфигурацией сборщика. Прикрепите контракт, с которым вы фактически работаете Репозиторий GenAI OpenTelemetry охватывает клиентов LLM, агентов, выполнение инструментов, оценку, память, извлечение и MCP. Его документация частично генерируется на основе моделей YAML, что ценно, поскольку исходный код доступен для проверки и тестирования. Это также означает, что фраза «мы используем OTel» слишком расплывчата, чтобы служить заявлением о совместимости. Записывайте четыре идентификатора при каждом развертывании приборов: Личность Пример Почему это важно Источник конвенции Репозиторий плюс фиксация SHA Определяет атрибут и контракт операции, который вы просмотрели. Пакет приборов Имя и версия пакета Определяет, что излучало диапазон Коллекторный трубопровод Дайджест конфигурации и идентификатор развертывания Идентифицирует преобразования, фильтры и средства экспорта. Контракт запроса Версия информационной панели или оповещения Определяет, какие поля ожидает вердикт Не делайте вывод о версии соглашения на основании полученных полей. Это превращает молчаливый дрейф в кажущуюся совместимость. Если производитель не может объявить о своей редакции, классифицируйте партию как schema drift пока вы не протестируете и не зарегистрируете эту форму производителя. Это особенно важно, когда сосуществуют встроенные и внешние инструменты. OpenTelemetry's руководство по наблюдаемости агентов описывает компромиссы при обслуживании встроенного инструментария и предупреждает, что внешние пакеты могут с ним конфликтовать. В противном случае один и тот же вызов модели может наблюдаться дважды, или один маршрут может остаться в старом соглашении после частичного обновления. Практическое правило простое: один ожидаемый производитель телеметрии на каждый путь операции, одна объявленная редакция соглашения на каждую когорту развертывания и канареечную трассировку, которая должна пройти перед повышением когорты. Проверьте небольшой рабочий профиль перед полной схемой. Полный валидатор семантического соглашения может быть создан на основе моделей репозитория. Операционные ворота должны начинаться с меньшего размера. Применяйте только те поля, которые влияют на ваши текущие решения, а затем расширяйте профиль по мере использования большего количества операций. В закрепленной ревизии таблица интервалов вывода отметки: gen ai.operation.name по мере необходимости; gen ai.provider.name по мере необходимости; error.type как условно необходимое условие, когда операция завершается ошибкой; gen ai.request.model по мере необходимости, если таковые имеются; входные сообщения, выходные сообщения, системные инструкции и определения инструментов по желанию. Эти уровни требований не следует сводить к «присутствию или отсутствию поля». Диапазон ошибок без error.type потерял класс доказательств, которых ожидает конвенция. Отсутствующая модель запроса может быть законной, если она была недоступна. Содержимое подсказок и ответов должно отсутствовать, если явная политика не разрешает сбор. Сопутствующий аудит реализует этот узкий профиль: Проверка содержимого проверяет только атрибут keys . Он не читает и не сохраняет текст подсказки, текст ответа, системные инструкции или аргументы инструмента. Этого достаточно, чтобы отловить случайный захват согласия, не превращая валидатор в еще один приемник конфиденциальных данных. Здесь есть намеренное ограничение: этот профиль не является всей спецификацией OpenTelemetry. Он тестирует один подлежащий проверке контракт, используемый для вынесения оперативного вердикта. При изменении исходного источника обновите закрепленную ревизию, сравните сгенерированные определения, настройте фикстуру и перезапустите ее перед обновлением производителей. Аудит покрытия перед интерпретацией чистой трассировки Соответствующий диапазон все еще может быть неполным доказательством. Если приложение ожидает invoke agent , chat , и execute tool , но трасса содержит только первые два, верный вердикт: coverage gap , не здоров. Создавайте ожидаемые операции на основе топологии рабочего процесса, а не на основе наблюдаемых интервалов: Это позволяет избежать циклического теста, при котором телеметрия определяет свою полноту. Ожидаемый набор может быть получен из манифеста выпуска, зарегистрированного маршрута инструмента или определения рабочего процесса. Он должен быть достаточно небольшим, чтобы его можно было поддерживать, и достаточно конкретным, чтобы выявить недостающий путь инструментов. Автоматические повторные попытки требуют осторожности. Текущая концепция клиентского диапазона гласит, что один логический диапазон должен охватывать продолжительность операции, включая автоматические повторные попытки. Ваше приложение также может сохранять транспортные промежутки на уровне попыток. Не считайте эти два уровня дублирующей работой агента. Решите, выражено ли покрытие в логической операции, попытке или в том и другом, а затем сделайте взаимосвязь явной. Аналогично, имя поставщика не обязательно является конечным владельцем модели. В конвенции отмечается, что инструментарий может знать прокси сервер или платформу хостинга, а не прозрачного вышестоящего поставщика. Обращаться gen ai.provider.name в качестве дискриминатора формата и факта маршрутизации в пределах его документированной области, а не в качестве оракула выставления счетов или происхождения модели. Сохраняйте схему, работоспособность и результат как отдельные вердикты. После прохождения схемы и покрытия трассировка может использоваться для принятия решения о работоспособности. Это не решение само по себе. Используйте явный приоритет: 1. Идентификатор схемы — соответствует ли производитель закрепленной версии? 2. Действительность схемы — действительны ли обязательные и условные поля? 3. Политика в отношении контента — разрешены ли поля согласия для этого маршрута? 4. Охват – представлены ли все ожидаемые операции? 5. Свежесть – достаточно ли свежих данных для рабочего процесса? 6. Рабочее состояние — агент работает, ждет, завис, не уверен или завершен? 7. Результат — существует ли обещанный результат в пункте назначения? Приспособление из десяти корпусов для этой статьи намеренно делает эти слои неудобными. Он включает в себя: незакрепленный продюсер и устаревший продюсер; отсутствует интервал вывода gen ai.provider.name ; отсутствует диапазон ошибок error.type ; ключ контента для согласия без разрешения; в рабочем процессе отсутствует ожидаемый набор инструментов; полный след без получения результата; проверенный, но устаревший след; законное ожидание одобрения человека; один свежий, охваченный и подтвержденный исход дела. Запустите артефакт с помощью: Выполненный результат классифицировал ровно десять случаев: complete no receipt случай является ключевой границей. Ревизия производителя совпадает. Его промежутки содержат поля, необходимые профилю. Ожидаемые операции агента и модели существуют. Телеметрия свежая. Он все еще возвращается unverified поскольку никакая квитанция о назначении не доказывает существование билета, файла, развертывания или другого обещанного результата. waiting for approval случае сохраняет другую границу. Недавние совместимые промежутки заканчиваются одобрением поименованного человека с владельцем и крайним сроком. Это не ларек. Пейджинг оператора, как если бы агент вышел из строя, уничтожил бы полезную информацию о состоянии. Превратите аудит в релиз и контроль инцидентов Запустите этот тест за три момента. Перед обновлением инструментария запишите текущую версию, версии пакета, дайджест сборщика и ожидаемые операции. Воспроизведите фиксированное приспособление против предложенного стека. Измененный вердикт должен быть объяснен до повышения. Во время развертывания отправляйте канарейку без содержания через каждую зарегистрированную модель, агент и маршрут инструмента. Убедитесь, что каждая канарейка прибывает один раз, несет ожидаемую идентификацию производителя, проходит рабочий профиль и остается доступной для поиска в окне свежести. Во время инцидента сохраняйте четыре слоя, а не сворачивайте их в состояние «Наблюдаемость нарушена». Сдвиг схемы требует согласования производителя и запроса. Недостаток покрытия требует ремонта оборудования. Устаревшие данные телеметрии требуют диагностики сборщика или экспортера. waiting вызывает названного владельца. unverified требует проверки пункта назначения, а не повторной попытки модели. Не восстанавливайте агент автоматически из за изменения поля телеметрии. Отклонение от общепринятых норм может сделать доказательства неопределенными, не нанося при этом вреда основной работе. Заморозьте активное восстановление, определите неудавшийся уровень доказательств и используйте наименьший обратимый тест, который восстанавливает уверенность. Профилю схемы также нужен владелец. Закрепление коммита навсегда небезопасно; это окончательный застой. Назначьте частоту проверки, просмотрите репозиторий GenAI и запрашивайте разницу в приспособлениях при перемещении штифта. Если OpenTelemetry позже опубликует стабильный URL адрес схемы GenAI, примените его, если ваши производители и запросы поддерживают его, но сохраняйте независимость проверок покрытия, актуальности, ожидания и результатов. Sidewisp сейчас находится на этапе закрытого предварительного доступа. Его публичный опыт — это веб сайт с ранним доступом и интерактивная демонстрация; Сбор информации о состоянии производственного агента, адаптеры хоста и восстановление не включены в текущий репозиторий веб сайта. Направление продукта — это уровень работоспособности существующих сред выполнения, а не сборщик OpenTelemetry, серверная часть трассировки или автономное средство исправления. Если доказательства, закрепленные за пересмотром, и отдельная проверка результатов соответствуют ошибкам, которые вам нужно выявить, вы можете присоединяйтесь к закрытому предварительному просмотру Sidewisp и опишите среду выполнения агента и путь телеметрии, с которым вы работаете.