트레이스

최종 수정: 2026. 1. 16.

트레이스

분산 트레이싱을 사용하여 마이크로서비스 간 요청 흐름을 추적하고 분석하는 방법을 안내합니다.


개요

분산 트레이싱은 마이크로서비스 아키텍처에서 요청이 여러 서비스를 거쳐 처리되는 과정을 추적합니다.

핵심 개념

개념 설명
Trace 하나의 요청 전체 흐름
Span 트레이스 내 개별 작업 단위
Trace ID 트레이스 고유 식별자
Span ID 스팬 고유 식별자
Parent Span 부모 스팬 (호출자)

트레이스 구조

Trace ID: abc123
├── Span: Frontend (100ms)
│   ├── Span: API Gateway (80ms)
│   │   ├── Span: Auth Service (20ms)
│   │   └── Span: User Service (50ms)
│   │       └── Span: Database Query (30ms)
│   └── Span: Cache Lookup (5ms)

트레이스 탐색기 접근

  1. 좌측 메뉴에서 Traces 클릭
  2. 트레이스 탐색기 화면이 표시됩니다

화면 구성

trace-00.png


트레이스 검색

기본 필터

필터 설명
시간 범위 조회 기간 선택
서비스 특정 서비스의 트레이스
작업 (Operation) 특정 엔드포인트/메서드
상태 OK, Error
지연시간 최소/최대 지연시간

지연시간 필터

  • 1초 이상: 느린 요청 찾기
  • P99 이상: 이상치 탐지

태그 검색

특정 속성으로 검색:

http.status_code = 500
http.method = POST
http.url contains /api/users
user.id = 12345

Trace ID로 검색

특정 트레이스를 직접 조회:

trace_id = abc123def456

트레이스 상세 보기

타임라인 뷰

트레이스를 선택하면 스팬들이 워터폴 형식으로 표시됩니다:

trace-01.png

스팬 정보

스팬을 클릭하면 상세 정보가 표시됩니다:

정보 설명
Service 서비스 이름
Operation 작업 이름
Duration 지연시간
Start Time 시작 시간
Status 상태 (OK/Error)
Tags 속성 (HTTP 메서드, URL 등)
Logs 스팬 내 이벤트

에러 표시

에러가 발생한 스팬은 빨간색으로 표시되며:

  • 에러 메시지
  • 스택 트레이스 (있는 경우)
  • 에러 유형

APM Agent 자동 트레이싱

APM Agent (eBPF)가 자동으로 수집하는 트레이스:

지원 프로토콜

프로토콜 자동 수집 내용
HTTP 요청/응답, 헤더, 상태 코드
gRPC 메서드, 상태, 메타데이터
SQL 쿼리, 테이블, 지연시간
Redis 명령어, 키, 지연시간
Kafka 토픽, 파티션, 오프셋

수집되는 속성

http.method: GET
http.url: /api/users/123
http.status_code: 200
http.request_content_length: 0
http.response_content_length: 1024

서비스 간 추적

컨텍스트 전파

트레이스 컨텍스트가 서비스 간에 자동으로 전파됩니다:

분산 트랜잭션 추적

여러 서비스에 걸친 트랜잭션을 단일 트레이스로 확인:

  1. 요청 시작점 서비스 선택
  2. 전체 트레이스 워터폴 확인
  3. 병목 지점 식별

성능 분석

느린 요청 찾기

  1. 지연시간 필터 설정: > 1s
  2. 결과에서 가장 느린 트레이스 선택
  3. 워터폴에서 병목 스팬 확인

P95/P99 분석

  1. Traces 메뉴에서 서비스 선택
  2. 지연시간 분포 히스토그램 확인
  3. 이상치 트레이스 분석

서비스별 지연시간

서비스 A: 평균 50ms, P95 120ms, P99 500ms
서비스 B: 평균 30ms, P95 80ms, P99 200ms
서비스 C: 평균 100ms, P95 250ms, P99 800ms ← 병목

에러 추적

에러 트레이스 필터

  1. 상태 필터: Error 선택
  2. 에러가 발생한 트레이스만 표시

에러 분석

에러 스팬에서 확인할 수 있는 정보:

정보 설명
error.message 에러 메시지
error.type 에러 유형
error.stack 스택 트레이스
http.status_code HTTP 상태 코드

에러 패턴 식별

동일한 에러가 반복되는지 확인:

  1. 에러 메시지로 그룹핑
  2. 발생 빈도 확인
  3. 공통 원인 분석

로그 연결

트레이스에서 로그로

  1. 트레이스 상세 보기에서 View Logs 클릭
  2. 해당 Trace ID의 로그가 자동으로 필터링됨

로그에서 트레이스로

  1. 로그 탐색기에서 Trace ID가 있는 로그 클릭
  2. View Trace 링크 클릭
  3. 해당 트레이스로 이동

서비스 맵 연동

트레이스에서 Service Map으로

  1. 트레이스 상세에서 서비스 클릭
  2. View in Service Map 선택
  3. 해당 서비스의 연결 관계 확인

Service Map에서 트레이스로

  1. Service Map에서 엣지 클릭
  2. Recent Traces 섹션에서 트레이스 선택
  3. 트레이스 상세 보기로 이동

샘플링

샘플링이란?

모든 트레이스를 저장하면 스토리지 비용이 높아집니다. 샘플링으로 일부만 저장:

샘플링 유형 설명
Head-based 요청 시작 시 샘플링 결정
Tail-based 요청 완료 후 샘플링 결정
Rate limiting 초당 최대 트레이스 수 제한

샘플링 설정

APM Agent 설정에서:

otel_traces_export:
  sampler:
    name: parentbased_traceidratio
    arg: "0.1"  # 10% 샘플링

문제 해결

트레이스가 표시되지 않음

  1. 시간 범위 확인
  2. 필터 조건 확인
  3. APM Agent 상태 확인:
    kubectl logs -n skuber-observability -l app.kubernetes.io/name=skuber-apm-agent

트레이스가 끊김

  1. 컨텍스트 전파 확인
  2. 서비스 간 헤더 전달 확인
  3. 수동 계측이 필요한지 확인

스팬 누락

  1. 해당 서비스에 APM Agent가 설치되었는지 확인
  2. 프로토콜이 지원되는지 확인
  3. 필터링되지 않았는지 확인

다음 단계

  • 서비스 맵 - 서비스 토폴로지 시각화
  • 서비스 - APM 서비스 상세
  • 자동 계측 - APM Agent 설정
  • 알림 - 지연시간 기반 알림 설정