Observability 101: Logs, Metrics, Traces untuk Tim Modern

Daftar Isi

Bedanya Monitoring dan Observability
Tiga Pilar Observability (LMT)
Logs: Menceritakan Detail Kejadian
Metrics: Mengukur Kesehatan Sistem Secara Keseluruhan
Traces: Melacak Perjalanan Request Lintas Service
Cara Praktis Memulai Observability di Tim Kamu
Anti-Pattern yang Sering Terjadi
Kesimpulan

Bedanya Monitoring dan Observability

Sering kali monitoring dan observability dipakai bergantian, padahal punya arti yang berbeda. Monitoring adalah mengumpulkan data untuk melihat kondisi sistem—seperti melihat dashboard CPU load atau notifikasi error 500. Monitoring bisa menjawab pertanyaan “Apakah sistem sedang error?”, tetapi belum tentu menjawab “Kenapa error ini terjadi?”.

Di sinilah Observability masuk. Observability adalah kemampuan kita untuk memahami apa yang terjadi di dalam sistem hanya dengan melihat data output eksternal yang dihasilkannya. Kalau monitoring adalah alat deteksi, observability adalah alat investigasi dan troubleshooting.

Sistem yang punya observability yang baik akan memungkinkan engineer menavigasi dari notifikasi high-level turun terus sampai ke baris kode atau database query yang bermasalah, tanpa harus menebak-nebak atau memutar ulang error secara manual.

Tiga Pilar Observability (LMT)

Dalam ekosistem modern (terutama microservices dan cloud-native), observability biasanya dibangun di atas tiga pilar utama:

Logs (Catatan Kejadian)
Metrics (Satuan Ukur)
Traces (Jejak Request)

Ketiganya bekerja sama. Metrics biasanya jadi trigger peringatan pertama, Traces membantu menunjuk ke area atau service mana yang bermasalah, dan Logs memberikan detail kenapa kegagalan itu spesifik terjadi di titik tersebut.

Logs: Menceritakan Detail Kejadian

Log adalah catatan spesifik tentang sesuatu yang terjadi pada waktu tertentu. Contohnya: [2026-02-12 10:15:00] ERROR: Payment failed for user 12345: Insufficient balance.

Dalam arsitektur lama, log ditulis ke dalam file teks dan dibaca dengan tail atau grep. Tapi dalam sistem terdistribusi, pendekatan tersebut tidak lagi efektif. Saat ini kita memakai Structured Logging (biasanya format JSON).

Kenapa Structured Logging Penting? Kalau log berbentuk plain text, mesin pencari seperti Elasticsearch atau Datadog sulit memfilternya. Kalau log berbentuk JSON seperti {"level": "error", "event": "payment_failed", "user_id": 12345, "reason": "timeout"}, kita bisa dengan instan men-query “Tampilkan semua log error untuk event payment_failed di service billing”.

Tips untuk Logs:

Jangan log informasi sensitif (password, nomor kartu kredit penuh).
Gunakan level log (INFO, WARN, ERROR, DEBUG) dengan benar. Jangan pakai ERROR untuk hal yang di-expect gagal (seperti input validasi user yang salah).

Metrics: Mengukur Kesehatan Sistem Secara Keseluruhan

Metrics adalah angka yang dihitung dalam rentang waktu (time-series data). Angka ini menunjukkan seberapa sehat sistem bekerja secara keseluruhan.

Metrics jauh lebih murah untuk disimpan dibanding Logs karena hanya menyimpan rentetan angka. Contoh umum metrics adalah persentase CPU, jumlah memori tersedia, dan yang sering jadi acuan utama, yaitu RED method (Rate, Errors, Duration).

Rate: Berapa banyak request yang masuk per detik?
Errors: Berapa persentase request yang gagal?
Duration: Berapa lama waktu yang dihabiskan untuk merespons (biasanya dilihat dari persentil 95th atau p99)?

Metrics sangat ideal untuk menempelkan Alerts (notifikasi). Misalnya, “Beri tahu di Slack kalau error rate pembayaran di atas 5% selama 5 menit terakhir”.

Traces: Melacak Perjalanan Request Lintas Service

Kalau sistem kamu hanya terdiri dari satu aplikasi (monolith), logs dan metrics mungkin sudah cukup. Tapi ketika masuk ke dunia microservices, satu klik user di frontend bisa melewati API Gateway, Service A, Service B, dua jenis Database, dan Redis cache.

Kalau proses ini lambat atau gagal di tengah jalan, log dari Service B tidak akan punya konteks keseluruhan. Itulah fungsi Distributed Tracing.

Sebuah Trace merekam satu perjalanan utuh. Trace terdiri dari elemen yang disebut Spans, di mana setiap Span mewakili satu unit pekerjaan (misal: query ke DB, memanggil API eksternal). TraceID yang sama akan mengalir (propagated) lewat HTTP Headers ke semua service yang dikunjungi.

Dengan Trace, kamu bisa membuka UI (seperti Jaeger, Zipkin, atau Datadog APM) dan melihat secara visual grafik timeline: Request diterima (1.2 detik) → Service Auth (50ms) → Service Payment DB Query (1.1 detik) → Ketemu masalahnya, query ini lambat.

Cara Praktis Memulai Observability di Tim Kamu

Bagi tim menengah atau startup, tidak perlu langsung membangun infrastruktur rumit. Mulailah secara bertahap:

Standarisasi Log Dulu. Pastikan semua aplikasi memuntahkan (output) log dalam format JSON dan sertakan informasi inti seperti timestamp, severity, dan message.
Setup Metrics Dasar. Jangan mengukur semuanya. Fokus ke metrik trafik (RED) untuk setiap endpoint penting. Buat dashboard yang menampilkan grafik tersebut.
Kumpulkan Error. Simpan error di platform terpusat seperti Sentry, Datadog, atau Elastic Stack.
Implementasikan TraceID. Kalau belum siap setup Jaeger/Zipkin, minimal buat satu ID unik (misalnya X-Request-ID) yang dipassing di HTTP header dan dilog di setiap barisan log JSON. Ini sudah cukup membantu mencari benang merah antar log service.

Anti-Pattern yang Sering Terjadi

Membangun observability yang baik juga berarti menghindari beberapa jebakan umum:

Logging Overload. Menge-log seluruh payload HTTP request setiap saat. Ini akan bikin tagihan cloud membengkak dan performa aplikasi turun, padahal 99% dari log tersebut tidak pernah dibaca.
Alert Fatigue. Mengirim notifikasi Slack untuk setiap error minor atau CPU naik di atas 80%. Kalau pager bunyi terus untuk hal yang bukan insiden serius, engineer akan mulai mengabaikannya (mute alert).
Silo Tools. Beda tim pakai beda alat. Frontend pakai Sentry, Backend pakai ELK, Infra pakai CloudWatch. Ketika ada insiden, susah menyatukan konteks. Platform observability yang baik harusnya menyatukan data.

Kesimpulan

Observability modern bukan sekadar soal menambah “alat monitoring”. Ini soal membangun budaya di mana sistem yang kita deploy cukup “banyak bicara” (dalam bahasa terstruktur) tentang keadaannya sendiri.

Dengan Logs, Metrics, dan Traces yang terintegrasi, fase investigasi error yang tadinya bikin frustrasi bisa berubah menjadi data-driven, terukur, dan tidak membuat panik. Mulailah merapikan log format, buat metrik dasar apik, dan sambungkan dengan trace.