Observability vs Monitoring #
Monitoring dan observability sering digunakan bergantian, padahal keduanya mewakili dua cara berpikir yang sangat berbeda tentang bagaimana kamu memahami sistem. Monitoring adalah tentang memantau hal-hal yang sudah kamu ketahui dan sudah kamu siapkan — apakah CPU di bawah threshold? Apakah endpoint health check merespons? Observability adalah kemampuan untuk menjawab pertanyaan yang belum kamu bayangkan sebelumnya, menggunakan data yang sudah dikumpulkan dari sistem. Di era microservices dan sistem terdistribusi yang kompleks, monitoring saja tidak cukup.
Perbedaan Fundamental #
Monitoring:
"Apakah sistem berjalan sesuai yang diharapkan?"
→ Kamu definisikan KPI dan threshold di depan
→ Pantau apakah nilai tersebut melewati batas
→ Alert jika ada yang keluar dari parameter yang dikenal
→ Cocok untuk: kondisi yang sudah diketahui dan bisa diantisipasi
Analogi: speedometer di mobil
→ Kamu tahu batas kecepatan, sensor langsung beri tahu jika terlampaui
→ Tapi speedometer tidak bisa tahu "kenapa mesin berbunyi aneh"
Observability:
"Mengapa sistem berperilaku seperti ini?"
→ Kemampuan untuk menjawab pertanyaan yang tidak dipersiapkan
→ Berdasarkan data yang dikumpulkan secara komprehensif
→ Memungkinkan eksplorasi dan debugging dari first principles
→ Cocok untuk: masalah yang tidak pernah terjadi sebelumnya
Analogi: sistem diagnostik medis lengkap
→ Bukan hanya detak jantung, tapi semua data yang memungkinkan
dokter mendiagnosis penyakit yang belum pernah dilihat sebelumnya
Mengapa Monitoring Saja Tidak Cukup #
Sistem modern bersifat kompleks dan dinamis:
Kompleksitas:
→ 50+ microservice yang saling berinteraksi
→ Dependensi pada third-party API
→ Infrastructure yang di-scale secara dinamis
→ Behavior yang emerge dari interaksi komponen
Sifat masalah yang tidak bisa diprediksi:
→ "Unknown unknowns" — masalah yang tidak pernah dibayangkan sebelumnya
→ Bug yang hanya muncul pada kombinasi kondisi tertentu
(satu user, dengan browser tertentu, di waktu tertentu,
saat database replica lag tinggi)
→ Masalah yang terlihat berbeda tergantung dari sudut pandang mana
Pertanyaan yang tidak bisa dijawab monitoring biasa:
✗ "Mengapa user X mengalami checkout lambat padahal metrik umum normal?"
✗ "Request yang gagal: apakah ada pola di antara mereka?"
✗ "Service mana yang paling berkontribusi pada P99 latency naik?"
✗ "Apakah deploy tadi menyebabkan regresi untuk fitur tertentu?"
Monitoring bisa detect "ada masalah" tapi sering tidak bisa
menjawab "masalah apa dan di mana".
Observability memungkinkan investigasi mendalam untuk menjawabnya.
Tiga Pilar Observability #
Observability dibangun di atas tiga jenis telemetry yang saling melengkapi.
┌─────────────────────────────────────────────────────────┐
│ OBSERVABILITY │
│ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ LOGS │ │ METRICS │ │ TRACES │ │
│ │ │ │ │ │ │ │
│ │ Peristiwa│ │Kondisi │ │ Perjalanan│ │
│ │ diskrit │ │agregat │ │ request │ │
│ │ "Apa │ │"Seberapa │ │"Melewati │ │
│ │ terjadi"│ │ baik" │ │ mana saja"│ │
│ └──────────┘ └──────────┘ └──────────┘ │
│ │
│ Bersama: menjawab "mengapa sistem berperilaku ini?" │
└─────────────────────────────────────────────────────────┘
Setiap pilar melengkapi yang lain:
Metrics memberi tahu: "ada masalah" (error rate naik)
↓
Traces membantu: "di mana masalahnya" (service X paling lambat)
↓
Logs mengungkap: "kenapa masalah terjadi" (error detail di service X)
High Cardinality — Kunci Observability yang Berguna #
Salah satu konsep yang membedakan observability modern dari monitoring tradisional adalah kemampuan menangani high cardinality data.
Cardinality = jumlah nilai unik yang mungkin untuk suatu dimensi
Low cardinality (mudah di-aggregate, cocok untuk metrics):
→ status_code: 200, 201, 400, 404, 500 (sedikit nilai unik)
→ region: us-east-1, ap-southeast-1, eu-west-1
High cardinality (tidak cocok untuk metrics tradisional):
→ user_id: jutaan nilai unik
→ request_id: setiap request unik
→ customer_name: ribuan nilai
Masalah monitoring tradisional dengan high cardinality:
→ Metric series explode jika di-breakdown per user_id
→ "Error rate per user_id" = jutaan metric series → tidak feasible
Solusi observability modern:
→ Data yang high cardinality disimpan sebagai event (log/trace)
→ Bisa di-query dengan filter: "tampilkan semua trace dengan user_id=12345"
→ Tidak perlu pre-aggregate — query on-demand
Contoh kekuatan high cardinality:
"Tampilkan P99 latency untuk semua request dengan
customer_plan=enterprise AND region=ap-southeast-1
AND browser=Safari AND feature_flag=new-checkout"
→ Monitoring tradisional tidak bisa menjawab ini
→ Observability modern bisa
Praktik Membangun Observability #
Mulai dari instrumentasi yang baik:
1. Semua service harus emit tiga sinyal:
✓ Structured logs dengan trace_id
✓ Metrics RED (Rate, Errors, Duration)
✓ Distributed traces dengan context propagation
2. Gunakan standar terbuka:
✓ OpenTelemetry untuk instrumentasi
✓ W3C Trace Context untuk propagasi
✓ Pilih backend yang bisa berubah tanpa ganti instrumentasi
3. Correlate ketiga sinyal:
✓ Trace ID yang sama hadir di log, trace, dan bisa di-link ke metrics
✓ Dari alert metrics → klik → lihat trace → klik → lihat log
→ Investigasi yang mulus tanpa pindah-pindah tool dan manual search
4. Observability-driven development:
✓ Tambahkan instrumentasi bersamaan dengan kode baru
✓ Bukan setelah ada masalah di produksi
✓ "Bagaimana kita tahu ini bekerja?" = pertanyaan sebelum deploy
Kultur Observability #
Observability bukan hanya tentang tools — ia tentang cara tim mendekati sistem yang mereka bangun.
Tim dengan kultur observability yang baik:
Saat release fitur baru:
✓ "Metrik apa yang kita pantau untuk fitur ini?"
✓ "Bagaimana kita tahu fitur ini bekerja dengan benar?"
✓ Dashboard dibuat sebelum atau bersamaan dengan deploy
Saat ada insiden:
✓ Investigasi berbasis data, bukan spekulasi
✓ "Mari kita lihat trace dari request yang gagal"
✓ Bukan: "Sepertinya ini masalah X"
Setelah insiden (post-mortem):
✓ "Bagaimana kita bisa mendeteksi ini lebih cepat?"
✓ Tambahkan instrumentasi untuk mengisi gap yang ditemukan
✓ Update runbook dengan query yang berguna saat investigasi
Tim dengan observability buruk:
✗ "Coba restart dulu, lihat apakah hilang sendiri"
✗ SSH ke server dan grep log secara manual
✗ Instrumentasi ditambahkan hanya setelah ada masalah
✗ Dashboard yang tidak pernah di-update dan tidak mencerminkan sistem nyata
Monitoring vs Observability: Keduanya Dibutuhkan #
Monitoring tetap relevan dan dibutuhkan:
✓ SLO monitoring: apakah kita memenuhi commitment ke user?
✓ Infrastructure health: apakah server, database, network sehat?
✓ Alerting: deteksi masalah secara otomatis
✓ Compliance: audit trail yang terprediksi
Observability melengkapi, bukan menggantikan:
✓ Investigasi mendalam saat alert trigger
✓ Debugging masalah yang kompleks dan tidak terprediksi
✓ Memahami perilaku sistem yang baru
✓ Performance optimization yang guided oleh data
Alur yang ideal:
Monitoring alert → "ada masalah!"
↓
Observability tools → "apa masalahnya? di mana? kenapa?"
↓
Fix → deploy → verifikasi melalui monitoring bahwa fix berhasil
Ringkasan #
- Monitoring menjawab “apakah ada masalah?”, observability menjawab “mengapa masalah terjadi?” — keduanya dibutuhkan, bukan pilihan salah satu.
- Sistem modern terlalu kompleks untuk diprediksi sepenuhnya — unknown unknowns membutuhkan kemampuan investigasi yang fleksibel, bukan hanya alert yang sudah dikonfigurasi.
- Tiga pilar observability saling melengkapi — metrics mendeteksi, traces menemukan lokasi, logs mengungkap detail penyebab.
- High cardinality adalah kunci observability yang berguna — kemampuan filter dan query per user_id, request_id, atau kombinasi atribut kompleks memberi insight yang tidak bisa didapat dari metrics aggregate.
- Instrumentasi bersamaan dengan kode baru, bukan setelah masalah terjadi — observability sebagai kebiasaan, bukan respons reaktif.
- Kultur observability: investigasi berbasis data, bukan spekulasi — “mari kita lihat trace” bukan “sepertinya masalahnya di sini”.