Monitoring vs Observability dalam Sistem Terdistribusi

Pendahuluan

Istilah monitoring dan observability sering dipakai bergantian, seolah keduanya hal yang sama. Dalam operasi sistem terdistribusi, penyamaan ini justru sering menimbulkan investasi yang salah. Ada tim yang mengira sudah membangun observability padahal sebenarnya hanya punya dashboard. Ada juga tim yang buru-buru mengumpulkan trace di mana-mana, tetapi belum memiliki alert dasar untuk mendeteksi gangguan nyata.

Monitoring dan observability saling berkaitan, tetapi keduanya menjawab pertanyaan yang berbeda. Monitoring fokus pada kondisi penting yang sudah diketahui. Observability membantu menyelidiki perilaku sistem yang belum diprediksi sebelumnya.

Konsep Utama

Monitoring menjawab kondisi gagal yang sudah dikenal

Monitoring cocok untuk pertanyaan seperti:

• apakah service masih available
• apakah latency melewati batas
• apakah antrean kerja menumpuk
• apakah database replication lag memburuk
• apakah kapasitas mendekati habis

Sinyal ini stabil dan biasanya bisa dihubungkan ke SLO atau komitmen layanan.

Observability menjawab kondisi gagal yang belum diketahui

Pada sistem terdistribusi, satu request bisa melewati API gateway, auth service, cache, queue, worker, database, dan layanan pihak ketiga. Saat error naik, kita sering belum tahu komponen mana yang perlu ditanya. Observability memberi jalur investigasi melalui kombinasi metrics, logs, traces, dan events.

Metrics, logs, dan traces punya peran berbeda

Metrics menjawab “berapa banyak” dan “seberapa sering”. Logs menjawab “apa yang terjadi pada eksekusi ini”. Traces menjawab “di mana waktu habis atau error berpindah”. Sistem observability yang sehat tidak memaksa satu jenis data mengerjakan semuanya.

Arsitektur / Cara Kerja

Arsitektur telemetry yang cukup matang biasanya terdiri dari:

1. instrumentasi aplikasi dan platform
2. collector atau agent
3. backend metrics, log, dan trace
4. alerting dan dashboard operasional
5. workflow investigasi dan incident review

Instrumentasi harus konsisten. Service perlu punya naming yang seragam, trace context propagation, label environment dan version, serta log terstruktur dengan field yang bermakna. Tanpa itu, backend observability secanggih apa pun akan menghasilkan jawaban yang dangkal.

Cardinality juga perlu dikendalikan. Menaruh user_id, request_id, atau path mentah pada semua metric akan membuat backend mahal dan sulit dipakai. Data berdimensi tinggi lebih cocok berada di trace atau log.

Studi Kasus / Masalah Nyata

Dashboard banyak, jawaban sedikit

Sebuah organisasi memiliki ratusan dashboard, tetapi ketika latency API pembayaran melonjak, tim tetap tidak bisa menjelaskan dependency mana yang paling memengaruhi jalur tersebut. Mereka punya monitoring, tetapi belum punya observability yang menghubungkan trace, deploy event, dan latency dependency.

Alert bising membuat insiden lambat

Tim SRE menerima puluhan alert setiap hari untuk CPU tinggi, disk usage, packet retry, dan error log tertentu. Sebagian besar tidak berkorelasi dengan dampak pengguna. Saat insiden besar datang, engineer sudah kebal terhadap notifikasi. Ini contoh monitoring tanpa actionability.

Trace ada, context propagation kacau

Banyak service mengirim trace, tetapi beberapa hop tidak meneruskan context sehingga satu request terpecah menjadi beberapa potongan trace. Data technically ada, tetapi investigasi tetap melelahkan.

Best Practices

Gunakan monitoring untuk known-important conditions

Alert utama sebaiknya berbasis availability, latency yang relevan bagi pengguna, error budget burn, health dependency kritis, dan saturation yang benar-benar butuh tindakan.

Gunakan observability untuk mempercepat investigasi

Engineer harus bisa melompat dari alert metrik ke trace terkait, lalu ke log terstruktur, lalu ke event deploy atau perubahan konfigurasi.

Rawat skema telemetry seperti API

Setiap label, field log, dan atribut trace punya dampak biaya dan query pattern. Perlakukan perubahan skema telemetry sebagai desain antarmuka, bukan detail kecil.

Kesalahan Umum

• mengira dashboard banyak berarti sistem sudah observable
• mem-paging tim pada sinyal mentah tanpa konteks dampak pengguna
• membiarkan cardinality metric tumbuh tanpa governance
• mengumpulkan trace tanpa context propagation yang konsisten
• menyimpan log sangat besar tanpa strategi retensi dan query

Kesimpulan

Monitoring memberi tahu saat kondisi penting yang sudah dikenal mulai keluar jalur. Observability membantu menjelaskan perilaku baru yang tidak diprediksi. Tim yang matang membangun keduanya secara sengaja: monitoring untuk deteksi yang dapat ditindaklanjuti, observability untuk investigasi yang cepat dan akurat.