Observability 101: Logs, Metrics, dan Distributed Tracing

Monitoring vs Observability

Monitoring menjawab pertanyaan yang sudah Anda tahu sebelumnya: "Apakah CPU di atas 80%?", "Apakah endpoint ini down?". Anda memasang dashboard dan alert untuk kondisi yang sudah diprediksi.

Observability menjawab pertanyaan yang belum tentu Anda tahu sebelumnya akan muncul: "Kenapa user spesifik ini mengalami error 500 jam 3 pagi tadi, padahal endpoint yang sama normal untuk user lain?" Ini butuh kemampuan menelusuri sistem secara mendalam tanpa harus sudah menyiapkan dashboard khusus untuk skenario itu sebelumnya.

Tiga pilar yang membentuk observability: Logs, Metrics, dan Traces.

Pilar 1: Structured Logging

Log tradisional berbentuk teks bebas (console.log("User login failed")) sulit di-query di skala besar. Structured logging menulis log sebagai JSON dengan field yang konsisten, sehingga bisa difilter dan diagregasi oleh tool seperti Datadog, Loki, atau ELK Stack.

// Alih-alih ini:
console.log(`User ${userId} login failed: ${error.message}`)

// Structured logging seperti ini:
logger.error({ userId, err: error.message, event: "login_failed" }, "Login attempt failed")

Satu teknik yang sangat berharga: correlation ID (atau request ID)—sebuah identifier unik yang di-generate di awal setiap request masuk, lalu disisipkan ke setiap baris log yang dihasilkan selama request itu diproses, termasuk saat memanggil service lain.

// Middleware yang menempelkan requestId ke setiap log dalam satu request
app.use((c, next) => {
  const requestId = crypto.randomUUID()
  const requestLogger = logger.child({ requestId })
  c.set("logger", requestLogger)
  return next()
})

Dengan pola ini, ketika seorang user melapor error, Anda tinggal mencari satu requestId dan langsung melihat seluruh jejak yang terjadi selama request itu—bukan menebak-nebak dari ribuan baris log yang tidak berkorelasi.

Pilar 2: Metrics

Metrics adalah angka teragregasi dari waktu ke waktu—jumlah request per detik, persentil latensi, tingkat error. Berbeda dari log (yang detail per-kejadian), metrics dirancang untuk murah disimpan dalam jumlah besar dan cepat divisualisasikan sebagai grafik.

Metode RED adalah kerangka sederhana untuk service yang menerima request (API, web server):

Untuk resource (database, message queue, cache), metode USE lebih relevan:

Pilar 3: Distributed Tracing

Ketika satu request melewati banyak service (API gateway -> auth service -> database -> cache -> third-party API), distributed tracing merekam perjalanan lengkap request itu sebagai satu trace, terdiri dari beberapa span—masing-masing merepresentasikan satu unit kerja (misalnya satu query database atau satu pemanggilan HTTP ke service lain).

Dari satu visualisasi seperti ini, terlihat jelas span mana yang menjadi bottleneck—tanpa harus menebak-nebak dari log yang terpisah-pisah di setiap service.

Standar industri saat ini adalah OpenTelemetry—spesifikasi vendor-neutral untuk instrumentasi tracing, metrics, dan log, yang bisa dikirim ke backend observability apa pun (Jaeger, Grafana Tempo, Datadog, dll) tanpa perlu mengganti kode instrumentasi setiap kali berganti vendor.

Kesimpulan

Tiga pilar ini saling melengkapi, bukan saling menggantikan: metrics memberi tahu Anda bahwa ada masalah (misalnya p99 latency naik drastis), traces menunjukkan di mana letak masalahnya dalam alur request, dan log memberi detail persis apa yang terjadi di titik itu. Sistem yang benar-benar observable membiarkan Anda berpindah lancar dari satu pilar ke pilar lain—dari grafik metrik yang mencurigakan, ke trace yang menunjukkan span lambat, ke log detail dengan correlation ID yang sama, untuk sampai ke akar masalah dalam hitungan menit, bukan jam.