Новая реликвия LLM Observability: докажите, что каждый вызов принадлежит одному маршруту

Наблюдение New Relic LLM может отображать задержку модели, токены, ошибки, трассировки и данные ответа ИИ. Он сам по себе не может сообщить оператору, засчитали ли два коллектора один и тот же вызов модели или выдал ли агент запрошенный внешний результат. Практический вариант по умолчанию — назначить одного владельца инструментов для каждой границы вызова модели , сопоставить каждую запись с идентификатором вызова без содержания и сохранить отдельную квитанцию ​​за результат. Это правило имеет значение, поскольку New Relic документирует несколько законных путей. Его роднойИИ мониторингиспользует агенты APM. New Relic также документируетOpenLIT поверх OTLPдля трассировок и метрик иOpenLLMetry через OTLPна следы. LiteLLM имеет отдельныйИнтеграция Новой Реликвиипостроен на основе обратного вызова и агента New Relic Python. Эти пути являются вариантами, а не свидетельством того, что все должны использовать одну и ту же границу. Панель мониторинга может быть заполнена, если владелец неправильный, данные устарели, необходимое поле отсутствует или завершенный вызов модели не имеет проверенного результата. Объявите маршрут, прежде чем доверять карте. Начните с манифеста развертывания, а не с запроса. Он должен идентифицировать услугу, инструментируемую границу, одного владельца, которому разрешено сообщать об этой границе, типы сигналов, которые может излучать владелец, поле корреляции и предел актуальности. Различие между владельцем и видом сигнала предотвращает грубую ошибку дедупликации. Один объявленный владелец может намеренно выдать диапазон APM и событие AI сообщения для одного и того же вызова. Эти записи дополняют друг друга, если они используют один и тот же идентификатор вызова и контракт на развертывание предполагает оба. Запись OpenLIT и запись OpenLLMetry для одной и той же границы являются двумя владельцами, даже если их поля выглядят одинаково. Манифест должен быть создан развертыванием, в котором включено инструментирование. Не делайте выводов о том, какой объект появляется в пользовательском интерфейсе. Пути установки устанавливают идентичность по разному: Мониторинг New Relic AI начинается с агента APM и поддерживаемой библиотеки или платформы. OpenLIT отправляет трассировки и метрики в конечную точку OTLP New Relic. OpenLLMetry отправляет трассировки в эту конечную точку, а New Relic извлекает объект службы из OpenTelemetry. service.name атрибут ресурса. LiteLLM позволяет newrelic обратный вызов и использует агент New Relic Python для телеметрии APM. В его документации говорится, что обратный вызов регистрирует сообщение инициализации, и что появление деталей трассировки может занять две три минуты. Этого достаточно, чтобы потребовать явную запись маршрута. Это не является доказательством того, что какая то конкретная пара всегда будет дублировать звонок. Заявление о безопасной эксплуатации более узкое: если за границей наблюдаются два владельца, манифест которых допускает наличие одного, итоговые значения и вердикты о работоспособности остаются неоднозначными до тех пор, пока размещение не будет согласовано. Используйте непрозрачный идентификатор вызова, а не хэш подсказки. Полезный конверт наблюдения может оставаться свободным от содержимого: Содержимое подсказок и ответов не требуется для проверки владения, актуальности, наличия поля токена или проверки места назначения. LiteLLM документирует как специфичные для New Relic turn off message logging настройка и переключатель среды, который отключает запись контента AI мониторинга. Рассматривайте сохранение контента как отдельное решение о конфиденциальности; не включайте его только для того, чтобы заставить работать аудит владения. Воспроизведите восемь состояний, которые скрывает зеленый вид. Сопутствующий аудит использует восемь синтетических вызовов. Он применяет этот приоритет: 1. нет наблюдения; 2. ожидаемый владелец отсутствует; 3. более одного владельца; 4. неожиданный тип сигнала или отсутствие обязательного поля; 5. устаревшие доказательства; 6. законное ожидание; 7. завершение без получения результата; 8. завершение с получением результата. Приоритет имеет значение. Устаревшая запись от правильного владельца не является здоровой. Свежая запись от неправильного владельца также вредна. Ожидание оценивается только после того, как право собственности, форма и свежесть прошли, поэтому пауза утверждения не может скрыть испорченную коллекцию. Полный прибор не содержит подсказок или ответов. Его запуск выдает восемь различных вердиктов: Классификатор намеренно небольшой: Каждый неработоспособный вердикт указывает на отдельный ремонт: Вердикт Что он устанавливает Ограниченное следующее действие NO TELEMETRY Не поступило записей об ожидаемом звонке Проверьте инициализацию инструментов, доступность экспортера и окно запроса. ROUTE DRIFT Данные пришли, но не от заявленного владельца Сравните манифест развертывания с запущенным процессом и отключите непредусмотренный путь. MULTIPLE OWNERS Границу соблюдали более одного владельца приборов Поместить вызов в карантин из итогов; выберите одного владельца или запишите временное исключение миграции SCHEMA GAP Право собственности установлено, но доказательства непригодны для использования или неполны. Исправьте сопоставление полей или контракт типа сигнала перед оповещением об этом. STALE Последние доказательства превышают разрешенный возраст Проверьте задержку экспортера, организацию очереди, выравнивание часов и время запроса. WAITING Коллекция работоспособна, и именованная зависимость сохраняется. Уведомите владельца или дождитесь записанного срока; не перезапускать агент OUTCOME UNVERIFIED Вызов модели завершен без подтверждения запрошенного эффекта. Запустите детерминированную проверку места назначения HEALTHY Право собственности, доказательства, состояние работы и результат совпадают. Сохраните квитанцию ​​и примените обычное окно стабильности. MULTIPLE OWNERS не должен автоматически удалять или объединять записи. Во время плановой миграции может оказаться полезным двойной сбор. Сделайте исключение явным, указав время начала, время окончания, владельцев и правило согласования. Не допускайте, чтобы наблюдения за миграцией были включены в знаменатели производственных затрат и надежности до тех пор, пока не будут сопоставлены два пути. В противном случае очевидный всплеск токена может быть изменением инструментария, а не изменением поведения. Этот прибор также показывает, почему обычное красное состояние является слабым. ROUTE DRIFT является проблемой развертывания; STALE это может быть проблема с приемом или окном запроса; WAITING это не провал; и OUTCOME UNVERIFIED требует проверки места назначения, а не другого запроса трассировки. Присоединить наблюдаемость к получению результата Документация New Relic по мониторингу искусственного интеллекта описывает производительность, стоимость, токены, ответ, трассировку и отзывы пользователей. Это полезные сигналы об уровне ИИ. За ответом модели по прежнему может последовать неудачный вызов инструмента, незафиксированный файл, электронное письмо, которое так и не было отправлено, или задание, ожидающее утверждения. По этой причине держите квитанцию ​​о назначении вне телеметрии вызова модели: Назначение и способ проверки зависят от работы. Используйте версию объекта для загрузки файла, хэш фиксации плюс проверки на изменение кода, идентификатор сообщения поставщика для доставки или обратное чтение API для мутации конфигурации. Код завершения команды слабее, если обещанный результат существует где то еще. В повторе, false complete и healthy имеют одинаковые два типа сигналов на стороне New Relic: владельца, поля и свежесть. Меняется только квитанция назначения. Это операционная граница: наблюдаемость LLM объясняет доказательства вызова модели; квитанция доказывает, что предполагаемый результат агента существует. Практическое внедрение невелико: 1. Выберите одну реальную границу вызова модели. 2. Запишите предполагаемого владельца оборудования и разрешенные типы сигналов в развертывании. 3. Создайте один синтетический идентификатор вызова и запросите его для каждого соответствующего типа события New Relic. 4. Завершите развертывание неудачно, если ожидаемый владелец отсутствует или появляется необъявленный владелец. 5. Проверьте обязательные поля и ограниченный интервал актуальности. 6. Записывать working , именованная зависимость ожидания или complete отдельно. 7. Требовать детерминированную квитанцию ​​о пункте назначения перед переездом complete к здоровому. 8. Повторите эти действия после обновления SDK, обратного вызова, средства экспорта или агента. У этой процедуры есть ограничение: она не доказывает, что каждая интеграция, поддерживаемая New Relic, будет дублировать каждую комбинацию платформ. Это доказывает, соответствует ли наблюдаемое вами развертывание заявленному договору владения. Он также не заменяет проверки совместимости New Relic или полный тест на соответствие схемы OpenTelemetry. Предполагаемая роль Sidewisp близка к этому различию: объединить данные о достижимости, полезном прогрессе, инструментах, результатах, времени и бюджете в представление о состоянии агента. Sidewisp сейчас находится на этапе закрытого предварительного доступа. Живой продукт представляет собой веб сайт с ранним доступом и демонстрацию; производственный адаптер New Relic, механизм мониторинга и средство автоматического восстановления не поставляются. Используйте приведенный выше аудит с вашими текущими системами телеметрии и назначения, а не предполагайте, что Sidewisp соберет или исправит их сегодня. Это решение достаточно просто реализовать: один объявленный владелец инструментария на каждую границу вызова модели, несколько типов сигналов только тогда, когда это разрешено манифестом, свежие доказательства без содержания, явное состояние ожидания и независимое получение результатов. Зеленое представление New Relic становится надежным для операций агента только после согласования этих границ.