OpenTelemetry LLM 관찰 가능성: 녹색 이전에 스키마 고정

OpenTelemetry LLM 관찰 가능성은 원격 분석에 선언된 의미가 있는 경우에만 유용합니다. GenAI 추적을 운영 증거로 처리하기 전에 의미 체계 개정을 고정하고, 각 작업에 필요한 필드의 유효성을 검사하고, 승인되지 않은 콘텐츠 캡처를 거부하고, 예상되는 작업이 있음을 증명한 다음 신선도, 작업 상태 및 외부 결과를 개별적으로 평가합니다. 이 순서는 2026년 7월에 중요합니다. OpenTelemetry 웹 사이트는 이제 GenAI 규칙을 다음과 같이 가리킵니다. 전용 저장소. 이 기사에 대해 검사된 소스 개정에서, 434c91dcc34ed038e3048c07720ddfed2c6bddfc , 저장소의 README에는 여전히 스키마 URL이 TODO로 나열되어 있습니다., 생성 클라이언트 범위 문서는 Development 로 표시됩니다. 이는 OpenTelemetry를 피해야 하는 이유가 아닙니다. 호환성을 명시적으로 명시하는 이유입니다. GenAI 범위가 포함된 대시보드는 여전히 이전 생산자, 현재 수집기 및 세 번째 속성 형태에 대해 작성된 쿼리를 결합할 수 있습니다. 안전한 기본값은 수집기 구성 옆에 있는 작은 버전의 허용 프로필입니다. 실제로 운영하는 계약을 고정하세요. OpenTelemetry의 GenAI 저장소는 LLM 클라이언트, 에이전트, 도구 실행, 평가, 메모리, 검색 및 MCP. 해당 문서는 부분적으로 YAML 모델에서 생성되는데, 이는 소스를 검사 및 테스트할 수 있다는 점에서 가치가 있습니다. 이는 또한 "우리는 OTel을 사용합니다"가 호환성 주장이 되기에는 너무 모호하다는 것을 의미합니다. 모든 계측 배포에서 네 가지 ID를 기록합니다. 신원 예 왜 중요한가요? 컨벤션 소스 리포지토리와 커밋 SHA 검토한 속성 및 작업 계약을 정의합니다. 계측 패키지 패키지 이름 및 버전 범위를 방출한 항목을 식별합니다. 수집기 파이프라인 구성 다이제스트 및 배포 ID 변환, 필터 및 내보내기를 식별합니다. 계약 조회 대시보드 또는 경고 버전 결과가 예상하는 필드를 식별합니다. 어떤 필드가 도착하더라도 규칙 개정을 추론하지 마십시오. 이는 조용한 드리프트를 명백한 호환성으로 바꿉니다. 생산자가 개정을 선언할 수 없는 경우 배치를 다음과 같이 분류합니다. schema drift 해당 생산자 형태를 테스트하고 등록할 때까지 말이죠. 이는 프레임워크 기본 계측과 외부 계측이 공존하는 경우 특히 중요합니다. OpenTelemetry의 에이전트 관찰 가능성 지침 내장된 계측의 유지 관리 장단점을 설명하고 외부 패키지가 충돌할 수 있음을 경고합니다. 그렇지 않으면 동일한 모델 호출이 두 번 관찰되거나 부분 업그레이드 후 하나의 경로가 이전 규칙에 남아 있을 수 있습니다. 실제 규칙은 간단합니다. 작업 경로당 하나의 예상 원격 측정 생성자, 롤아웃 코호트당 하나의 선언된 규칙 개정, 코호트가 승격되기 전에 통과해야 하는 카나리아 추적입니다. 전체 스키마 전에 작은 운영 프로필을 검증합니다. 완전한 의미론적 규칙 유효성 검사기는 저장소 모델에서 생성될 수 있습니다. 운영 게이트는 더 작게 시작해야 합니다. 현재 결정에 영향을 미치는 필드만 적용한 다음 더 많은 작업을 사용함에 따라 프로필을 확장하세요. 고정된 개정판에서는 추론 범위 테이블 점수: 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. 스키마 ID — 생산자가 고정된 개정과 일치합니까? 2. 스키마 유효성 — 필수 필드와 조건 필드가 유효합니까? 3. 콘텐츠 정책 — 이 경로에 선택 필드가 허용됩니까? 4. 범위 — 예상되는 작업이 모두 표시됩니까? 5. 신선성 — 워크플로우에 적합한 최신 증거입니까? 6. 작업 상태 — 상담원이 작업 중, 대기 중, 정체 상태, 불확실함, 완료 상태입니까? 7. 결과 — 약속된 결과가 목적지에 존재합니까? 이 기사의 10개 케이스 고정 장치는 의도적으로 해당 레이어를 불편하게 만듭니다. 여기에는 다음이 포함됩니다. 고정되지 않은 제작자 및 레거시 제작자 추론 범위가 누락되었습니다. gen ai.provider.name ; 오류 범위가 누락되었습니다. error.type ; 허가 없는 옵트인 콘텐츠 키 예상되는 도구 범위가 누락된 워크플로 결과 영수증 없이 완전한 추적; 검증되었지만 오래된 추적입니다. 합법적인 인간 승인 대기; 신선하고 보장되며 결과가 검증된 사례 1개. 다음을 사용하여 아티팩트를 실행합니다. 실행 결과는 정확히 10가지 경우로 분류되었습니다. 그만큼 complete no receipt 케이스가 핵심 경계입니다. 생산자 개정이 일치합니다. 해당 범위에는 프로필에 필요한 필드가 포함되어 있습니다. 예상되는 에이전트 및 모델 작업이 존재합니다. 원격 측정이 신선합니다. 아직도 돌아오네요 unverified 티켓, 파일, 배포 또는 기타 약속된 결과가 존재함을 입증하는 대상 영수증이 없기 때문입니다. 그만큼 waiting for approval 케이스는 다른 경계를 유지합니다. 최근의 적합성 범위는 소유자 및 기한이 있는 지정된 사람의 승인에서 중지됩니다. 그것은 노점이 아닙니다. 에이전트가 실패한 것처럼 운영자에게 페이징을 하면 유용한 상태 정보가 삭제됩니다. 감사를 릴리스 및 사고 통제로 전환 세 순간에 이 테스트를 실행합니다. 계측 업그레이드 전에 현재 버전, 패키지 버전, 수집기 다이제스트 및 예상 작업을 캡처하세요. 제안된 스택에 대해 고정된 픽스처를 재생합니다. 변경된 평결은 승진 전에 설명되어야 합니다. 롤아웃 중에 등록된 모든 모델, 에이전트 및 도구 경로를 통해 콘텐츠가 없는 카나리아를 내보냅니다. 각 카나리아가 한 번 도착하고, 예상 생산자 신원을 전달하고, 운영 프로필을 통과하고, 신선도 창 내에서 검색 가능한 상태로 유지되는지 확인하세요. 사고 발생 시 4개의 레이어를 "관찰 가능성이 손상되었습니다."로 축소하는 대신 보존하세요. 스키마 드리프트에는 생산자와 쿼리 조정이 필요합니다. 적용 범위 공백으로 인해 기기 수리가 필요합니다. 오래된 원격 분석에서는 수집기 또는 내보내기 진단이 필요합니다. waiting 명명된 소유자를 호출합니다. unverified 다른 모델 재시도가 아닌 대상 확인이 필요합니다. 원격 분석 필드가 변경되었기 때문에 에이전트를 자동으로 복구하지 마세요. 컨벤션 드리프트는 기본 작업을 건강하지 않게 만들지 않으면서 증거를 불확실하게 만들 수 있습니다. 활성 복구를 중단하고, 실패한 증거 레이어를 식별하고, 신뢰도를 회복하는 가장 작은 가역적 테스트를 사용합니다. 스키마 프로필에도 소유자가 필요합니다. 커밋을 영원히 고정하는 것은 안전하지 않습니다. 그것은 결국 침체이다. 검토 주기를 할당하고, GenAI 저장소를 관찰하고, 핀을 이동할 때 고정 장치 차이를 요구합니다. OpenTelemetry가 나중에 안정적인 GenAI 스키마 URL을 게시하는 경우 생산자와 쿼리가 지원할 때 이를 채택하되 적용 범위, 최신성, 대기 및 결과 확인을 독립적으로 유지하세요. Sidewisp는 현재 비공개 프리뷰 단계입니다. 공개 경험은 초기 액세스 웹사이트와 대화형 데모입니다. 프로덕션 에이전트 상태 수집, 호스트 어댑터 및 복구는 현재 웹 사이트 저장소에 제공되지 않습니다. 제품 방향은 OpenTelemetry 수집기, 추적 백엔드 또는 자율 수정 프로그램이 아닌 기존 런타임 주변의 상태 계층입니다. 개정 고정 증거와 별도의 결과 검증이 포착해야 하는 실패와 일치하는 경우 다음을 수행할 수 있습니다. Sidewisp 비공개 미리보기에 참여하세요 그리고 귀하가 운영하는 에이전트 런타임 및 원격 측정 경로를 설명합니다.