Halo 👋

Waktu sebuah API mulai terasa lambat, error muncul random, atau sistem kerasa lagi "nggak sehat", hal pertama yang biasanya dilakuin engineer adalah ngecek logs. Dan itu sangat masuk akal, karena logs emang sering jadi sumber informasi tercepat waktu keadaan mulai berantakan.

Tapi makin kompleks sebuah sistem, makin kelihatan juga kalau logs aja itu nggak selalu cukup.

Di sistem modern, satu request bisa lewat banyak komponen: API gateway, auth service, business logic, database, cache, sampai external API. Waktu ada bottleneck atau failure di salah satu rantai itu, nyari akar masalah cuma dari barisan log yang kepisah-pisah bisa jadi ribet banget.

Nah, di sinilah observability jadi penting.

Apa Itu Observability?

Simpelnya, observability adalah kemampuan sebuah sistem buat bantu kita memahami apa yang lagi terjadi di dalamnya saat ini berdasarkan data yang dihasilkan sistem itu sendiri.

Jadi bukan cuma tahu kalau ada yang rusak, tapi juga bisa melacak:

  • masalahnya ada di bagian mana
  • kapan mulai kejadian
  • komponen mana yang paling kena dampaknya
  • kenapa hal itu bisa terjadi

Observability bantu engineer jawab pertanyaan-pertanyaan yang biasanya susah banget dijawab kalau cuma ngandelin monitoring dasar.

Monitoring vs Observability

Banyak orang pakai istilah monitoring dan observability secara bergantian, padahal sebenarnya keduanya nggak persis sama.

Monitoring

Monitoring biasanya fokus ke hal-hal yang dari awal memang udah kita definisiin. Contohnya:

  • CPU usage naik di atas 80%
  • memory hampir penuh
  • latency API lewat ambang batas tertentu
  • error rate naik

Dengan monitoring, kita tahu ada sesuatu yang salah.

Observability

Observability melangkah satu tingkat lebih jauh. Dia bantu kita cari tahu kenapa hal itu bisa salah.

Kalau monitoring bilang:

"Latency lagi tinggi."

maka observability bantu jawab:

"Latency tinggi karena request ke Service B melambat setelah sebuah query database tertentu jadi jauh lebih lama dari biasanya."

Jadi singkatnya:

  • Monitoring ngasih tahu ada masalah.
  • Observability bantu investigasi akar masalahnya.

Kenapa Logs Aja Nggak Cukup?

Logs tetap sangat penting. Sampai sekarang pun, logs masih jadi salah satu fondasi paling berguna buat debugging.

Tapi logs juga punya batasan, apalagi kalau sistem lu mulai tumbuh jadi arsitektur yang lebih terdistribusi.

Berikut beberapa masalah umum kalau cuma ngandelin logs:

1. Logs tersebar di banyak service

Kalau satu request lewat lima service, jejaknya bakal nyebar di lima tempat berbeda. Tanpa cara yang jelas buat menghubungkan semuanya, lu bakal susah nyusun potongan-potongan informasinya secara manual.

2. Volumenya bisa sangat besar

Di environment production, jumlah logs bisa gila-gilaan. Nyari sinyal yang benar-benar penting di tengah semua noise itu sering makan waktu banyak.

3. Susah lihat hubungan antar komponen

Logs biasanya nunjukkin event, tapi nggak selalu nunjukkin gambaran utuh soal hubungan antar proses. Lu mungkin tahu ada error, tapi belum tentu tahu perjalanan lengkap request itu dari awal sampai akhir.

4. Nggak selalu cukup buat analisis performa

Kalau sebuah endpoint lambat, log mungkin cuma kasih timestamp masuk dan keluar. Tapi belum tentu bisa nunjukkin bagian mana yang paling lambat: query database, call ke service lain, atau external API.

Karena itu, observability modern nggak cuma bergantung ke logs.

Tiga Pilar Observability

Secara umum, observability dibangun di atas tiga jenis data telemetry:

  • Logs
  • Metrics
  • Traces

Tiga hal ini saling melengkapi satu sama lain.

Logs

Logs adalah catatan dari event-event spesifik yang terjadi di dalam sistem.

Contohnya:

  • ada request masuk
  • login user gagal
  • error koneksi database
  • background job selesai dijalankan

Logs cocok banget buat lihat detail-detail kecil dari event tertentu.

Metrics

Metrics adalah data numerik yang diukur dari waktu ke waktu.

Contohnya:

  • requests per second
  • response time
  • error rate
  • CPU usage
  • memory usage

Metrics bagus banget buat melihat tren, pola, dan kondisi kesehatan sistem secara keseluruhan.

Traces

Traces nunjukkin perjalanan sebuah request waktu dia lewat berbagai komponen di dalam sistem.

Dengan traces, lu bisa lihat:

  • request itu nyentuh service apa aja
  • berapa lama waktu yang dihabiskan di tiap langkah
  • bottleneck-nya ada di mana
  • service mana yang ngelempar error

Kalau logs itu potongan cerita, dan metrics itu ringkasan statistiknya, maka trace adalah alur cerita lengkap dari satu request.

Kenapa Observability Makin Penting di Sistem Modern?

Di aplikasi yang simpel dan cuma punya satu service, debugging biasanya masih cukup straightforward. Tapi makin besar sistemnya, makin banyak tantangan baru yang muncul:

  • jumlah service makin banyak
  • komunikasi antar service makin kompleks
  • dependency eksternal makin banyak
  • deployment makin sering
  • perubahan terjadi makin cepat

Di kondisi kayak gitu, pertanyaan-pertanyaan seperti ini jadi sering banget muncul:

  • Kenapa endpoint ini lambat padahal CPU normal?
  • Kenapa error ini cuma muncul sesekali?
  • Kenapa Service A kelihatannya aman, tapi user tetap gagal pakai fitur tertentu?
  • Sebenarnya request ini macet di bagian mana?

Tanpa observability yang bagus, investigasi hal-hal kayak gini bakal terasa lambat, manual, dan sering mengandalkan tebakan.

Contoh Sederhana

Bayangin ada alur request seperti ini:

  1. Client manggil API
  2. API manggil auth service
  3. Auth service validasi token
  4. API manggil user service
  5. User service ambil data dari DB
  6. API balikin response

Kalau response-nya jadi lambat, penyebabnya bisa macam-macam:

  • auth service lagi lambat
  • user service lemot
  • query database jelek
  • ada masalah jaringan antar service
  • dependency eksternal timeout

Kalau lu cuma ngandelin logs, kemungkinan besar lu harus buka banyak file atau dashboard yang beda cuma buat nyusun timeline-nya.

Dengan observability yang bagus, investigasi kayak gini jadi jauh lebih gampang.

Observability Itu Lebih dari Sekadar Tools

Ada satu hal penting yang perlu dipahami dari awal: observability itu bukan cuma soal install tools kayak Grafana, Loki, Jaeger, atau Prometheus.

Observability adalah sebuah pendekatan dalam mendesain sistem supaya lebih gampang dipahami waktu semuanya nggak berjalan sesuai rencana.

Tools memang penting, tapi yang lebih penting adalah:

  • gimana sistem lu menghasilkan data telemetry
  • gimana data itu saling dikorelasikan
  • gimana engineer bisa benar-benar memakainya buat debugging dan analisis

Penutup

Monitoring bantu kita tahu kalau ada masalah.
Observability bantu kita paham kenapa masalah itu terjadi.

Di backend system yang makin kompleks, kemampuan buat melihat logs, metrics, dan traces secara terhubung itu bukan lagi sekadar "nice to have" — tapi udah jadi kebutuhan besar.

Di artikel berikutnya, kita bakal bahas salah satu fondasi utama dari observability modern: OpenTelemetry — sebuah standar terbuka buat menghasilkan, mengumpulkan, dan mengirim data telemetry dari aplikasi.

Selamat membaca 🚀