103 lines
8.4 KiB
Markdown
103 lines
8.4 KiB
Markdown
---
|
|
title: OpenTelemetry Sampling — Head-based vs Tail-based
|
|
source_type: official-doc
|
|
url: https://opentelemetry.io/docs/concepts/sampling/
|
|
archive_url:
|
|
status: raw
|
|
confidence: high
|
|
tags: [ca-distributed-tracing, opentelemetry, sampling, tail-based, head-based, official-doc]
|
|
related_projects: [ca-skeleton-operational-contract]
|
|
related_branches: [feature-distributed-tracing-contract]
|
|
created: 2026-05-22
|
|
last_reviewed: 2026-05-27
|
|
---
|
|
|
|
# OpenTelemetry Sampling — Head-based vs Tail-based
|
|
|
|
> Layer: `raw/official-docs/` — OpenTelemetry 공식 Sampling 개념 문서 verbatim. ca-tmpl 의 sampling 전략 (head-based 1% + force-sample boost) 대안 비교 근거.
|
|
|
|
## Parent / 활용 branch (필수)
|
|
|
|
| Branch | 이 자료가 정당화하는 결정 |
|
|
|---|---|
|
|
| [[raw/branch-notes/feature-distributed-tracing-contract]] | sampling 전략 결정 (head-based TraceIdRatioBased + force-sample boost vs tail-based collector buffering) 비교의 spec 근거 |
|
|
| [[raw/project-notes/ca-skeleton-operational-contract]] | §Distributed Tracing Contract 의 sampling 전략 대안 비교 (Group G-A 대안 2 — tail-based / adaptive) |
|
|
|
|
## 컨텍스트
|
|
|
|
ca-tmpl 이 결정한 "**trace sampling rate default = prod 1%, staging 10%, dev/local 100%. force-sample = error response, slow request (p99 초과), retry exhausted**" 의 sampling 전략 평가. head vs tail 위치 비교의 1차 근거.
|
|
|
|
## 출처 / Source
|
|
|
|
- 원본 URL: https://opentelemetry.io/docs/concepts/sampling/
|
|
- 아카이브 URL: (미수집)
|
|
- 저자 / 조직: OpenTelemetry Authors (CNCF)
|
|
- 발행일: rolling docs
|
|
- 마지막 확인일: 2026-05-27
|
|
|
|
## 핵심 인용 / Key quotes (verbatim)
|
|
|
|
> [§Head sampling] "Head sampling is a sampling technique used to make a sampling decision as early as possible."
|
|
|
|
> [§Head sampling] "A decision to sample or drop a span or trace is not made by inspecting the trace as a whole."
|
|
|
|
> [§Head sampling — advantages] "Easy to understand, Easy to configure, Efficient, Can be done at any point in the trace collection pipeline."
|
|
|
|
> [§Head sampling — disadvantages] "It is not possible to make a sampling decision based on data in the entire trace."
|
|
|
|
> [§Tail sampling] "Tail sampling is where the decision to sample a trace takes place by considering all or most of the spans within the trace."
|
|
|
|
## Claims Extracted / 추출된 주장
|
|
|
|
| Claim ID | Claim (이 자료가 직접 말하는 것) | Evidence quote | Strength | Applies to | Does not prove |
|
|
|---|---|---|---|---|---|
|
|
| OTEL-SAMP-C1 | Head sampling 은 가능한 한 이른 시점에 sampling decision 을 내리는 기법 | [§Head sampling] "Head sampling is a sampling technique used to make a sampling decision as early as possible." | `official-vendor-doc` | OpenTelemetry SDK 일반 sampling 모델 | "as early as possible" 의 정확한 위치 (root span 생성 시 vs propagator inject 시) 는 본 인용에 명시 없음 |
|
|
| OTEL-SAMP-C2 | Head sampling 은 trace 전체를 검사하여 결정하는 방식이 아님 (span 단독 정보로 결정) | [§Head sampling] "A decision to sample or drop a span or trace is not made by inspecting the trace as a whole." | `official-vendor-doc` | head sampler 의 결정 입력 범위 | 부모 span 의 sampled 결정을 child 가 상속할 수 없다는 뜻 아님 (ParentBased sampler 는 별도) |
|
|
| OTEL-SAMP-C3 | Head sampling 의 장점: 이해 쉬움, 설정 쉬움, 효율적, trace 수집 파이프라인의 어느 지점에서도 가능 | [§Head sampling — advantages] "Easy to understand, Easy to configure, Efficient, Can be done at any point in the trace collection pipeline." | `official-vendor-doc` | head sampling 채택 시 trade-off 평가 | 효율 (efficient) 의 정량적 기준 (CPU/메모리 절감) 은 본 인용에 없음 |
|
|
| OTEL-SAMP-C4 | Head sampling 의 단점: trace 전체 데이터 기반 결정 불가 (즉 error/slow trace 우선 보존 불가) | [§Head sampling — disadvantages] "It is not possible to make a sampling decision based on data in the entire trace." | `official-vendor-doc` | head sampler 의 한계 | force-sample 같은 boundary-specific boost 기법으로 일부 보완 가능하다는 뜻은 본 인용에 없음 (별도 SDK 구현) |
|
|
| OTEL-SAMP-C5 | Tail sampling 은 trace 의 모든 또는 대부분 span 을 고려하여 sample 결정을 내림 | [§Tail sampling] "Tail sampling is where the decision to sample a trace takes place by considering all or most of the spans within the trace." | `official-vendor-doc` | tail sampler 의 결정 시점 정의 | "모든 또는 대부분" 의 trade-off (decision_wait window 길이, missing span 처리) 는 본 인용 범위 밖 — Collector contrib `tailsamplingprocessor` 별도 |
|
|
| OTEL-SAMP-C6 | TraceIdRatioBased / ParentBased sampler / decision_wait window 등의 정확한 SDK 명세 | (본 페이지 발췌에 명시 없음) | `needs-confirmation` | head/tail sampler 의 구체 구현 | 본 OTel sampling 개념 페이지에는 TraceIdRatioBased / ParentBased / decision_wait 의 상세가 포함되지 않음 — 별도 SDK spec / Collector contrib 문서 필요 |
|
|
|
|
## Usage Boundaries / 적용 경계
|
|
|
|
- **이 자료가 직접 증명하는 것**:
|
|
- `OTEL-SAMP-C1` ~ `C5`: head sampling 과 tail sampling 의 정의, head 의 장단점, tail 의 결정 시점
|
|
- **이 자료가 증명하지 않는 것**:
|
|
- TraceIdRatioBased sampler 의 정확한 알고리즘 (trace_id range 의 deterministic 비율 매칭) — 본 페이지 발췌 부재
|
|
- ParentBased sampler 의 동작 (부모 sampled 결정 상속 정책) — 본 페이지 발췌 부재
|
|
- tail sampling 의 collector buffering 메모리 비용, `decision_wait` typical 값 (5~30 초) — 본 페이지 발췌 부재
|
|
- "tail sampling 이 head sampling 보다 항상 우월" 이라는 결론 — 운영 부담 vs 데이터 품질의 trade-off
|
|
- adaptive sampling (Honeycomb refinery, Datadog APM) 이 OTel 공식 표준이라는 결론 (vendor 구현)
|
|
- **내 프로젝트에 적용하려면 추가 확인이 필요한 것**:
|
|
- ca-tmpl 의 Spring Boot Micrometer Tracing 에서 `Sampler.parentBased(Sampler.traceIdRatioBased(0.01))` 구성 가능 여부 (SDK 별도 spec)
|
|
- force-sample boundary (error response / slow request / retry exhausted) 를 inbound 시점이 아닌 outbound boundary 에서 구현 가능한지 (root span sampled 결정이 child 에 상속되므로 inbound 시점 결정 불가능)
|
|
|
|
## 메모 / Notes (내 프로젝트 해석)
|
|
|
|
> 본 섹션은 자료 직접 인용 아님. ca-tmpl 결정 컨텍스트 해석.
|
|
|
|
- **ca-tmpl 현재 = head-based + force-sample boost**:
|
|
- 1% TraceIdRatioBased + error/slow request 에서 sampler decision override.
|
|
- Spring Boot 에서는 `Sampler.parentBased(Sampler.traceIdRatioBased(0.01))` + custom span processor 로 구현 가능 (SDK 별도 확인 필요, `OTEL-SAMP-C6`).
|
|
- **tail-based 대안**:
|
|
- 1% sample 대신 100% collect → collector 에서 error/slow trace 만 keep.
|
|
- 장점: error trace 100% 보존, 정상 trace 1% sample → 같은 storage 비용에 더 유용한 데이터.
|
|
- 단점: collector 메모리/네트워크 비용. trace 완료 대기 window 필요. multi-collector 환경에선 trace 일부 chunk 가 다른 collector 로 가면 decision 불완전 (별도 Collector contrib 문서 확인).
|
|
- **adaptive sampling 대안**:
|
|
- traffic 변화에 따라 sample rate 동적 조정.
|
|
- Honeycomb refinery, Datadog APM adaptive sampling 등 vendor 구현 존재.
|
|
- ca-tmpl 처럼 표준 SDK default 를 선호하면 채택하지 않음.
|
|
- **장점 (head-based + force-sample, ca-tmpl 채택)** — `OTEL-SAMP-C3` 의 4가지 advantage 가 spec 직접 지지.
|
|
- **단점**: `OTEL-SAMP-C4` 가 직접 지적 — force-sample 은 inbound 시점에는 error/slow 여부 모름 → root span sampled=false 면 child 도 sampled=false. 즉 force-sample 은 outbound retry 같은 특정 boundary 에서만 효과. error/slow trace 는 항상 잡히지 않을 수 있음.
|
|
- **ca-tmpl 과의 차이**: ca-tmpl decision 은 head-based + force-sample. tail-based 가 더 강력하지만 collector overhead 로 채택 안 함 (skeleton 단계).
|
|
|
|
## Related / 관련
|
|
|
|
- 같은 주제 다른 raw:
|
|
- [[raw/official-docs/tracing-b3-propagation-zipkin-spec]] (propagation format, 별도 spec)
|
|
- 인용하는 branch:
|
|
- [[raw/branch-notes/feature-distributed-tracing-contract]]
|
|
- 인용하는 project:
|
|
- [[raw/project-notes/ca-skeleton-operational-contract]] (§Distributed Tracing Contract — sampling 전략 대안 비교)
|
|
- 인용한 wiki 요약: (미작성)
|