Phoenix LLM 관찰 가능성: 다시 시작 후에도 추적이 유지되는지 입증

Phoenix는 자체 증거 레이어가 여전히 취약한 상태에서도 완전한 흔적을 보여줄 수 있습니다. 접근 가능한 페이지는 웹 프로세스가 이제 응답한다는 것을 증명합니다. 다시 시작해도 이전 추적이 유지되었는지, 수집기가 수집을 재개했는지, 팀에서 사고를 조사하는 기간 동안 유효한 보존 정책이 적용되는지 여부는 증명되지 않습니다 . 합리적인 기본값은 두 개의 카나리아 다시 시작 훈련입니다. 1. 다시 시작하기 전에 생성된 콘텐츠 없는 추적 하나를 쿼리합니다. 2. 애플리케이션 코드를 변경하지 않고 Phoenix 서비스를 다시 시작합니다. 3. 동일한 추적을 다시 쿼리합니다. 4. 다시 시작한 후 두 번째 추적을 내보내고 쿼리합니다. 5. 관찰 기간과 유효 보존 기간을 명시적인 한계와 비교합니다. 이전 카나리아는 지속성을 테스트합니다. 새로운 카나리아 테스트에서 수집이 재개되었습니다. 둘 다 필요합니다. 이전 추적만 존재하는 경우 수집이 중단되어도 저장은 문제가 없을 수 있습니다. 새 추적만 존재하는 경우 서버가 비어 있거나 예상치 못한 저장소로 돌아온 것입니다. Phoenix를 3개의 증거 레이어로 처리 Phoenix의 아키텍처 문서 시스템을 웹 인터페이스, 추적 수집기 및 SQL 데이터베이스 백엔드로 분리합니다. 진단 중에는 이러한 구별이 중요합니다. OTLP 수집이 실패하는 동안 인터페이스가 응답할 수 있습니다. 수집기는 추적을 쿼리할 수 없는 동안 연결을 수락할 수 있습니다. 컨테이너가 새로운 SQLite 작업 디렉터리를 가리키는 동안 데이터베이스에 접근할 수 있습니다. 보존 작업이 사고 프로세스가 예상하는 것보다 빨리 증거를 제거하는 동안 세 가지 모두가 작동될 수 있습니다. Phoenix는 SQLite와 PostgreSQL을 지원합니다. 현재 문서에서는 SQLite를 로컬 개발 및 단일 사용자 배포용으로 지정하고 있습니다. ~/.phoenix/ 또는 PHOENIX WORKING DIR . PostgreSQL은 다중 사용자 및 고가용성 배포를 위한 문서화된 프로덕션 선택입니다. 이것은 SQLite가 항상 건강하지 않다는 규칙은 아닙니다. 단일 개발자는 마운트된 볼륨으로 안정적인 로컬 인스턴스를 실행할 수 있습니다. 실패는 지속성을 암시적으로 남겨둡니다. 그만큼 공식 도커 가이드 두 계약을 직접 보여줍니다. PostgreSQL의 경우 Phoenix는 다음을 읽습니다. PHOENIX SQL DATABASE URL ; 가이드에는 PostgreSQL 14 이상에 대한 문서가 나와 있습니다. 건강 영수증이 아닌 비밀 시스템에 연결 값을 보관하십시오. 영수증에는 백엔드 클래스, 불투명 배포 식별자, 카나리아 쿼리 결과만 필요합니다. 이미지를 고정하는 것은 별도의 컨트롤입니다. latest 일회용 로컬 평가판에는 편리할 수 있지만 다시 시작하면 애플리케이션과 해당 데이터베이스 기대치를 동시에 변경할 수 있습니다. 드릴 전에 변경할 수 없는 이미지 다이제스트 또는 명시적인 버전을 기록하세요. 알 수 없는 이미지에 대한 성공적인 재시작은 재현 가능한 증거가 아닙니다. 콘텐츠가 없는 재시작 영수증을 하나 만들어 보세요. 관심 있는 에이전트 트래픽과 동일한 수집기 및 프로젝트 라우팅을 실행하는 카나리아 경로를 선택하세요. 카나리아에 실제 프롬프트, 모델 응답, 도구 인수, 자격 증명 또는 고객 식별자를 넣지 마십시오. 임의 실행 레이블과 타임스탬프이면 충분합니다. Phoenix의 문서화된 REST 엔드포인트는 다음을 수행할 수 있습니다. 프로젝트의 트레이스 나열 시작 시간 범위와 선택적 범위가 있습니다. 배포의 인증 방법을 사용하되 셸 기록 및 저장된 출력에서 ​​인증 값을 유지하세요. 예를 들어 비밀이 아닌 라우팅 값을 설정하고 짧은 기간을 요청합니다. 카나리아의 불투명에 대한 응답을 로컬에서 검색합니다. trace id ; 응답 본문을 일반 원격 분석으로 내보내지 마세요. 당신이 요청하는 경우 include spans=true , 응답 크기 및 쿼리 대기 시간이 증가하므로 Phoenix API 참조에서는 범위 세부 정보를 느리게 가져오는 것을 권장합니다. 다시 시작 훈련에는 프롬프트 내용이 아닌 추적 ID와 시간이 필요합니다. 최소 영수증은 다음과 같습니다. effectiveRetentionDays 단순한 배포 기본값이 아닌 실제 프로젝트에 첨부된 정책을 의미합니다. 피닉스 기본적으로 데이터를 무기한 보관합니다., 기본 정책에서는 0일로 표시됩니다. 관리자는 개별 프로젝트에 시간 또는 추적 수 기반 정책을 할당할 수 있습니다. 배포 시간 기본값은 기존 프로젝트별 재정의를 변경하지 않고도 새 프로젝트를 업데이트할 수 있습니다. 그렇기 때문에 구성 의도와 효과적인 프로젝트 상태가 다른 증거입니다. 유지율을 운영 프로세스와 비교하세요. 사고가 14일 동안 눈에 띄지 않을 수 있는 경우 모든 현재 추적이 존재하더라도 7일 추적 기간이 저하됩니다. 30일도 본질적으로 건강하지 않습니다. 이는 검토 기간, 스토리지 예산, 데이터 거버넌스 결정과 관련하여만 건전합니다. 방해를 숨기지 않고 훈련을 실행하세요 런타임의 일반적인 다시 시작 작업을 사용합니다. 첫 번째 훈련을 Phoenix 업그레이드, 스토리지 마이그레이션, 수집기 재구성 또는 애플리케이션 릴리스와 결합하지 마십시오. 요점은 지속성과 수집 재개를 분리하는 것입니다. 다시 시작하기 직전: 1. 고정된 버전 또는 이미지 다이제스트를 기록합니다. 2. 의도한 데이터베이스 백엔드와 내구성 있는 볼륨 또는 데이터베이스 ID를 확인합니다. 3. 효과적인 프로젝트 유지 정책을 기록합니다. 4. 일반적인 계측 경로를 통해 첫 번째 카나리아를 방출합니다. 5. 이를 쿼리하고 부울 결과, 추적 ID 및 타임스탬프만 저장합니다. 다시 시작한 후: 1. 임의의 절전 모드를 사용하는 대신 서비스의 문서화된 준비 동작을 기다립니다. 2. 동일한 재시작 전 추적을 쿼리합니다. 3. 재시작 후 다른 카나리아를 내보냅니다. 4. 동일한 프로젝트 경로를 통해 새 추적을 쿼리합니다. 5. 영수증에 스탬프를 찍고 신선도 한도가 만료되기 전에 평가하세요. 이 기사의 보조 장치는 5분 관찰 제한을 적용하고 9가지 상태를 재생합니다. 결과는 9/9 cases pass . 두 가지 구성이 정상으로 분류됩니다. 다중 사용자 배포를 위해 고정된 PostgreSQL과 단일 사용자를 위한 내구성 있는 볼륨이 있는 고정된 SQLite입니다. 나머지 고정 장치는 의도적으로 생성됩니다. evidence lost , ingestion failed , waiting , needs human , uncertain , 또는 degraded . 결정 우선순위가 중요합니다. 증거 평결 운영자 결정 마이그레이션이 계획대로 진행 중입니다. waiting 제한된 유지 관리 작업을 관찰합니다. 에이전트 실패라고 부르지 마세요. 마이그레이션 실패 needs human 자동 복구 중지 및 데이터베이스/버전 경계 검사 관찰 내용이 신선도 한도보다 오래되었습니다. uncertain 작업하기 전에 쿼리를 다시 실행하세요. 정책 내 오래된 흔적이 사라졌습니다. evidence lost 현재 스토리지를 보존하고 마운트/데이터베이스 ID를 먼저 진단합니다. 이전 흔적은 남아 있지만 새로운 흔적은 없습니다. ingestion failed 수집기 연결 가능성, 내보내기 경로, 인증 및 프로젝트 라우팅 검사 두 추적이 모두 존재하지만 보존 기간이 너무 짧습니다. degraded 효과적인 프로젝트 정책을 사고 검토에 맞춰 조정 두 가지 흔적이 모두 존재하고 증거가 신선하며 컨트롤이 일치합니다. healthy 증거 레이어가 이 제한된 드릴을 통과했습니다. 이 순서는 구성 경고로 인해 실제 데이터 손실이 가려지는 것을 방지합니다. 고정되지 않은 이미지도 중요하지만 정책 내 추적 누락이 첫 번째 사건입니다. 마이그레이션을 맹목적인 복구에서 제외 Phoenix에서는 새로운 주요 버전이 시작 중에 데이터베이스 마이그레이션을 실행할 수 있다고 문서화합니다. 또한 애플리케이션 이미지를 롤백해도 데이터베이스 스키마가 자동으로 다운그레이드되지 않음 경고합니다. 이로 인해 주요 업그레이드 실패 후 "이전 컨테이너 다시 시작"이 안전하지 않은 일반 복구 규칙이 됩니다. 쿠버네티스의 경우, 마이그레이션 가이드 에서는 마이그레이션을 실행할 것을 권장합니다. initContainer 따라서 기본 컨테이너가 활성 상태 검사를 받기 전에 완료됩니다. 또한 PostgreSQL 인덱스 생성이 쓰기를 차단할 수 있음을 설명합니다. PHOENIX MIGRATE INDEX CONCURRENTLY=true 쓰기 잠금을 유지하는 것을 방지하지만 문서화된 절충안은 마이그레이션이 대략 2~3배 느려지고 새 포드가 여전히 완료될 때까지 기다립니다. 해당 메커니즘을 상태로 변환합니다. 승인된 유지 관리 기간 내에 실행되는 마이그레이션은 waiting ; 마이그레이션 상태를 알 수 없는 동안 수행된 쿼리는 다음과 같습니다. uncertain ; 스키마를 발전시켰을 수 있는 실패한 마이그레이션은 다음과 같습니다. needs human ; 자동 롤백은 데이터베이스 호환성 계획에서 명시적으로 지원하는 경우에만 허용됩니다. 이는 다른 곳에서 신뢰할 수 있는 에이전트 작업에 필요한 것과 동일한 구별입니다. 활동이 진행되지 않고, 대기가 중단되지 않고, 명령 완료가 의도한 결과가 아닙니다. 이 영수증이 증명하지 못하는 것이 무엇인지 알아두세요 통과된 재시작 확인은 하나의 증거 경로를 보호합니다. 모든 모델 경로가 계측되었는지, 모든 범위가 의미상 정확했는지, 백업이 복원될 수 있는지 또는 에이전트가 의도한 결과를 전달했는지 여부는 입증되지 않습니다. 또한 LLM 평가 내용을 검증하지 않습니다. 그것들은 별도의 테스트입니다. 영수증에는 의도적으로 내용이 없습니다. 이는 노출을 줄이지만 의미론적 오류에는 제한된 평가 또는 사람의 검토가 필요하다는 의미이기도 합니다. 사용할 수 없는 증거를 사용할 수 없는 것으로 처리합니다. 건전한 추측으로 채우지 마세요. Sidewisp의 의도된 건강 모델은 증거의 신선도, 도달 가능성, 유용한 진행, 결과 및 안전한 복구 경계와 관련이 있습니다. 여기의 운영 패턴은 해당 영역에 적합하지만 통합이 제공된다는 주장은 아닙니다. Sidewisp 현재 Phoenix에 연결하지 않거나 이 배포를 모니터링하지 않습니다. Sidewisp는 현재 비공개 프리뷰 단계입니다. 에이전트 스택에 대한 첫 번째 상태 계약을 정의하는 경우 에이전트의 결과 영수증 옆에 이 다시 시작 영수증을 보관하십시오. 하나는 진단 증거가 살아남았는지 여부를 알려줍니다. 다른 하나는 작업이 수행되었는지 여부를 알려줍니다.