Belajar OpenTelemetry - Sampling: Head vs Tail

#Pendahuluan

Semakin besar traffic, semakin terasa pertanyaan besar observability: "apakah setiap request perlu disimpan?" Mengirim 100% telemetry dari 50.000 rps ke backend bukan sekadar mahal — itu sering kali mustahil dan tidak berguna, karena sebagian besar request adalah duplikasi pola yang sama. Jawabannya adalah sampling: memilih sebagian trace untuk disimpan.

Episode 13 membedah dua pendekatan sampling yang saling melengkapi: head sampling di SDK (keputusan cepat di awal) dan tail sampling di collector (keputusan bijak setelah trace lengkap). Memahami kapan memakai yang mana adalah keterampilan SRE yang membedakan observability hemat dari observability mahal.

#Head Sampling: Keputusan di SDK

Head sampling menentukan sampel saat trace dimulai — di dalam SDK aplikasi, sebelum data dikirim. Karena keputusannya dibuat di root span, seluruh child span mewarisi keputusan yang sama melalui flag sampled di traceparent (bit flags episode 4).

#Ratio Sampler

Sampel acak dengan persentase tetap — contoh paling sederhana:

from opentelemetry.sdk.trace.sampling import TraceIdRatioBased
from opentelemetry.sdk.trace import TracerProvider
 
provider = TracerProvider(sampler=TraceIdRatioBased(0.1))

#ParentBased Sampler

Sampler yang menghormati keputusan parent: jika trace datang dari service lain dengan flag sampled, ikuti; jika mulai baru, gunakan aturan lokal:

from opentelemetry.sdk.trace.sampling import ParentBased, TraceIdRatioBased
 
provider = TracerProvider(
    sampler=ParentBased(root=TraceIdRatioBased(0.25))
)

Ini wajib untuk konsistensi: tanpa parent-based, dua service bisa mengambil keputusan berbeda untuk satu trace — separuh tersimpan, separuh hilang.

#Kelebihan & Kekurangan Head Sampling

• Kelebihan: murah, tanpa infrastruktur tambahan, keputusan lokal per aplikasi, tidak menunda data.
• Kekurangan: keputusan dibuat buta. Error jarang terjadi? Hampir pasti tidak ke-sample — padahal error justru yang paling penting untuk disimpan.

#Tail Sampling: Keputusan di Collector

Tail sampling menahan trace di collector sampai seluruh span-nya lengkap, lalu memutuskan secara utuh berdasarkan kebijakan. Karena melihat trace penuh, ia bisa menyimpan justru yang penting: error, trace lambat, trace dari pelanggan tertentu.

processors:
  tail_sampling:
    decision_wait: 10s          # tunggu trace hingga 10 detik
    num_traces: 10000           # buffer maksimum
    expected_new_traces_per_sec: 500
    policies:
      - name: keep-errors
        type: status_code
        status_code: {status_codes: [ERROR]}
      - name: keep-slow
        type: latency
        latency: {threshold_ms: 1000}
      - name: keep-random
        type: probabilistic
        probabilistic: {sampling_percentage: 10}

• decision_wait — berapa lama collector menahan trace sebelum memutuskan (mengorbankan sedikit latensi ekspor).
• Policy status_code — simpan semua trace yang berisi span berstatus ERROR.
• Policy latency — simpan trace lebih lambat dari 1 detik.
• Policy probabilistic — sampel acak sisanya.

Hasilnya: 100% error dan request lambat tersimpan, request normal hanya 10% — biaya turun drastis tanpa kehilangan informasi penting.

#Membandingkan Head vs Tail

#Strategi Hemat-Biaya: 100% Head + Tail Cerdas

Pola produksi yang direkomendasikan menggabungkan keduanya:

1. SDK mengirim 100% — seluruh trace dikirim ke collector (head sampling ratio 100%). Ini murah di sisi aplikasi karena tidak ada yang dibuang.
2. Collector agent melakukan batch + filter — buang yang jelas tidak berguna (healthcheck) di node.
3. Gateway tail-sampling — simpan semua error + lambat, sampel acak sisanya.

Kelebihan pola ini: tidak pernah kehilangan error, biaya backend terkendali, dan aplikasi tidak perlu tahu strategi sampling — semua kebijakan hidup di collector.

#Kasus Khusus: Tidak Perlu Sample Semua?

Ada pertimbangan yang sering terlewat: apakah backend kalian bisa menampung 100% traces? Untuk traffic rendah (beberapa ratus rps) dan backend internal, sampling mungkin tidak perlu sama sekali — simpan semuanya. Sampling baru wajib saat volume mulai menggerus biaya atau menurunkan query performance. Jangan menambahkan kompleksitas sampling sebelum dibutuhkan data nyata.

#Common Pitfalls

• Head sampling tanpa parent-based — trace terbelah: sebagian di-sample, sebagian di-drop antar service.
• Tail sampling di agent per-node — memory kecil, trace ter-dump sebelum keputusan.
• decision_wait terlalu kecil — trace lambat belum lengkap saat diputuskan, error tersembunyi.
• Sampling 100% tanpa pengukuran — terapkan sampling berbasis data volume, bukan firasat.

#Penutup

Pada episode 13 ini, kalian telah menguasai dua paradigma sampling OTel.

Inti yang harus dibawa pulang:

• Head sampling (SDK): keputusan cepat di awal — parent-based wajib agar konsisten.
• Tail sampling (collector): keputusan bijak setelah trace lengkap — simpan semua error & lambat.
• Strategi hemat: SDK 100% → agent batch → gateway tail sampling.
• Sampling adalah keputusan biaya; terapkan saat volume benar-benar menuntut, dan tempatkan tail sampling di gateway.

Di episode 14 selanjutnya, kita akan membahas buffering, backpressure & retry — queue exporter dan sending_queue di collector, sinyal backpressure (429/ResourceExhausted), konfigurasi retry/backoff, dan cara mencegah data loss saat backend down. Sampai jumpa di episode 14!