Metrics, Logs, dan Traces dalam Observability

Monitoring memberi tahu Anda bahwa ada masalah. Observability membantu Anda memahami mengapa masalah itu terjadi, termasuk untuk kondisi yang belum pernah diantisipasi sebelumnya. Kemampuan itu dibangun dari tiga jenis sinyal: metrics, logs, dan traces.

Tiga sinyal, tiga pertanyaan

Ketiganya saling melengkapi. Metrics biasanya menjadi pintu masuk karena murah disimpan dan cepat dianalisis, sedangkan logs dan traces memberi detail ketika Anda perlu menggali lebih dalam.

Metrics

Metrics adalah pengukuran numerik yang dikumpulkan secara berkala: jumlah request, latensi, penggunaan CPU, atau panjang antrean. Karena berupa agregat, metrics cocok untuk dashboard, tren jangka panjang, dan alert.

Contoh query PromQL untuk menghitung persentase request yang gagal dalam lima menit terakhir:

sum(rate(http_requests_total{status=~"5.."}[5m]))
/
sum(rate(http_requests_total[5m]))

Dua kerangka yang membantu memilih metrics:

• RED untuk layanan: Rate (jumlah request), Errors (request gagal), Duration (latensi).
• USE untuk resource: Utilization, Saturation, Errors pada CPU, memori, disk, dan jaringan.

Logs

Logs mencatat kejadian individual beserta konteksnya. Log terstruktur, misalnya dalam format JSON, jauh lebih mudah dicari dan difilter dibanding teks bebas.

{
  "timestamp": "2026-10-20T08:15:42.120Z",
  "level": "error",
  "service": "checkout",
  "message": "payment provider timeout",
  "route": "/api/checkout",
  "duration_ms": 5003,
  "trace_id": "4bf92f3577b34da6a3ce929d0e0e4736"
}

Praktik yang membantu:

• Gunakan level log secara konsisten dan hindari log berlebihan di jalur yang sering dipanggil.
• Jangan mencatat data sensitif seperti password, token, atau data pribadi lengkap.
• Sertakan identitas korelasi seperti trace_id agar log dapat dihubungkan dengan trace.

Traces

Pada sistem yang terdiri dari beberapa layanan, satu request pengguna dapat melewati API gateway, layanan aplikasi, cache, dan database. Trace merekam perjalanan tersebut sebagai rangkaian span: setiap span mewakili satu operasi dengan waktu mulai, durasi, dan atribut.

Dengan trace, pertanyaan seperti "mengapa checkout lambat?" dapat dijawab dengan melihat span mana yang memakan waktu paling lama. OpenTelemetry kini menjadi standar terbuka yang umum dipakai untuk menghasilkan dan mengirim traces, metrics, dan logs tanpa terikat pada satu vendor.

Menghubungkan ketiganya

Nilai observability muncul ketika sinyal-sinyal ini dapat ditelusuri satu sama lain. Alur investigasi yang umum:

1. Alert dari metrics: error rate checkout naik di atas ambang batas.
2. Dashboard menunjukkan kenaikan terjadi pada satu route dan dimulai pada waktu tertentu.
3. Traces pada rentang waktu tersebut memperlihatkan span ke payment provider yang lambat.
4. Logs dengan trace_id yang sama menunjukkan pesan timeout beserta detailnya.

Agar alur ini berjalan, gunakan nama layanan dan label yang konsisten di semua sinyal, serta propagasi konteks trace di setiap panggilan antar layanan.

Alert berdasarkan gejala

Alert yang baik membutuhkan tindakan. Arahkan alert pada gejala yang dirasakan pengguna, seperti error rate atau latensi yang melewati batas, bukan pada setiap penyebab yang mungkin. CPU tinggi yang tidak memengaruhi pengguna lebih cocok ditampilkan di dashboard daripada membangunkan seseorang di tengah malam.

Mulai dari mana

Untuk tim yang baru memulai, urutan berikut biasanya paling bermanfaat:

1. Kumpulkan metrics RED untuk layanan utama dan buat satu dashboard ringkas.
2. Ubah log menjadi terstruktur dan kirim ke penyimpanan terpusat.
3. Tambahkan alert untuk dua atau tiga gejala terpenting.
4. Perkenalkan tracing ketika jumlah layanan mulai bertambah dan investigasi lintas layanan menjadi sulit.

Penutup

Metrics menunjukkan adanya masalah, traces menunjukkan lokasinya, dan logs menjelaskan detailnya. Ketiganya paling berguna ketika saling terhubung dan dirancang untuk menjawab pertanyaan nyata tentang sistem Anda.