Mengapa Observability & Monitoring Sangat Dibutuhkan?
Bayangkan kamu adalah seorang pilot yang menerbangkan pesawat komersial besar di malam hari di tengah badai awan tebal. Tanpa panel instrumen di kokpit (kecepatan angin, ketinggian, kompas, indikator bahan bakar), kamu menerbangkan pesawat dalam kondisi “buta”. Kamu baru tahu ada kerusakan mesin ketika pesawat sudah menukik tajam ke bumi.
Dalam dunia rekayasa perangkat lunak modern:
- Aplikasi tidak lagi berjalan di satu server sederhana, melainkan terpecah menjadi puluhan hingga ratusan layanan kecil (Microservices), ratusan kontainer Docker, dan tersebar di berbagai kluster Kubernetes lintas kawasan dunia (Multi-Region).
- Jika pengguna melaporkan: “Aplikasi lambat dan gagal checkout pembayaran”, mencari penyebab masalah di antara ribuan server tanpa instrumen pemantau adalah hal yang mustahil.
Monitoring dan Observability adalah “panel kokpit” bagi insinyur DevOps dan SRE (Site Reliability Engineer) untuk melihat kesehatan sistem, memprediksi kegagalan sebelum terjadi, dan memperbaiki masalah dalam hitungan menit.
Perbedaan Monitoring vs Observability
Meskipun sering digunakan bergantian, keduanya memiliki filosofi yang berbeda:
3 Pilar Utama Observability (The Three Pillars)
Untuk mendapatkan observabilitas penuh terhadap sistem, kita mengumpulkan 3 jenis data telemetri:
1. Metrics (Metrik Numerik)
- Definisi: Data numerik terukur yang dikumpulkan dalam interval waktu tertentu (Time-Series Data).
- Karakteristik: Sangat hemat penyimpanan (lightweight), mudah diagregasi menjadi grafik, dan sangat cepat dihitung.
- Contoh:
- Utilisasi CPU & RAM server (%).
- Jumlah permintaan HTTP per detik (Requests Per Second - RPS).
- Rasio error (Error Rate HTTP 500).
- Tools Populer: Prometheus, InfluxDB, Datadog.
2. Logs (Catatan Peristiwa Terperinci)
- Definisi: Catatan baris teks berstempel waktu (timestamped text) yang dikeluarkan aplikasi ketika suatu peristiwa terjadi.
- Karakteristik: Memuat konteks mendalam (ID pengguna, payload transaksi, baris error file), namun memakan kapasitas penyimpanan harddisk yang sangat besar.
- Contoh:
- Tools Populer: Grafana Loki, Elasticsearch/Logstash (ELK Stack), Fluentd.
3. Distributed Tracing (Penelusuran Jejak Terdistribusi)
- Definisi: Melacak perjalanan satu buah permintaan pengguna (Request Flow) dari awal masuk gateway, melintasi puluhan microservices independen, query database, hingga kembali ke pengguna.
- Karakteristik: Memberikan visualisasi latensi berupa diagram Waterfall (Spans) untuk menemukan bottleneck performa.
- Contoh: Mengetahui bahwa dari total loading 3 detik, 2.8 detik dihabiskan karena query
SELECT * FROM orders yang tidak memiliki indeks database!
- Tools Populer: Jaeger, Zipkin, OpenTelemetry, Grafana Tempo.
4 Golden Signals (Standar SRE Google)
Google Site Reliability Engineering (SRE) menetapkan 4 metrik emas yang wajib dipantau pada setiap layanan pengguna:
- Latency (Latensi): Berapa lama waktu yang dibutuhkan sistem untuk membalas permintaan (harus memisahkan latensi request sukses vs request error).
- Traffic (Lalu Lintas): Beban permintaan yang masuk ke sistem (misal: HTTP requests per second, I/O network bandwidth).
- Errors (Tingkat Kegagalan): Berapa banyak permintaan yang gagal (error rate HTTP 5xx, atau transaksi pembayaran gagal).
- Saturation (Saturasi / Kejenuhan): Seberapa penuh sumber daya sistemmu (misal pemakaian memory 92%, connection pool database tersisa 2 slot).
Kapan & Kenapa Observability Ini Bisa Ada?
- Evolusi Monolith ke Microservices: Dahulu aplikasi monolith hanya menghasilkan 1 file log di satu server. Sekarang, satu klik tombol belanja melibatkan panggilan ke 15 container terpisah.
- Lingkungan Server Dinamis (Ephemeral): Di Kubernetes, kontainer hidup dan mati dalam hitungan detik. Jika kontainer mati dan kamu tidak mengirim lognya ke sistem terpusat, catatan penyebab crash akan hilang selamanya.
- Kebutuhan SLA/SLO Bisnis: Perusahaan modern menjanjikan ketersediaan 99.99% (Four Nines). Artinya dalam setahun, downtime maksimal hanya boleh 52 menit! Tanpa observabilitas, mencari akar masalah butuh berjam-jam.
Last modified on October 26, 2026
