Belajar Observability dengan LGTM Stack - Distributed Tracing dengan Tempo - Introduction

#Pendahuluan

Pillar ketiga observability adalah traces — peta perjalanan sebuah request melintasi banyak service. Tanpa traces, menemukan service mana yang memperlambat request adalah tebakan murni. Grafana Tempo adalah backend yang menyimpan dan mengquery data trace tersebut.

Tempo dirancang dengan filosofi yang sama seperti Loki: murah, scalable, dan berbasis object storage. Episode ini membahas arsitektur Tempo, konsep tracing yang mendasar, sampling strategy, serta perbandingan Tempo dengan Jaeger.

#Grafana Tempo Overview

#Desain dan Keunggulan

• Scalable distributed tracing backend: setiap komponen bisa diskalakan horizontal.
• Object storage based: trace disimpan di S3, GCS, atau Azure Blob — bukan di disk lokal.
• Native OTLP support: Tempo menerima trace langsung dalam protokol OTLP, tanpa adapter.
• Cost-effective trace storage: tanpa index penuh, biaya jauh lebih rendah dari Jaeger.
• TraceQL query language: bahasa query khusus untuk mencari trace berdasarkan atribut span — dibahas di episode 15.

curl -s http://localhost:3200/ready

Output ready dari curl -s http://localhost:3200/ready berarti Tempo siap menerima trace — kebiasaan yang sudah kalian pakai sejak episode 4.

#Tempo Architecture

Seperti saudaranya Mimir dan Loki, Tempo memecah alur trace menjadi komponen:

• Distributor: menerima trace dari collector, memvalidasi, dan mengirim ke ingester.
• Ingester: menyimpan trace terbaru dalam memori dan menulis blok ke object storage.
• Querier: menjawab query berdasarkan TraceID atau query TraceQL.
• Query-frontend: mengatur antrean dan pembagian query besar.
• Compactor: menggabungkan blok kecil menjadi blok lebih besar.
• Metrics-generator (opsional): menghasilkan metrik RED dari trace — dibahas di episode 24.

otlp -> distributor -> ingester -> object storage
query -> query-frontend -> querier <- blok

Alur otlp -> distributor -> ingester -> object storage adalah jalur penyimpanan utama. Metrics-generator membaca trace yang sama untuk menurunkan metrik.

#Tracing Concepts Deep Dive

#Span dan Trace

• Trace: perjalanan utuh sebuah request, diidentifikasi oleh TraceID.
• Span: satu unit kerja dalam trace, seperti "query database" atau "call HTTP", dengan durasi dan atribut.
• Span context: metadata identitas span yang diteruskan antar service.

span:
  name: call.payment
  trace_id: 4bf92f3577b34da6
  span_id: 00f067aa0ba902b7
  parent_span_id: 1d2e3f4a5b6c7d8e
  duration_ms: 145
  attributes:
    http.status_code: 500

Field parent_span_id inilah yang membentuk relasi parent-child antar span dalam satu trace.

#Context Propagation

Trace hanya terbentuk bila context diteruskan antar service. Standar yang dipakai adalah W3C Trace Context melalui header traceparent — kalian akan mempraktikkannya langsung di episode 14.

#Sampling Strategy

Menyimpan semua trace tidak realistis pada trafik tinggi. Ada dua pendekatan utama:

• Head-based sampling: memutuskan sampel saat trace dimulai, konsisten untuk seluruh trace.
• Tail-based sampling: memutuskan setelah trace selesai, memungkinkan aturan yang lebih cerdas.

sampler:
  type: traceidratio
  ratio: 0.1

Nilai ratio: 0.1 berarti 10 persen trace disimpan. Konsep sampling yang lebih lengkap ada di episode 24.

#Tempo vs Jaeger

#Perbandingan Arsitektur

• Arsitektur: Tempo mengadopsi pola komponen ala Mimir; Jaeger menggunakan arsitektur gRPC dan Cassandra/Elasticsearch.
• Penyimpanan: Tempo menyimpan blok trace di object storage tanpa index isi; Jaeger mengandalkan database eksternal dengan index.
• Query: Tempo punya TraceQL untuk query berbasis atribut; Jaeger mencari berdasar service, operation, dan tag.
• Skalabilitas: keduanya scalable, tapi biaya operasional Tempo lebih rendah karena object storage.

tempo: object storage + TraceQL, murah, terintegrasi Grafana
jaeger: database eksternal, matang, ekosistem luas

Pola tempo: object storage + TraceQL menjadi pilihan di series ini karena integrasi native dengan Grafana dan biaya penyimpanan.

#Penutup

Di episode 13 ini kalian memahami Tempo sebagai backend trace berbasis object storage dengan dukungan OTLP native, mengenal komponen arsitekturnya dari distributor hingga metrics-generator, memahami konsep span, trace, context propagation, dan sampling, serta perbandingan Tempo dengan Jaeger.

Inti yang harus dibawa pulang:

• Tempo menyimpan trace di object storage, bukan disk lokal.
• Trace dibangun dari span dengan relasi parent-child.
• OTLP adalah protokol masuk utama Tempo.
• Sampling menekan volume dan biaya trace.
• Tempo menang dengan biaya dan integrasi Grafana.

Di episode 14 selanjutnya kita akan membahas OpenTelemetry instrumentation untuk traces — auto-instrumentation per bahasa, pembuatan span manual, context propagation W3C, serta best practices penamaan span dan atribut. Waktunya membuat aplikasi kalian menghasilkan trace sungguhan.