Monitoring vs Observability dalam Sistem Terdistribusi

TL;DR

• Monitoring memberi tahu bahwa sesuatu salah; observability membantu menjelaskan mengapa dan di mana.
• Sistem terdistribusi membutuhkan korelasi lintas signal, bukan sekadar lebih banyak grafik.
• Tim yang matang tidak memilih salah satu; mereka membangun keduanya dengan fungsi yang berbeda.

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.

Problem di Production

Masalah paling umum adalah organisasi mengumpulkan metric, log, dan trace tanpa kejelasan fungsi. Alert menjadi bising, dashboard membesar tanpa arah, dan saat insiden datang operator tetap membuka banyak tool tanpa jalur diagnosis yang jelas. Ini bukan kekurangan data; ini kekurangan model operasi.

Mental Model

Monitoring adalah mekanisme deteksi. Observability adalah kemampuan bertanya pada sistem. Ketika dua hal ini dipahami sebagai fungsi yang berbeda, tim bisa menentukan mana yang layak dijadikan alert dan mana yang cukup menjadi bahan investigasi.

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.

Dari sudut operasi

Secara operasional, perbedaan paling terasa ada pada incident triage. Monitoring memberi alarm awal, sementara observability memberi cardinality, trace linkage, dan context untuk narrowing down. Tanpa keduanya, tim bergeser antara tidak tahu ada masalah dan tahu ada masalah tetapi tidak tahu harus melihat ke mana.

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.

Decision point yang sering menentukan hasil

Arsitektur observability yang sehat biasanya mengalir dari instrumentation yang konsisten ke storage backend yang tepat, lalu ke query dan alert yang sesuai use case. Mencampur semuanya ke satu backend atau satu pola retention jarang menghasilkan hasil terbaik.

Practical Implementation

Mulai dari kontrol paling sempit yang bisa langsung memberi nilai operasional. Fokusnya bukan membuat desain paling lengkap, tetapi membuat satu jalur implementasi yang dapat direview, diuji, dan dipulihkan.

receivers:
  otlp:
    protocols:
      http:
      grpc:
processors:
  batch:
exporters:
  prometheus:
  logging:

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.

Trade-offs

• Lebih banyak cardinality memberi diagnosis lebih tajam, tetapi meningkatkan biaya penyimpanan dan query.
• Trace sangat berguna untuk permintaan individual, tetapi implementasinya lebih mahal daripada metric dasar.
• Alert yang terlalu kaya context enak dibaca, tetapi lebih sulit dirawat daripada threshold sederhana.

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.

Guardrail tambahan yang layak dipasang

• Lebih banyak cardinality memberi diagnosis lebih tajam, tetapi meningkatkan biaya penyimpanan dan query.
• Trace sangat berguna untuk permintaan individual, tetapi implementasinya lebih mahal daripada metric dasar.
• Alert yang terlalu kaya context enak dibaca, tetapi lebih sulit dirawat daripada threshold sederhana.

Failure Modes

• Tim menganggap semua grafik observability layak menjadi alert dan akhirnya menciptakan noise.
• Instrumentation tidak konsisten antarservice sehingga korelasi antar-signal patah.
• Biaya observability naik tanpa kontrol karena label/cardinality tidak dibatasi.

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.

Pada level senior engineer, tujuan utamanya bukan hanya membuat sistem berjalan, tetapi membuat pilihan desainnya cukup jelas untuk diaudit, diubah, dan dipulihkan saat kondisi produksi memburuk.

Pada level senior engineer, tujuan utamanya bukan hanya membuat sistem berjalan, tetapi membuat pilihan desainnya cukup jelas untuk diaudit, diubah, dan dipulihkan saat kondisi produksi memburuk.