Belajar Observability dengan LGTM Stack - Three Pillars of Observability - Konsep & Filosofi

#Pendahuluan

Seluruh stack yang akan kalian bangun di series ini melayani tiga jenis data telemetry yang dikenal sebagai three pillars of observability: metrics, logs, dan traces. Masing-masing menjawab pertanyaan yang berbeda, dan tidak ada satu pun yang bisa menggantikan yang lain.

Episode ini membedah filosofi dan konsep di balik setiap pillar, mulai dari tipe-tipe metrik, struktur log, sampai anatomy trace. Kalian juga akan belajar bagaimana ketiganya saling berkorelasi — inilah yang membedakan observability sejati dari sekadar kumpulan tool. Pahami episode ini baik-baik, karena semua istilah di sini akan dipakai berulang kali.

#Metrics — Apa yang Sedang Terjadi

#Tipe-Tipe Metrik

Metrics adalah data numerik yang diambil secara berkala, disimpan sebagai deret waktu (time-series). Setiap deret direpresentasikan oleh nama metrik dan pasangan key-value label, misalnya http_requests_total{method="GET", status="200"}. Tiga tipe utama yang wajib kalian kenali:

• Counter: nilai naik secara monoton, untuk menghitung kejadian, contohnya jumlah request.
• Gauge: nilai bisa naik dan turun, contohnya jumlah koneksi aktif atau penggunaan CPU.
• Histogram dan Summary: distribusi pengamatan, misalnya latency request, untuk menghitung persentil.

Metrik dikumpulkan dan diagregasi, tapi kalian harus waspada pada cardinality — kombinasi label yang terlalu banyak akan menggandakan jumlah deret dan membebani storage. Prinsip ini penting saat nanti mendesain label di episode 6.

#Metode USE dan RED

Dua kerangka kerja populer untuk memilih metrik yang tepat:

• USE method (Utilization, Saturation, Errors): berfokus pada resource. Utilization adalah seberapa penuh resource dipakai, saturation adalah kelebihan kapasitas, dan errors adalah kegagalan resource. Cocok untuk monitoring infrastruktur.
• RED method (Rate, Errors, Duration): berfokus pada layanan. Rate adalah jumlah request per detik, Errors adalah jumlah request gagal, dan Duration adalah latency distribusi. Cocok untuk microservices.

rate:     http_requests_total
errors:   http_requests_total{status=~"5.."}
duration: http_request_duration_seconds

Contoh di atas akan diubah menjadi query PromQL sungguhan di episode 7. Ingat pola {status=~"5.."} sebagai representasi label filter untuk kode status 5xx.

#Logs — Apa yang Terjadi

Logs adalah catatan peristiwa yang terjadi dalam sistem, biasanya satu baris per kejadian lengkap dengan timestamp. Filosofi log sederhana: ia adalah sumber kebenaran paling detail tentang apa yang persis terjadi.

#Struktur dan Level Log

• Structured vs unstructured logs: log terstruktur berbentuk key-value atau JSON sehingga mudah diparsing mesin; log tak terstruktur hanyalah teks bebas. Selalu prioritaskan log terstruktur — detailnya dibahas di episode 12.
• Log levels: DEBUG, INFO, WARN, ERROR, dan FATAL digunakan untuk mengelompokkan tingkat kepentingan. Level yang salah (terlalu verbose di production) akan membuang biaya storage.

#Contextual dan Correlation

Log yang baik membawa konteks: service name, request ID, user ID, dan terutama TraceID. Dengan TraceID, sebuah baris log bisa dihubungkan langsung ke trace yang memuatnya. Inilah jembatan utama antara logs dan traces.

{
  "level": "error",
  "ts": "2026-08-10T09:12:33Z",
  "service": "checkout",
  "trace_id": "b3c9e1a2f4d50781",
  "msg": "payment gateway timeout"
}

Perhatikan pola "trace_id" di atas — field seperti inilah yang dipakai Grafana untuk otomatis mengorelasikan log dengan trace di episode 18.

#Traces — Mengapa Itu Terjadi

Traces memetakan perjalanan sebuah request melintasi banyak service. Inilah pillar yang paling membedakan observability dari monitoring tradisional.

#Span, Trace, dan Relasi

• Span: satu unit kerja bernama dengan durasi, misalnya "query database" atau "call payment API". Setiap span membawa start time, duration, atribut, dan status.
• Trace: kumpulan span yang membentuk satu request utuh, dihubungkan oleh TraceID yang sama.
• Parent-child relationships: sebuah span bisa menjadi parent dari span lain, membentuk pohon — misalnya span HTTP request menjadi induk dari span database query.
• Critical path analysis: mengidentifikasi span terpanjang dalam trace untuk menemukan bottleneck.

#Context Propagation

Agar trace terbentuk lintas service, setiap service harus meneruskan context — TraceID, SpanID, dan flags sampling — ke service berikutnya lewat header HTTP. Standar yang paling banyak dipakai adalah W3C Trace Context dengan header traceparent.

traceparent: 00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01

Format header traceparent memiliki empat bagian yang dipisahkan tanda hubung: versi, TraceID, SpanID, dan flags. Detail propagation akan kalian praktikkan langsung di episode 14.

#Korelasi Antar Pillars

Kekuatan observability muncul saat ketiga pillars digabungkan. Beberapa mekanisme korelasi yang umum:

• Exemplars: metrik tertentu membawa referensi ke contoh trace, sehingga dashboard metrik bisa langsung membuka trace yang relevan.
• TraceID dalam logs: setiap log membawa TraceID yang menghubungkannya ke trace.
• Unified querying: dari Grafana, kalian bisa pindah dari metrik ke log ke trace tanpa berpindah tool.
• Context switching workflows: alur standar penyelidikan — mulai dari alert, lihat metrik, masuk ke trace, lalu telusuri log terkait.

Alur ini dijuluki golden triangle of observability. Rangkaian alert → metrics → traces → logs akan menjadi pola debugging utama di episode 18 dan 21.

alert -> metrics -> traces -> logs

Kalian akan melihat diagram alert -> metrics -> traces -> logs ini berulang kali. Hafalkan arahannya, karena hampir semua investigasi insiden dimulai dari sini.

#Penutup

Di episode 2 ini kalian memahami filosofi dan konsep ketiga pillar observability: metrics yang menjawab "apa yang terjadi" dengan tipe counter, gauge, histogram, dan summary, logs yang menjawab "apa yang persis terjadi" dalam bentuk terstruktur, serta traces yang menjawab "mengapa" lewat span dan context propagation.

Inti yang harus dibawa pulang:

• Metrics memakai metode USE untuk resource dan RED untuk layanan.
• Log terstruktur dengan TraceID adalah jembatan menuju trace.
• Trace dibangun dari span dengan relasi parent-child.
• Context propagation standar W3C menyatukan trace lintas service.
• Korelasi pillars lewat exemplars, TraceID, dan unified querying.
• Alur golden triangle: alert, metrics, traces, lalu logs.

Di episode 3 selanjutnya kita akan membahas OpenTelemetry — standard observability yang vendor-agnostic, dari sejarah merger OpenTracing dan OpenCensus, komponen API dan SDK, hingga alasan mengapa ia menjadi fondasi instrumentasi modern. Pastikan pemahaman tiga pillars kalian solid sebelum lanjut.