Trace verisi büyüdükçe ekipler iki uç arasında sıkışır: her span’i saklamak pahalıdır, ama fazla agresif örnekleme incident anında körlük yaratır. Head sampling bu sorunu erken ve ucuz biçimde azaltır; fakat karar daha isteğin sonucu bilinmeden verildiği için kritik hata zincirlerini kaçırabilir. Tail sampling ise isteğin tamamı görüldükten sonra karar verdiği için özellikle kurumsal sistemlerde çok daha anlamlıdır. Bedeli ise daha dikkatli kuyruk ve bellek tasarımıdır.
Tail sampling ne zaman gerekli olur?
Şu sinyaller varsa genelde zamanı gelmiştir:
- İstek hacmi yüksek ama anlamlı hata oranı düşüktür
- Health check ve düşük değerli trafik trace depolamasını şişirir
- Incident sonrası “tam o isteğin trace’i yok” cümlesi sık duyulur
- Maliyet düşürme baskısı instrumentation kalitesini tehdit etmeye başlar
Bu durumda amaç tüm veriyi kesmek değil, yüksek tanısal değeri koruyan seçici bir akış kurmaktır.
Temel tasarım prensibi nedir?
Ben tail sampling için üç katman öneriyorum:
- Hata veya yüksek gecikme içeren trace’leri öncelikli tut
- Kritik servisler için minimum örnekleme tabanı bırak
- Başarılı ve düşük etkili trafiği düşük oranda örnekle
Bu model, yalnızca teknik maliyet değil operasyon önceliği üzerinden de okunabilir. Önemli olan sampling kuralını backend fiyatına göre değil, hangi soruları cevaplamak istediğinize göre kurmaktır.
Örnek Collector akışı
Aşağıdaki örnek, tail sampling’i bellek güvenliği ve temel sınıflandırma ile birlikte başlatmak için sade bir çerçeve verir:
receivers:
otlp:
protocols:
grpc:
http:
processors:
memory_limiter:
check_interval: 1s
limit_mib: 512
spike_limit_mib: 128
batch:
timeout: 5s
send_batch_size: 1024
tail_sampling:
decision_wait: 15s
num_traces: 50000
expected_new_traces_per_sec: 1500
policies:
- name: keep-errors
type: status_code
status_code:
status_codes: [ERROR]
- name: keep-slow-checkout
type: latency
latency:
threshold_ms: 1500
- name: keep-critical-services
type: string_attribute
string_attribute:
key: service.name
values: [erp-api, payment-gateway, identity-broker]
- name: sample-background
type: probabilistic
probabilistic:
sampling_percentage: 8
exporters:
otlphttp:
endpoint: https://traces.internal/v1/traces
service:
pipelines:
traces:
receivers: [otlp]
processors: [memory_limiter, tail_sampling, batch]
exporters: [otlphttp]Bu örnekte decision_wait ve num_traces değerleri kritik parametrelerdir. Çok düşük ayar, geç biten trace’leri eksik toplar; çok yüksek ayar ise collector belleğini gereksiz büyütür.
Politika sırası neden önemli?
Tail sampling yalnızca “yüzde kaç kalsın” problemi değildir. Politika mantığını şu sırayla düşünmek daha sağlıklı olur:
- Önce kesin tutulacak sınıflar
- Sonra iş açısından kritik ama teknik olarak başarılı istekler
- En sonda arka plan ve düşük değerli trafik
Böylece düşük oranlı genel örnekleme, kritik hata trace’lerini gölgede bırakmaz.
Operasyon tarafında hangi metrikler izlenmeli?
En az şu alanları dashboard’a bağlamak gerekir:
- Collector bellek tüketimi
- Sampling sonrası trace kabul oranı
- Politika bazında tutulan trace sayısı
- Karar bekleme süresi ve düşen trace miktarı
Bu metrikler olmadan tail sampling çoğu ekipte “maliyet düştü sanıyoruz” şeklinde kör uygulanır. Oysa yanlış ayarlı akış, sessiz veri kaybı üretir.
Yaygın hata nedir?
Tek collector havuzunda tüm servisleri aynı policy setiyle yönetmek. ERP, kimlik ve batch iş akışları aynı tanısal değere sahip değildir. İdeal durumda en azından servis sınıfına göre ayrı policy kümeleri ya da ayrı collector havuzları düşünülmelidir.
Sonuç
OpenTelemetry Collector’da tail sampling tasarımı, trace hacmini azaltma hilesi değil gözlemlenebilirlik önceliklerini kodlama işidir. Hata, gecikme ve kritik servis trafiği korunurken düşük değerli akışlar kontrollü azaltıldığında hem maliyet hem de tanı kalitesi birlikte iyileşir. Güçlü sonuç almak için sampling oranından önce karar bekleme süresi, bellek sınırı ve politika görünürlüğü doğru kurulmalıdır.