샘플링 전략: 원격 측정 볼륨 및 비용 감소
수백 개의 마이크로서비스와 초당 수천 개의 요청이 있는 분산 시스템에서는 수집하다 모든 것이 괜찮습니다 추적하고 엄청나게 비쌉니다. 그만큼 견본 추출 (샘플링) 및 대표 하위 집합을 선택할 수 있는 기술 추적을 통해 용량 손실 없이 데이터 볼륨 및 스토리지 비용 절감 문제를 진단합니다.
샘플링하고 올바른 균형을 찾는 문제: 샘플링이 너무 적으면 가시성; 샘플링을 너무 많이 하면 비용이 증가합니다. 고급 샘플링 전략 유지할 수 있도록 해주세요 오류가 있는 모든 트랙 느린 요청, "정상" 및 반복적인 트래픽만 삭제합니다.
이 기사에서 배울 내용
- 헤드 기반 샘플링: 트랙 시작 시 결정
- 테일 기반 샘플링: 추적 종료 시 결정
- 확률적 샘플링 및 속도 제한
- Collector에서 샘플링 구성
- 비용 최적화 전략
- 정확성과 비용 간의 균형
헤드 기반 샘플링
Il 헤드 기반 샘플링 트랙을 샘플링하기로 결정
처음에는, 첫 번째 범위(루트 범위)에서. 그런 다음 결정이 전파됩니다.
플래그를 통해 모든 다운스트림 서비스에 sampled 에서 traceparent
헤더. 루트 스팬이 샘플링하지 않기로 결정하면 체인의 어떤 서비스도 기록하지 않습니다.
해당 트랙의 범위입니다.
가장 큰 장점은 간단 그리고능률: 트랙이 완료될 때까지 기다리지 않고 즉시 결정이 내려집니다. 단점은 결정 당시 요청 결과를 알 수 없다는 것입니다. 오류가 있는 트랙은 폐기될 수 있습니다.
from opentelemetry import trace
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.sampling import (
TraceIdRatioBased,
ParentBasedTraceIdRatio,
ALWAYS_ON,
ALWAYS_OFF,
)
# --- 1. Probability Sampler (25% delle tracce) ---
# Ogni traccia ha il 25% di probabilità di essere campionata
sampler_25 = TraceIdRatioBased(0.25)
# --- 2. ParentBased Sampler (rispetta la decisione del parent) ---
# Se il parent e campionato, il figlio e campionato
# Se non c'è parent, usa il ratio specificato
sampler_parent = ParentBasedTraceIdRatio(0.25)
# --- 3. Configurazione nel TracerProvider ---
provider = TracerProvider(
sampler=ParentBasedTraceIdRatio(0.25)
)
trace.set_tracer_provider(provider)
# --- 4. Configurazione via variabili d'ambiente ---
# OTEL_TRACES_SAMPLER=parentbased_traceidratio
# OTEL_TRACES_SAMPLER_ARG=0.25
헤드 기반 샘플러의 유형
| 샘플러 | 행동 | 일반적인 사용 |
|---|---|---|
| AlwaysOn | 모든 트랙 샘플링(100%) | 개발, 테스트, 트래픽이 적은 서비스 |
| 항상 꺼짐 | 샘플링하지 않음(0%) | 일시적으로 추적 비활성화 |
| TraceIdRatioBased | 고정된 비율 샘플링 | 볼륨을 줄이는 간단한 접근 방식 |
| 상위 기반 | 부모의 결정을 존중한다 | 서비스 전반에 걸쳐 일관성 보장 |
테일 기반 샘플링
Il 꼬리 기반 샘플링 트랙을 샘플링하기로 결정 후에 모든 범위가 수집되어 전체 추적을 분석합니다. 이를 통해 요청 결과에 따라 지능적인 결정을 내릴 수 있습니다. 오류가 있는 모든 추적, 느린 요청, 비정상적인 추적, 반복적이고 성공적인 트래픽.
테일 기반 샘플링에는 중앙 집중식 구성 요소(일반적으로 모든 추적 범위를 수집하고 조합하여 정책을 평가하는 게이트웨이 모드) 샘플링하여 전체 트랙을 유지할지, 삭제할지 결정합니다.
# Configurazione tail_sampling nel Collector Gateway
processors:
tail_sampling:
# Tempo massimo per attendere tutti gli span di una traccia
decision_wait: 30s
# Numero massimo di tracce in attesa di decisione
num_traces: 100000
# Numero atteso di nuove tracce al secondo
expected_new_traces_per_sec: 1000
policies:
# Policy 1: mantenere TUTTE le tracce con errori
- name: errors-policy
type: status_code
status_code:
status_codes:
- ERROR
# Policy 2: mantenere le tracce lente (latenza > 2s)
- name: latency-policy
type: latency
latency:
threshold_ms: 2000
# Policy 3: mantenere tracce con attributi specifici
- name: vip-customers
type: string_attribute
string_attribute:
key: customer.tier
values:
- premium
- enterprise
# Policy 4: campionamento probabilistico per il resto
- name: probabilistic-policy
type: probabilistic
probabilistic:
sampling_percentage: 10
# Policy 5: rate limiting globale
- name: rate-limiting
type: rate_limiting
rate_limiting:
spans_per_second: 500
# Policy 6: policy composita (AND/OR)
- name: composite-policy
type: composite
composite:
max_total_spans_per_second: 1000
policy_order: [errors-policy, latency-policy, probabilistic-policy]
rate_allocation:
- policy: errors-policy
percent: 50
- policy: latency-policy
percent: 30
- policy: probabilistic-policy
percent: 20
머리와 꼬리 샘플링 비교
헤드 기반 샘플링과 테일 기반 샘플링
| 나는 기다린다 | 헤드 기반 | 테일 기반 |
|---|---|---|
| 결정의 순간 | 트랙의 시작 | 트랙의 끝 |
| 결과에 대한 지식 | No | 예(오류, 대기 시간, 속성) |
| 필요한 자원 | 최소(분산) | 중요(중앙 집중식) |
| 일관성 | 항상 일관성 | 분리된 범위의 위험 |
| 복잡성 | 낮은 | 높음(전용 인프라) |
| 발견된 오류 | 무작위로 샘플링된 경우에만 | 모두(전용정책) |
비용 최적화 전략
관찰 가능성 비용은 원격 분석 볼륨에 따라 증가합니다. 최적화 전략 그들은 세 가지 수단, 즉 트랙의 볼륨을 줄이고, 속성의 수를 줄이는 데 중점을 둡니다. 백엔드에서 보존 범위를 확장하고 최적화합니다.
# Strategia di ottimizzazione multi-livello
# 1. Filtrare il rumore nel Collector
processors:
filter:
traces:
span:
# Eliminare health check e readiness probe
- 'attributes["http.route"] == "/health"'
- 'attributes["http.route"] == "/ready"'
- 'attributes["http.route"] == "/metrics"'
# Eliminare richieste di asset statici
- 'attributes["http.route"] =~ "/static/.*"'
# 2. Rimuovere attributi ad alta cardinalita
attributes:
actions:
# Rimuovere header sensibili
- key: http.request.header.authorization
action: delete
- key: http.request.header.cookie
action: delete
# Troncare query SQL lunghe
- key: db.query.text
action: hash
# 3. Tail sampling intelligente
tail_sampling:
policies:
- name: keep-errors
type: status_code
status_code:
status_codes: [ERROR]
- name: keep-slow
type: latency
latency:
threshold_ms: 1000
- name: sample-rest
type: probabilistic
probabilistic:
sampling_percentage: 5
# 4. Batch per efficienza
batch:
send_batch_size: 2048
timeout: 10s
비용 최적화 체크리스트
- 소음을 필터링하세요.: 백엔드 이전에 상태 확인, 준비 상태 프로브 및 정적 자산을 제거합니다.
- 카디널리티 확인: 측정항목 라벨을 제한된 값으로 제한합니다(측정항목당 최대 5~7개의 라벨).
- 오류에 대한 테일 샘플링: 오류가 있는 트랙을 100% 유지하고 나머지는 샘플링합니다.
- 차별화된 보존: 집계 지표의 장기 보존(90일), 원시 추적의 단축(7~14일)
- 압축: Collector에서 gzip/zstd를 활성화하여 네트워크 트래픽을 줄입니다.
- 다운샘플링 측정항목: 기록 측정항목의 해상도를 줄입니다(7일 후 15초에서 5분으로).
적응형 샘플링
L'적응 샘플링 그에 따라 샘플링 속도를 자동으로 조정합니다. 현재 교통량에 맞춰 트래픽이 적으면 더 큰 비율로 샘플링하세요. 트래픽이 높으면 예산 내에서 볼륨을 유지하기 위해 속도를 줄입니다.
수집기 테일 샘플링의 속도 제한은 적응형 샘플링의 간단한 형태입니다.
spans_per_second: 500 관계없이 일정한 최대 볼륨을 보장합니다.
교통에서. 보다 정교한 전략을 위해서는 맞춤형 솔루션이나 SaaS 서비스가 필요합니다
플랫폼 수준에서 적응형 샘플링을 구현합니다.
결론 및 다음 단계
샘플링은 대규모 관찰 가능성을 관리하기 위한 기본 기술입니다. 선택 전략은 트래픽 양, 예산, 가시성 수준에 따라 달라집니다. 필수. 권장되는 접근 방식은 결합하는 것입니다. 헤드 기반 샘플링 에 대한 기본 볼륨 감소 꼬리 기반 샘플링 그것을 보장하기 위해 오류와 이상 현상은 항상 캡처됩니다.
황금률은 다음과 같습니다. 샘플 트랙, 측정항목 없음. 측정항목 집계 트래픽과 관계없이 고정 비용이 들고 높은 수준의 가시성을 제공합니다. 경고에 필요합니다. 추적은 비용이 많이 들지만 자세한 디버깅에만 필요합니다.
다음 기사에서는AI 관찰 가능성, 추적 방법 분석 대규모 언어 모델 호출, 토큰 사용 모니터링, 대기 시간 추론과 AI 에이전트의 행동.