크라우니클라우드 B-2 서비스별 요청/오류 계측 배선
개요
서비스 상세 화면의 "오늘 요청 수 / 오류율"이 null(미계측)로 정직하게 비어 있던 것을,
실제 카운터를 배선해 진짜 수치로 교체.
무엇을 했는지
서비스서버.한선 (29개 서비스 공유 TCP 서버): 요청처리()가 상태코드(200/400/401/404 등,
알 수 있는 분기만)를 반환하도록 수정. 메인 루프에서 총요청/오류 메모리 카운터를 두고
100요청마다 1회
data/metrics/<서비스명>.psv(epoch|총요청|오류수|시작에포크)에 덮어쓰기 스냅샷.
- cloud는 gateway.yaml에서
/cloudapi/*가 별도 백엔드(9662, 클라우드관리.toau)로 분리
라우팅되는 것을 실측으로 확인 — 같은 "cloud.psv" 파일에 9611/9662 두 프로세스가 동시에
쓰면 덮어쓰기 경합이 생기므로, 9611(SERVICE=cloud, 서비스서버.한선) 쪽은
cloud-web.psv로 분리하고 9662(클라우드관리.한선)가 진짜
cloud.psv를 쓰도록 함.
클라우드_서비스.한선의 서비스_통계처리()(GET /api/services/stats?id=)가
data/metrics/<id>.psv를 읽어 requests/errorRate(1소수)를 채움. 파일 없으면(재기동 전
서비스) 여전히 null+note.
관련 파일
- /Users/ef/crowny-services/서비스서버.한선 (+ .bak-계측-20260731, .toau)
- /Users/ef/crowny-services/클라우드관리.한선 (+ .bak-계측-20260731, .toau)
- /Users/ef/crowny-services/클라우드_서비스.한선 (+ .bak-계측-20260731)
- /Users/ef/crowny-services/data/metrics/*.psv (신규 데이터 디렉토리)
검증
- 그림자(18099/18662) 300+ 요청, 의도적 404 20건 → 카운터 정확 일치 실측.
- 라이브 배포 후 id=cloud → 실측치 반환, id=bible(미재기동) → 여전히 null+note.
- 회귀: cloud/quote 인증 200/401, 정적 200, 공개 HTTPS 200 전부 정상.
- 성능: /api/health p50 9611 0.774→0.743ms, 9662 0.727→0.757ms — 유의미한 저하 없음.
잔여 이슈
- 하위 처리함수(store처리/anchor처리 등) 내부에서 자체 반환하는 상태코드는 요청처리() 레벨에서
알 수 없어 기본 200으로 집계됨(정직한 한계, 문서화됨) — 필요 시 각 처리함수가 상태코드를
반환하도록 추가 배선 가능.
- 29개 서비스 중 실제로 100요청 이상 받은 서비스만 metrics 파일이 생성됨(자연스러운 지연 계측).