Menyelami Distributed Tracing: Melacak Jejak Request di Balik Keruwetan Microservices

Waktu backend kalian masih monolit sederhana, urusan debugging terasa damai banget. Ada request lambat? Tinggal intip log server. Atau pasang profiler lokal. Semuanya jalan di satu proses, satu memori, dan satu log file yang teratur.

Begitu arsitektur dipecah jadi belasan microservice, kondisinya berubah drastis, lho. Ada Auth Service. Ada Order Service. Ada Payment Gateway. Sampai Notification Service dan Inventory Service. Satu klik tombol "Checkout" bisa memicu puluhan network call asinkron antar-service.

Nah, pas pengguna ngeluh checkout-nya makan 8 detik lalu timeout 500, gimana kita tahu service mana yang bikin lambat? Query database di Inventory Service-nya? Atau ada antrean di payment worker? 🤔

Di sinilah Distributed Tracing hadir jadi penyelamat.

Kenapa Centralized Logging Aja Nggak Cukup?

Banyak developer ngira cukup pasang centralized log aggregator. Kayak Elasticsearch, Loki, atau Datadog. Padahal itu belum cukup buat beresin masalah di microservices.

Saat ratusan ribu request masuk per detik, log dari berbagai service bercampur jadi lautan teks raksasa. Nyari keterkaitan antara log di Service A sama log di Service D jadi mimpi buruk. Soalnya nggak ada benang merah yang ngikatnya.

Centralized logging ngasih tahu kita apa yang terjadi di dalam satu service. Distributed tracing ngasih tahu kita gimana request mengalir melintasi seluruh ekosistem. Itu dua hal yang beda banget.

Anatomi Distributed Tracing: Trace vs Span

Buat paham distributed tracing, ada dua konsep fundamental yang wajib kita kuasai.

Trace itu seluruh perjalanan sebuah transaksi atau request, dari awal sampai akhir. Bayangin trace kayak satu tiket perjalanan penumpang. Dari stasiun keberangkatan sampai tiba di tujuan akhir. Tiap trace punya ID unik global namanya Trace ID.

Span adalah segmen atau unit kerja tunggal di dalam sebuah trace, nih. Satu trace terdiri dari satu atau banyak span. Semuanya membentuk struktur pohon (directed acyclic graph). Tiap span nyatet:

• Nama operasi (misalnya POST /orders, SELECT * FROM users, atau Publish to RabbitMQ)
• Waktu mulai dan durasi eksekusi
• Metadata tambahan berupa tags/attributes (misalnya http.status_code: 200, db.system: postgresql, user.id: 1042)
• Log peristiwa (events/logs) plus status error

Dengan visualisasi span, kita bisa lihat service mana yang paling lama. Itulah si critical path. Kita juga langsung tahu di titik mana error pertama meledak.

Cara Kerja Context Propagation

Pertanyaan terbesarnya: gimana Service B tahu request yang dia terima itu kelanjutan dari Service A?

Jawabannya context propagation. Pas Service A manggil Service B lewat HTTP, Service A nyisipin Trace ID dan Parent Span ID ke dalam header request. Begitu juga kalau lewat message queue.

Standar industri modern yang paling banyak dipakai sekarang adalah W3C Trace Context. Header yang dikirim bentuknya traceparent:

traceparent: 00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01

Header ini terdiri dari 4 bagian:

1. version: versi spesifikasi W3C (saat ini 00).
2. trace-id: ID unik 16-byte buat keseluruhan trace (4bf92f3577b34da6a3ce929d0e0e4736).
3. parent-id / span-id: ID unik 8-byte buat span pemanggil (00f067aa0ba902b7).
4. trace-flags: opsi flag. Nilai 01 nandain span ini direkam atau sampled.

Begitu Service B nerima request, library tracing-nya baca header itu. Dia ngekstrak Trace ID, lalu bikin child span baru di bawah Parent ID yang sesuai. Rantainya pun nyambung terus.

Implementasi Modern dengan OpenTelemetry

Dulu kita mungkin bingung milih. Ada OpenTracing, OpenCensus, Jaeger client, sampai Zipkin client. Untungnya industri udah sepakat pada satu standar terbuka. Namanya OpenTelemetry (OTel). Proyek open source ini di bawah naungan Cloud Native Computing Foundation (CNCF).

OpenTelemetry nyediain SDK buat berbagai bahasa. Ada Python, Go, Node.js, dan Java. Ada juga Collector terpusat buat memproses dan neruskan data telemetry. Data itu lalu dikirim ke backend visualisasi kayak Jaeger, Grafana Tempo, atau Datadog.

Contoh sederhana instrumentasi otomatis di FastAPI pakai Python:

from fastapi import FastAPI
from opentelemetry import trace
from opentelemetry.instrumentation.fastapi import FastAPIInstrumentor
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import BatchSpanProcessor
from opentelemetry.exporter.otlp.proto.grpc.trace_exporter import OTLPSpanExporter

# 1. Setup Provider & Exporter ke OpenTelemetry Collector / Jaeger
provider = TracerProvider()
processor = BatchSpanProcessor(OTLPSpanExporter(endpoint="localhost:4317", insecure=True))
provider.add_span_processor(processor)
trace.set_tracer_provider(provider)

# 2. Inisialisasi FastAPI
app = FastAPI(title="Order Service")

# 3. Instrumentasi otomatis FastAPI
FastAPIInstrumentor.instrument_app(app)

@app.get("/checkout")
async def checkout():
    tracer = trace.get_tracer(__name__)
    with tracer.start_as_current_span("process_payment_logic") as span:
        span.set_attribute("payment.method", "credit_card")
        # Logika pemrosesan pembayaran...
        return {"status": "success", "message": "Order processed"}

Dengan beberapa baris konfigurasi aja, setiap request HTTP ke endpoint /checkout bakal otomatis ngasilin span. Status code ke-capture, latensi kehitung, dan context-nya diteruskan ke downstream service. Nggak perlu ngoprek satu-satu, deh. 😎

Kapan Sistem Kalian Beneran Butuh Ini?

Kalau backend kalian masih monolit dan semua jalan di satu proses, tracing bisa jadi kelebihan beban. Tapi begitu jumlah service independen lewat dari dua, mulailah butuh. Apalagi kalau ada banyak background worker asinkron.

Bangun microservices tanpa distributed tracing itu kayak nyetir di jalan tol berkabut tebal tanpa lampu depan. Kita tahu mobilnya bergerak. Tapi kita nggak tahu kapan bakal nabrak lubang. 😅

Mulai aja dari instrumentasi HTTP gateway dulu. Sambungin ke Jaeger lokal lewat Docker. Nikmatin gimana akar masalah performa ketemu cuma dalam hitungan detik.

Selamat ber-observability ria, dan semoga trace kalian selalu nyambung dari ujung ke ujung! 👋