Tracing: apa itu, prinsip dan pengumpulan data

Apa itu tracing dalam monitoring

Tracing adalah metode observasi terdistribusi di mana setiap permintaan yang masuk dilacak melalui semua layanan dan komponen sistem. Berbeda dengan metrik, yang menunjukkan nilai agregat (waktu respons rata-rata, jumlah kesalahan), tracing mempertahankan konteks lengkap dari satu permintaan tertentu.

Setiap langkah pemrosesan — panggilan basis data, permintaan HTTP ke mikrolayanan lain, eksekusi tugas latar belakang — dicatat sebagai unit terpisah dengan stempel waktu, status, dan atribut. Menurut data Google Dapper (publikasi asli tahun 2010), tracing memungkinkan lokalisasi keterlambatan dalam sistem terdistribusi dengan akurasi hingga satu panggilan.

Tracing sangat penting untuk aplikasi mobile, di mana backend terdiri dari puluhan mikrolayanan. Tindakan pengguna — misalnya, masuk ke akun — dapat melalui API Gateway, layanan autentikasi, basis data, dan layanan Push. Tanpa trace, hampir tidak mungkin untuk menentukan komponen mana yang memperlambat respons.

Span dan trace: struktur data dasar

Unit dasar tracing adalah span. Setiap span mewakili satu operasi logis: permintaan HTTP, kueri SQL, panggilan gRPC, serialisasi JSON. Span berisi pengidentifikasi unik, pengidentifikasi induk, nama operasi, waktu mulai, durasi, status, dan serangkaian atribut.

Hierarki span dalam trace

Semua span yang terkait dengan satu permintaan akar bergabung dalam trace. Span akar (root span) mewakili titik masuk — permintaan HTTP dari klien mobile ke API. Span anak membentuk pohon di mana setiap span merujuk ke induknya melalui bidang parent_span_id.

Durasi trace sama dengan jumlah durasi segmen waktu unik dari semua span. Jika dua span anak dijalankan secara paralel, waktu mereka tidak dijumlahkan — ini sangat penting untuk analisis yang benar atas keterlambatan yang disebabkan oleh panggilan paralel mikrolayanan.

Atribut dan peristiwa span

Setiap span dapat berisi atribut — pasangan kunci-nilai dengan meta-informasi: URL permintaan, ID pengguna, versi API, nama host. Atribut digunakan untuk memfilter dan mengelompokkan trace. Selain atribut, span mendukung peristiwa — stempel waktu dengan deskripsi teks, misalnya “cache miss” atau “percobaan koneksi ulang”.

Bagaimana cara kerja distributed tracing

Distributed tracing memecahkan masalah menghubungkan span yang dibuat dalam proses berbeda dan di mesin berbeda. Mekanismenya didasarkan pada transmisi konteks: saat memanggil layanan B dari layanan A, sebuah header dengan pengidentifikasi trace saat ini dan span induk ditambahkan ke permintaan keluar.

Protokol standar untuk transmisi konteks — W3C Trace Context (header traceparent dan tracestate) dan Zipkin B3 (header X-B3-TraceId, X-B3-SpanId). W3C Trace Context diadopsi sebagai standar oleh konsorsium W3C pada tahun 2021 dan didukung oleh semua penyedia telemetri utama.

Saat menerima permintaan, layanan B mengekstrak trace_id dari header dan membuat span anak dengan trace_id ini. Dengan demikian, setelah permintaan selesai, semua span dari berbagai layanan bergabung menjadi satu trace di sisi kolektor. Untuk ini, setiap layanan harus diinstrumentasi dengan pustaka tracing yang sama.

Transmisi konteks dalam mikrolayanan

Dalam pengembangan mobile, transmisi konteks mencakup tidak hanya backend, tetapi juga interaksi klien-server. Aplikasi mobile dapat mengirim trace_id di header setiap permintaan API, memungkinkan koneksi tindakan klien dengan pemrosesan server. OpenTelemetry SDK untuk iOS dan Android mendukung pembuatan dan transmisi konteks trace secara otomatis melalui klien HTTP.

import io.opentelemetry.api.trace.Span
import io.opentelemetry.api.trace.Tracer
import io.opentelemetry.context.Context

class TracingInterceptor : Interceptor {
    private val tracer: Tracer = OpenTelemetry.getTracer("mobile-app")

    override fun intercept(chain: Interceptor.Chain): Response {
        val span = tracer.spanBuilder("HTTP POST /api/login")
            .setParent(Context.current())
            .startSpan()

        return chain.proceed(chain.request())
            .also { span.end() }
    }
}

Interceptor yang disajikan di Kotlin membuat span untuk setiap permintaan HTTP ke server. Konteks induk ditransmisikan dari kode pemanggil melalui Context.current(), yang memungkinkan penautan trace sisi klien dengan trace sisi server.

Implementasi tracing melalui OpenTelemetry

OpenTelemetry — standar de facto untuk pengumpulan data trace. Ini menyediakan API terpadu untuk menghasilkan span, instrumentasi otomatis pustaka populer, dan mekanisme ekspor data yang fleksibel ke berbagai backend: Jaeger, Zipkin, Grafana Tempo, Datadog, New Relic.

Instrumentasi otomatis

OpenTelemetry mendukung pembuatan span otomatis untuk framework populer: Spring Boot, Ktor, Flask, Express, gRPC. Pengembang hanya perlu menambahkan ketergantungan ke proyek, dan pustaka secara mandiri mencegat permintaan masuk dan keluar. Auto-instrumentation untuk Java menggunakan javaagent, yang memodifikasi bytecode dengan cepat tanpa mengubah sumber.

Untuk platform mobile, OpenTelemetry menyediakan Swift SDK dan Kotlin SDK. Mereka secara otomatis membuat span untuk permintaan jaringan (URLSession, OkHttp), bekerja dengan basis data (CoreData, Room), dan tugas latar belakang. Pengembang dapat menambahkan span kustom untuk logika bisnis.

Ekspor data

Span yang terkumpul dikirim ke kolektor melalui protokol OTLP (OpenTelemetry Protocol). Kolektor dapat mem-buffer, memfilter, dan mengarahkan data ke satu atau beberapa sistem penyimpanan. Menurut dokumentasi OpenTelemetry, keterlambatan tipikal dari pembuatan span hingga tampilannya di dashboard adalah 2–5 detik saat menggunakan ekspor gRPC.

import OpenTelemetryApi
import OpenTelemetrySdk
import URLSessionInstrumentation

let instrumentation = URLSessionInstrumentation()
instrumentation.enable()

let tracer = OpenTelemetry.instance.tracerFactory
    .get("mobile-monitoring")

let span = tracer.spanBuilder("fetch-user-profile")
    .setAttribute(key: "user.id", value: userId)
    .startSpan()
span.end()

Kode di Swift mengaktifkan instrumentasi otomatis lapisan jaringan dan membuat span kustom untuk operasi pengambilan profil pengguna. Atribut user.id memungkinkan penyaringan trace nanti berdasarkan pengguna tertentu.

Strategi sampling trace

Dalam sistem dengan beban tinggi, tracing setiap permintaan tidak mungkin dilakukan — ini akan menciptakan beban yang tidak dapat diterima pada penyimpanan dan jaringan. Sampling memecahkan masalah ini dengan hanya menyimpan sebagian trace. Pemilihan strategi secara langsung memengaruhi kelengkapan data dan biaya infrastruktur.

Head-based sampling

Keputusan untuk menyimpan trace dibuat pada saat pembuatannya — di span akar. Pendekatan paling sederhana dan paling umum: persentase tetap permintaan (misalnya, 5%) disimpan, sisanya dibuang. Kekurangannya — tidak dapat dijamin bahwa kesalahan langka akan ditangkap. Probability sampler di OpenTelemetry mendukung pengaturan probabilitas dari 0.0 hingga 1.0.

Tail-based sampling

Keputusan ditunda sampai semua span trace selesai. Analisator mengevaluasi apakah trace berisi kesalahan, pelampauan waktu, atau atribut menarik, dan baru kemudian menyimpannya. Pendekatan ini memerlukan buffering semua span di kolektor, yang meningkatkan konsumsi memori. Menurut data Grafana Labs, tail-based sampling 40–60% lebih efisien dalam hal rasio “harga untuk data yang berguna” di sistem dengan kesalahan langka namun kritis.

Perbedaan antara tracing dan logging

Logging mencatat peristiwa terpisah dengan tingkat kepentingan (info, warn, error), tetapi tidak menghubungkannya dalam konteks satu permintaan. Tracing, sebaliknya, menciptakan pohon operasi terstruktur yang termasuk dalam satu permintaan ujung-ke-ujung. Dalam praktiknya, kedua pendekatan ini tidak saling eksklusif, melainkan saling melengkapi.

Log efektif untuk analisis terperinci dari kesalahan tertentu: pengembang melihat pesan yang tepat, stack trace, nilai variabel. Tracing menjawab pertanyaan “mengapa permintaan membutuhkan waktu 5 detik” — menunjukkan mikrolayanan atau panggilan mana yang menghabiskan waktu paling banyak. Menurut data Honeycomb (2024), tim yang menggunakan tracing bersama dengan logging menemukan akar penyebab insiden 2,3 kali lebih cepat.

Pendekatan modern — observability — menggabungkan trace, metrik, dan log ke dalam satu sistem. OpenTelemetry mendukung korelasi antara ketiga sinyal ini: setiap span dapat berisi referensi ke log terkait, dan metrik dapat ditandai dengan trace_id untuk navigasi ke trace tertentu.