Files

T

DongHyeonka d71669eb59 fix: 하네스 제거 및 keycloak 문서 보강

2026-07-25 12:53:13 +09:00

8.4 KiB

Raw Blame History

title, source_type, url, archive_url, status, confidence, tags, related_projects, related_branches, created, last_reviewed

title

source_type

url

archive_url

status

confidence

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 단계).

같은 주제 다른 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 요약: (미작성)

8.4 KiB Raw Blame History