New Relic LLM 가시성: 각 호출에 대해 하나의 경로가 해당 호출을 담당함을 입증

New Relic LLM 가시성 기능을 통해 모델 지연 시간, 토큰, 오류, 추적 정보 및 AI 응답 데이터를 확인할 수 있습니다. 하지만 이 기능만으로는 두 수집기가 동일한 모델 호출을 집계했는지, 또는 에이전트가 요청된 외부 결과를 생성했는지 여부를 운영자에게 알려줄 수는 없습니다. 실무상 기본 방식은 각 모델 호출 경계마다 하나의 계측 소유자를 지정 하고, 모든 레코드를 내용이 없는 호출 ID와 연관시키며, 전달 결과에 대해서는 별도의 영수증을 보관하는 것입니다. 이 규칙이 중요한 이유는 New Relic가 여러 가지 합법적인 경로를 기록하고 있기 때문입니다. 이 규칙의 기본 AI 모니터링 APM 에이전트를 사용합니다. New Relic도 관련 내용을 기록합니다. OpenLIT 대 OTLP 추적 정보 및 메트릭과 OpenLLMetry 대 OTLP 추적 정보를 위해. LiteLLM에는 별도의 New Relic 통합 콜백과 New Relic, Python 에이전트를 중심으로 구축되었습니다. 이러한 경로는 선택지일 뿐, 모두가 동일한 경계를 구현해야 한다는 증거는 아닙니다. 소유권이 잘못되었거나, 증거가 오래된 상태이거나, 필수 필드가 누락되었거나, 완료된 모델 호출에 검증된 결과가 없는 경우에도 대시보드에 데이터가 표시될 수 있습니다. 해도를 신뢰하기 전에 항로를 정하십시오 쿼리가 아닌 배포 매니페스트부터 시작하십시오. 이 매니페스트에는 서비스, 모니터링 대상 경계, 해당 경계를 보고할 수 있는 유일한 소유자, 해당 소유자가 발신할 수 있는 신호 유형, 상관 관계 필드 및 최신성 제한이 명시되어야 합니다. 소유자 와 신호 종류 를 구분함으로써, 조잡한 중복 제거 오류를 방지할 수 있습니다. 선언된 하나의 소유자는 동일한 호출에 대해 의도적으로 APM 스팬과 AI 메시지 이벤트를 발송할 수 있습니다. 이러한 레코드는 동일한 호출 ID를 공유하고 배포 계약에서 두 가지 모두를 기대할 경우 상호 보완적입니다. 동일한 경계에 대한 OpenLIT 레코드와 OpenLLMetry 레코드는 필드가 비슷해 보일지라도 서로 다른 두 소유자에 해당합니다. 매니페스트는 계측을 활성화한 배포에서 생성되어야 합니다. UI에 우연히 표시되는 개체를 바탕으로 이를 추측해서는 안 됩니다. 설정 경로는 식별 방식을 다르게 정합니다: New Relic AI 모니터링은 APM 에이전트와 지원되는 라이브러리 또는 프레임워크를 통해 시작됩니다. OpenLIT는 추적 정보와 메트릭을 New Relic의 OTLP 엔드포인트로 전송합니다. OpenLLMetry는 해당 엔드포인트로 트레이스를 전송하며, New Relic는 OpenTelemetry의 service.name 리소스 속성에서 서비스 엔티티를 도출합니다. LiteLLM는 newrelic 콜백을 활성화하고, APM 텔레메트리 수집을 위해 New Relic 및 Python 에이전트를 사용합니다. 관련 문서에 따르면, 이 콜백은 초기화 메시지를 기록하며, 추적 세부 정보가 표시되기까지 2~3분이 소요될 수 있다고 합니다. 이 사실만으로도 명시적인 라우트 레코드가 필요하다는 것을 의미합니다. 이는 특정 쌍이 항상 호출을 중복한다는 증거는 아닙니다. 안전한 운영상의 주장은 더 좁은 범위를 다룹니다. 즉, 매니페스트에서 하나만 허용하는 경계에 대해 두 명의 소유자가 관찰될 경우, 배포가 조정될 때까지 총계 및 상태 판정은 모호한 상태로 남아 있습니다. 프롬프트 해시 대신 불투명한 호출 식별자를 사용하세요. 유용한 관찰 엔벨로프는 내용을 포함하지 않아도 됩니다: 소유권, 최신성, 토큰 필드 존재 여부 또는 대상 확인을 위해 프롬프트와 응답 내용은 필요하지 않습니다. LiteLLM는 New Relic에 특화된 turn off message logging 설정과 AI 모니터링 콘텐츠 기록을 비활성화하는 환경 전환을 모두 문서화합니다. 콘텐츠 보존은 별도의 개인정보 보호 결정 사항으로 간주하십시오. 단순히 소유권 감사를 수행하기 위해 이 기능을 활성화해서는 안 됩니다. 초록빛 풍경 뒤에 숨겨진 여덟 가지 상태를 다시 살펴보세요 이 예제 감사에서는 8개의 합성 호출을 사용합니다. 이 예제에서는 다음과 같은 우선순위를 적용합니다: 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의 AI 모니터링 문서에는 성능, 비용, 토큰, 응답, 추적 정보 및 사용자 피드백 증거에 대한 내용이 설명되어 있습니다. 이러한 정보들은 AI 레이어에 대한 유용한 지표가 됩니다. 모델의 응답이 나온 후에도 도구 호출 실패, 커밋되지 않은 파일, 발송되지 않은 이메일, 또는 승인을 기다리고 있는 작업이 발생할 수 있습니다. 따라서, 목적지 수신 확인은 모델 호출 텔레메트리 외부에 두십시오: 대상과 검증 방법은 작업에 따라 다릅니다. 파일 업로드의 경우 객체 버전을, 코드 변경의 경우 커밋 해시와 검증을, 전송의 경우 제공자 메시지 ID를, 구성 변경의 경우 API 읽기 응답을 사용하십시오. 약속된 결과가 다른 곳에 존재하는 경우, 명령어의 종료 코드는 신뢰도가 떨어집니다. 리플레이에서 false complete 와 healthy 는 New Relic 측의 신호 종류, 소유자, 필드 및 최신성 측면에서 모두 동일합니다. 오직 대상 영수증만 달라집니다. 이것이 바로 운영상의 경계입니다. LLM의 관측 가능성은 모델 호출 증거를 설명하며, 영수증은 에이전트가 의도한 결과가 존재함을 증명합니다. 실제 적용 범위는 작습니다: 1. 실제 모델 콜 경계 중 하나를 선택하십시오. 2. 배포 시 예상되는 계측 장비 소유자와 허용되는 신호 종류를 기록하십시오. 3. 합성 통화 ID를 하나 생성하고, 해당 ID와 관련된 모든 New Relic 이벤트 유형을 조회합니다. 4. 예상된 소유자가 부재 중이거나, 선언되지 않은 소유자가 나타날 경우 배포를 중단한다. 5. 필수 입력 항목과 유효 기간 범위를 확인하십시오. 6. working 레코드와 명명된 대기 종속성, 또는 complete 를 각각 별도로 기록하십시오. 7. complete 를 ‘정상’ 상태로 전환하기 전에 결정론적 수신 확인을 받아야 합니다. 8. SDK, 콜백, 익스포터 또는 에이전트 업그레이드 후에는 이 절차를 반복하십시오. 이 절차에는 한 가지 한계가 있습니다. 즉, New Relic가 지원하는 모든 통합이 모든 프레임워크 조합에 대해 이중 계측을 수행한다는 사실을 증명하지는 않습니다. 이 절차는 사용자가 관찰한 배포 환경 이 선언된 소유권 계약과 일치하는지 여부를 증명할 뿐입니다. 또한 이 절차는 New Relic의 호환성 검사나 완전한 OpenTelemetry 스키마 적합성 테스트를 대체하지도 않습니다. Sidewisp의 의도된 역할은 이러한 구분과 밀접한 관련이 있습니다. 즉, 접근성, 실질적인 진전, 도구, 결과, 시간 및 예산에 대한 증거를 통합하여 에이전트 상태 관점을 제공하는 것입니다. Sidewisp는 현재 비공개 프리뷰 단계입니다. 현재 출시된 제품은 얼리 액세스 웹사이트 및 데모 버전이며, 정식 버전의 New Relic 어댑터, 모니터링 엔진 및 자동 복구 실행기는 제공되지 않습니다. Sidewisp가 현재 이러한 데이터를 수집하거나 문제를 해결한다고 가정하기보다는, 위의 감사 항목을 현재 사용 중인 텔레메트리 및 대상 시스템에 적용하여 활용하십시오. 이 해결책은 적용하기 매우 간단합니다. 모델 호출 경계마다 하나의 선언된 계측 소유자를 지정하고, 매니페스트에서 허용하는 경우에만 여러 종류의 신호를 사용하며, 새로운 콘텐츠가 포함되지 않은 증거를 제공하고, 명시적인 대기 상태를 설정하며, 독립적인 결과 수신 확인을 수행하면 됩니다. 녹색 New Relic 뷰는 해당 경계들이 일치한 후에야 에이전트 운영에 있어 신뢰할 수 있게 됩니다.