Logging Metrics Tracing
3줄 요약
- Logging, Metrics, Tracing은 장애를 “무슨 일이 있었는가”, “얼마나 자주/크게 일어났는가”, “어느 호출 경로에서 느려졌는가”로 나눠 설명하는 관측 체계다.
- 핵심은 도구를 많이 붙이는 것이 아니라 correlation id, metric label, trace id를 같은 요청과 같은 시간대로 연결할 수 있게 만드는 것이다.
- Spring 백엔드 개발자는 log field, Micrometer metric, Actuator endpoint, span, alert 증거를 보고 장애 원인 후보를 좁힐 수 있어야 한다.
핵심 정리
- Structured Logging은 로그를 검색 가능한 field로 남긴다. correlation id가 있으면 한 요청의 여러 로그를 묶을 수 있다.
- Metrics는 전체 흐름을 숫자로 본다. counter는 누적 횟수, gauge는 현재 상태, histogram은 분포와 latency를 설명한다.
- Distributed Tracing은 여러 서비스와 DB/HTTP 호출을 span으로 연결한다. 느린 구간을 요청 경로 안에서 찾는 데 유용하다.
- Spring Boot Actuator와 Micrometer는 애플리케이션 내부 상태를 health, info, prometheus, custom metric으로 노출하는 기본 통로다.
- 로그, 메트릭, 트레이스는 서로 대체하지 않는다. 로그는 문맥, 메트릭은 규모, 트레이스는 경로를 담당한다.
헷갈리는 지점
- 로그가 많으면 관측성이 좋다고 생각하기 쉽다.
- 핵심은 많은 문자열보다 검색 가능한 field, request id, 민감 정보 통제, 샘플링 기준이 더 중요하다는 점이다.
- 메트릭 평균만 보면 성능을 알 수 있다고 생각하기 쉽다.
- 핵심은 평균은 tail latency를 숨기므로 histogram, percentile, endpoint/status별 분리가 필요하다는 점이다.
- 트레이스가 있으면 원인이 자동으로 나온다고 생각하기 쉽다.
- 핵심은 span 이름, tag, sampling, error 표시가 부실하면 trace도 긴 로그 목록이 될 뿐이라는 점이다.
확인 질문
- 로그, 메트릭, 트레이스의 역할 차이는 무엇인가?
- 로그는 사건의 문맥, 메트릭은 규모와 추세, 트레이스는 요청이 지나간 경로와 구간별 시간을 보여준다.
- correlation id와 trace id가 필요한 이유는 무엇인가?
- 장애 중 같은 요청의 로그, metric exemplar, trace를 연결해 추측이 아니라 증거로 원인 후보를 좁히기 위해서다.
- metric label을 조심해야 하는 이유는 무엇인가?
- user id, order id처럼 값 종류가 많은 label은 cardinality를 폭증시켜 저장 비용과 조회 성능 문제를 만들 수 있기 때문이다.