trace 목록
각 행은 하나의 Guard API / Desktop Agent 호출이며, 입력, Guardian의 출력, 지연 시간, tags, 그리고 scores를 보여줍니다. Desktop Agent 호출의 경우, 트레이스의 session은 매칭된 Control Profile 이름이고, 그 metadata에는 요청의 URL, HTTP 메서드, Content-Type, 헤더가 담깁니다. 입력 호출과 그 출력 호출은 하나의 Trace ID를 공유하므로, 전체 요청→응답 주기를 하나의 트레이스로 볼 수 있습니다. API 호출의 경우, session은 호출자의session_id이며, 호출자는 동일한 trace_id를 전달하여 두 호출을 연결할 수 있습니다.
tags와 scores를 사용하면 쉽게 필터링하고 집계할 수 있습니다:
- 동작 —
PASS,MASK,BLOCK - 정책 결과 — 예:
PII Masking Policy:MASK,TOPIC:BLOCK - 호출자 — 예: API 키 이름
- 단계 —
process_type:input - scores — 정책 이름별로, 정책 유형별로 집계됨
trace 상세 정보
trace를 열면 전체 내용을 확인할 수 있습니다: 원본 입력,processed_content(마스킹된 출력), 결정된 action, 감지된 모든 항목, 그리고 호출 metadata(API 키, 모델 구성, process type).
Opticon Fail-Safe (Fail-Open / Fail-Closed)
트레이스 기록은 원래 비동기입니다. Opticon이 다운되거나 무응답이어도 Guard 판정(PASS / MASK / BLOCK)은 그대로 반환되고 기록만 유실됩니다 — 관측 평면은 fail-open입니다. 그러나 감사가 필수인 운영에서는 이 공백이 문제가 됩니다. 기록되지 않은 요청은 감사할 수 없는 요청이기 때문입니다. v1.3부터는 트레이스 기록이 끝내 실패할 때의 동작을 Project Settings → General의 Opticon Fail-Safe 설정으로 프로젝트 단위로 선택할 수 있습니다:
| 모드 | 기록 방식 | 기록이 끝내 실패하면 | 우선 가치 |
|---|---|---|---|
| Fail-Open (기본값) | 비동기 best-effort — 기존 동작 | 기록만 유실, 판정은 그대로 반환 | 가용성·지연 |
| Fail-Closed | 기록 성공이 응답의 선행 조건이 됨 | 해당 요청을 BLOCK으로 강등 — 내용 미전달 | 감사성 |
- Opticon 로깅을 명시적으로 끈 entry (의도된 opt-out이지 장애가 아님)
- 애초에 트레이스를 생성하지 않는 경로 (인증 실패, deterministic 게이트, 미지원 입력, 한도 초과 거부)
- Opticon 바인딩이 구성되지 않은 프로젝트