한눈에 보기
FOWOCO의 요청이 Client → Server → AI Runtime → Task/Renewal을 지나는 동안 어디에서 얼마나 걸렸고 왜 실패했는지 개인정보 없이 확인하는 작업입니다.
단순 운영 로그가 아니라, 데모 발표의 정량적 평가와 기대효과 근거를 만드는 것이 이번 구현의 핵심입니다.
이번 구현 범위
Server 단계별 관측
Micrometer·Prometheus
정량 평가 산출물
이번에 하지 않는 것
- Grafana Dashboard
- OpenTelemetry Collector·Jaeger·Tempo
- AI 내부 BERT·A.X·LangGraph Node별 시간 측정
- Metric 저장을 위한 신규 DB 테이블·Flyway
- 관리자 화면 API
Grafana·OpenTelemetry와 실제 Prometheus 배포는 운영 고도화 범위로 유지합니다. 이번 PR은 Server 저장소 안에서 로컬 측정 구성까지 완결합니다.
측정 경계
| 측정값 |
담당 |
| Client 요청부터 Candidate/질문 응답까지 |
Server |
| PLAN·Slot 조회·ANALYZE·결과 저장 구간 |
Server |
| Renewal Context·Runtime·문서 생성 구간 |
Server |
| BERT·A.X 모델 내부 추론시간·성능 |
AI |
| 배포 Prometheus 장기 보관·운영 알림 |
Infra |
안전 규칙
Metric tag에는 종류가 제한된 아래 값만 사용합니다.
phasestagestatusoutcomefailure_code
다음 값은 로그 본문이나 Metric tag에 넣지 않습니다.
companyId, workerId, taskId- 실명, 연락처, 이메일, 여권번호, 외국인등록번호
- Worker Link 원본 Token, JWT, API Key
- HR 발화문, 실제 Slot 값, Prompt 전문, AI 전체 응답
requestId와 attemptId는 문제 추적용 구조화 로그에서만 사용하고 Metric tag에는 사용하지 않습니다.
완료 조건
현재 검증 결과
./gradlew clean test: 557 tests, 0 failures, 37 skipped- 핵심 단계·endpoint 통합 테스트: 성공
docker compose -f compose.observability.yml config: 성공- 로컬 Prometheus Target
fowoco-server-local: 1/1 UP
/actuator/prometheus 실제 scrape 및 PromQL 조회: 성공
후속 정량 측정
정상 PLAN→ANALYZE, OUT_OF_SCOPE, NEEDS_INFO, timeout, Renewal 문서 생성의 반복 측정값 취합은 대표 흐름 E2E 이슈 #10에서 진행합니다. #26에서는 해당 값을 수집할 Server 로그·Metric·PromQL 경로까지 완성했습니다.
현재 기반
관계
한눈에 보기
FOWOCO의 요청이
Client → Server → AI Runtime → Task/Renewal을 지나는 동안 어디에서 얼마나 걸렸고 왜 실패했는지 개인정보 없이 확인하는 작업입니다.단순 운영 로그가 아니라, 데모 발표의 정량적 평가와 기대효과 근거를 만드는 것이 이번 구현의 핵심입니다.
이번 구현 범위
Server 단계별 관측
PLAN_RUNTIME_CALLSLOT_RESOLUTIONANALYZE_RUNTIME_CALLRESULT_PERSISTTOTALCONTEXT_LOADRENEWAL_RUNTIME_CALLDOCUMENT_GENERATIONRESULT_APPLYTOTALfailure_code로 구분Micrometer·Prometheus
Timer와 결과·실패Counter추가Timer와 실패Counter추가micrometer-registry-prometheus와/actuator/prometheus구성정량 평가 산출물
이번에 하지 않는 것
Grafana·OpenTelemetry와 실제 Prometheus 배포는 운영 고도화 범위로 유지합니다. 이번 PR은 Server 저장소 안에서 로컬 측정 구성까지 완결합니다.
측정 경계
안전 규칙
Metric tag에는 종류가 제한된 아래 값만 사용합니다.
phasestagestatusoutcomefailure_code다음 값은 로그 본문이나 Metric tag에 넣지 않습니다.
companyId,workerId,taskIdrequestId와attemptId는 문제 추적용 구조화 로그에서만 사용하고 Metric tag에는 사용하지 않습니다.완료 조건
PLAN → Slot 조회 → ANALYZE → 결과 저장의 단계별 시간과 실패 원인을 확인할 수 있음./gradlew clean test성공현재 검증 결과
./gradlew clean test: 557 tests, 0 failures, 37 skippeddocker compose -f compose.observability.yml config: 성공fowoco-server-local:1/1 UP/actuator/prometheus실제 scrape 및 PromQL 조회: 성공후속 정량 측정
정상 PLAN→ANALYZE, OUT_OF_SCOPE, NEEDS_INFO, timeout, Renewal 문서 생성의 반복 측정값 취합은 대표 흐름 E2E 이슈 #10에서 진행합니다. #26에서는 해당 값을 수집할 Server 로그·Metric·PromQL 경로까지 완성했습니다.
현재 기반
관계