메트릭·로그·트레이스는 서로 다른 질문에 답한다

한 줄 요약

메트릭은 전체 추세와 경보를, 구조화 로그는 한 사건의 문맥을, 트레이스 식별자는 경계를 지난 인과관계를 설명한다. 세 신호는 같은 요청에서 나온 안전한 상관 필드로 연결되어야 한다.

왜 로그 한 줄로 장애를 풀 수 없는가

error happened라는 문자열은 얼마나 자주, 어느 경로에서, 어떤 상태로 실패했는지 알려 주지 않는다. 주문 생성 수와 HTTP 지연 시간 메트릭은 변화와 임계치를 보여 준다. JSON 로그의 event, route, status, duration_ms는 개별 요청을 검색하게 한다. 응답 헤더와 로그에 같은 trace ID를 넣으면 사용자가 제보한 요청을 정확히 찾을 수 있다. 서비스가 여러 개라면 이 ID를 다음 호출에 전파한다.

메트릭 이름은 orders_created_total, http_request_duration_seconds처럼 단위와 누적 의미가 드러나야 한다. 사용자 ID나 주문 ID를 메트릭 라벨로 쓰면 카디널리티가 폭발한다. 그런 고유 값은 필요한 경우 로그에 넣되 개인정보와 비밀값 정책을 적용한다. 인증 헤더, 쿠키, 비밀번호, 연결 문자열, 내부 서비스 DNS는 어느 신호에도 기록하지 않는다.

현장에서 검증하는 방법

채점기는 서버에 생성 요청을 보내 응답의 trace ID를 얻고, /metrics에서 두 핵심 지표를 읽는다. 서버 종료 후 각 로그 줄을 JSON으로 파싱해 같은 trace ID, /orders 경로, 201 상태, 숫자 duration_ms가 한 레코드에 있는지 확인한다. 단순히 소스에 json이나 trace_id 문자열이 있는지는 증거가 아니다. import 시 출력이 생기거나 토큰 원문이 로그에 나타나도 실패한다.

실무 판단 기준

좋은 관측성은 사후 디버그 문장을 많이 찍는 것이 아니라 운영 질문을 먼저 정하고 낮은 비용의 신호를 설계하는 일이다. 성공률, 오류율, 지연 시간, 트래픽을 메트릭으로 보고 특정 이상을 trace와 로그로 좁힌다. 이어지는 배포 레슨에서는 이 신호가 정상이어도 준비되지 않은 파드로 트래픽을 보내지 않도록 프로브와 실행 보안 경계를 설계한다.