# Apa Itu Observability? Panduan Praktis untuk Tim Dev

URL: https://codebasechat.com/id/journal/apa-itu-observability
Type: blog
Locale: id
Published: 2026-10-27
Updated: 2026-10-28

---

> Apa itu observability, dan bagaimana bedanya dengan monitoring? Panduan praktis untuk tim engineering tentang logs, metrics, traces, OpenTelemetry, dan cara mulai dari satu alur kritis.

Pukul 2 pagi, endpoint checkout mengembalikan error 500 untuk sekitar satu dari dua puluh request, tetapi semua dashboard masih berwarna hijau. Celah antara "sistem bilang baik-baik saja" dan "pengguna bilang rusak" itulah yang coba ditutup oleh observability. **Apa itu observability?** Kemampuan memahami apa yang sedang dilakukan sistem Anda dari dalam, dengan membaca data yang dikeluarkannya (logs, metrics, dan traces), cukup baik untuk menjawab pertanyaan yang tidak Anda rencanakan sebelumnya.

Klausa terakhir itulah inti seluruh artikel ini. Sisanya hanyalah detail.

## Observability vs monitoring: pertanyaan yang belum pernah Anda buatkan alert

Monitoring menjawab pertanyaan yang sudah Anda ketahui sejak awal. CPU di atas 90%? Error rate di atas 2%? Antrean makin panjang? Anda memilih metrik, menetapkan ambang batas, dan pager berbunyi ketika salah satunya terlewati.

Observability menjawab pertanyaan yang tidak terpikir untuk ditanyakan. Mengapa hanya request dari satu tenant, pada satu versi aplikasi, setelah deploy tertentu, yang lebih lambat empat detik? Tidak ada yang punya alert untuk itu, karena tidak ada yang memprediksinya.

Jadi keduanya bukan lawan. Monitoring adalah lapisan alerting. Observability adalah yang memungkinkan Anda menyelidiki begitu alert menyala, atau ketika pelanggan menulis keluhan padahal tidak ada alert sama sekali. Jika satu-satunya alat Anda adalah deretan dashboard yang sudah jadi, Anda hanya punya monitoring. Jika Anda bisa mengiris data produksi berdasarkan dimensi apa pun dan menelusuri satu request melintasi beberapa service tanpa men-deploy kode baru, barulah Anda punya observability.

## Tiga sinyal: metrics, logs, dan traces

Kebanyakan definisi dibuka dengan "tiga pilar". Istilahnya agak kaku, tetapi ketiga jenis data itu nyata, dan masing-masing unggul di satu pekerjaan.

- 
**Metrics** adalah angka dari waktu ke waktu: jumlah request per detik, latensi p95, memori yang terpakai. Murah disimpan, cepat di-query, dan bagus untuk menjawab "apakah ada yang salah?". Kurang cocok untuk menjawab "request yang mana, dan kenapa?".

- 
**Logs** adalah catatan kejadian diskret yang diberi timestamp: pembayaran gagal, retry terpicu, feature flag berubah. Logs menyimpan detailnya, tetapi log yang tidak terstruktur di service yang sibuk akan berubah menjadi tumpukan jerami.

- 
**Traces** mengikuti satu request saat ia berpindah antar service. Setiap lompatan adalah span dengan waktu mulai, durasi, dan beberapa atribut. Trace adalah hal yang paling dekat dengan stack trace untuk sistem terdistribusi.

![Log cetak di samping diagram tangan yang menghubungkan beberapa service](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/codebasechat/2026-10/f0aa73-i1.webp)

Survei Grafana 2025 terhadap 1.255 praktisi menunjukkan posisi tim saat ini. [Survei observability dari Grafana](https://grafana.com/blog/2025/03/25/observability-survey-takeaways) mendapati bahwa 95% responden memakai metrics dan 87% memakai logs, tetapi hanya 57% yang memakai traces. Traces adalah sinyal yang paling mungkin membantu menemukan bug terdistribusi, dan sinyal yang paling sedikit disiapkan tim.

Lewati singkatan yang berbunyi "metrics memberi tahu apa, logs memberi tahu kenapa, traces memberi tahu di mana". Kedengarannya rapi, tetapi gagal dalam praktik: log terstruktur yang baik sering kali lebih banyak memberi tahu "di mana" dibanding trace dengan instrumentasi yang buruk.

## Apa yang membuat sistem observable dalam praktik

Mengeluarkan data itu perlu, tetapi belum cukup. Sistem bisa dikatakan observable ketika datanya memiliki tiga sifat.

**Kardinalitas tinggi.** Anda bisa memfilter berdasarkan user ID, tenant, SHA build, region, atau feature flag. Jika alat Anda memaksa agregasi awal berdasarkan nama service dan status code, Anda tidak akan bisa menemukan satu tenant yang berada dalam kondisi buruk.

**Konteks yang menghubungkan sinyal.** Trace ID di setiap baris log memungkinkan Anda melompat dari span yang lambat ke log persis yang dihasilkannya. Tanpa tautan itu, Anda membaca dua cerita terpisah dan menebak bagaimana keduanya saling terkait.

**Detail yang cukup berguna, tetapi tidak sampai tidak terjangkau.** Di sinilah kebanyakan tim kesulitan. Dalam survei Grafana yang sama, responden menyebut lebih dari 100 tool, service, dan proyek yang berbeda, dengan rata-rata tim menjalankan delapan. Biaya termasuk kriteria teratas saat memilih tool. Mengumpulkan semuanya itu mudah. Membayarnya adalah hal yang baru ditemukan orang belakangan.

Berikut titik awal dengan OpenTelemetry, standar instrumentasi yang netral terhadap vendor. Ini contoh Python minimal yang membuat span dan melampirkan atribut yang akan Anda butuhkan pukul 2 pagi:

`from opentelemetry import trace

tracer = trace.get_tracer("checkout")

def charge(order):
    with tracer.start_as_current_span("charge_card") as span:
        span.set_attribute("order.id", order.id)
        span.set_attribute("tenant.id", order.tenant_id)
        span.set_attribute("app.version", APP_VERSION)
        result = payment_client.charge(order)
        span.set_attribute("payment.provider", result.provider)
        return result`Tiga atribut itu adalah perbedaan antara "checkout lambat" dan "checkout lambat untuk tenant 4412 pada versi 3.8.1". [Primer observability dari OpenTelemetry](https://opentelemetry.io/docs/concepts/observability-primer/) menjelaskan konsep di balik ini lebih dalam, dan layak dibaca sekali, meskipun vendor Anda yang mengerjakan konfigurasinya.

## Di mana tool observability berbeda (dan di mana tidak)

Di balik pemasaran, sebagian besar platform menerima tiga sinyal yang sama. Perbedaannya ada pada model harga, kekuatan query, dan seberapa banyak instrumentasi yang dikerjakan untuk Anda.

- 
**Platform all-in-one** menggabungkan metrics, logs, traces, alerting, dan lainnya. Praktis, dengan konsekuensi tagihan berbasis pemakaian yang ikut naik seiring trafik.

- 
**Stack open source** seperti Prometheus, Loki, Tempo, dan Grafana memberi Anda kontrol serta tanpa lisensi per host, dengan konsekuensi Anda harus menjalankan dan menyetelnya sendiri.

- 
**Backend native OpenTelemetry** menerima format standar secara langsung, sehingga berganti vendor tidak berarti menginstrumentasi ulang setiap service.

Datadog adalah acuan untuk kategori all-in-one: cakupannya luas, UI-nya rapi, dan tagihannya layak ditinjau setiap bulan. Sepadan jika Anda menginginkan satu vendor dan punya anggarannya. Lewati jika kepastian biaya adalah batasan utama Anda.

Grafana adalah pilihan open source yang pragmatis. Anda bisa mulai dengan dashboard di atas data yang sudah dimiliki, lalu menambahkan logs dan traces saat dibutuhkan. Siapkan waktu engineering untuk mengelolanya.

![Diagram waterfall trace terdistribusi yang ditampilkan di layar laptop](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/codebasechat/2026-10/fb03e7-i2.webp)

SigNoz dibangun di atas OpenTelemetry sejak awal dan menyatukan metrics, logs, dan traces dalam satu antarmuka open source. Pilihan yang masuk akal untuk tim yang menginginkan pengalaman satu layar tanpa harga all-in-one.

New Relic berada di antara kedua dunia itu, dengan platform hosted dan tier gratis yang cukup luas untuk menjalankan evaluasi sungguhan. Nilailah dari apakah tim Anda sendiri bisa menjawab pertanyaan produksi yang nyata di dalamnya, bukan dari demo-nya.

Tidak satu pun dari ini akan membuat Anda observable dengan sendirinya. Tool hanyalah antarmuka query. Instrumentasilah yang sebenarnya menjadi produknya.

## Bagian yang dilewatkan kebanyakan panduan: observability berhenti di batas kode

Celah ini akan Anda temui begitu memakai tool-tool ini secara serius. Trace memberi tahu bahwa `charge_card` memakan 3,9 detik dan bagian yang lambat adalah panggilan ke `payment_client`. Trace tidak memberi tahu apa yang sebenarnya dilakukan `payment_client`, siapa yang menulisnya, atau kenapa ia mencoba ulang tiga kali tanpa backoff.

Untuk itu, Anda keluar dari tool observability dan membaca kode. Pada service kecil, itu memakan sepuluh menit. Di repo 100 ribu baris yang dimiliki empat tim, membaca kode sering menjadi bagian terpanjang dari sebuah insiden. Anda tahu persis span mana yang lambat, tetapi masih menghabiskan satu jam untuk memahami bagaimana kode di baliknya tersambung.

Ini adalah masalah serah terima antara data runtime dan kode sumber, dan itulah alasan kami memandang observability dan pemahaman kode sebagai dua separuh dari satu alur kerja:

- 
Observability memberi tahu **di mana** kejadiannya di runtime: service mana, span mana, tenant mana.

- 
Pemahaman kode memberi tahu **kenapa** di sumbernya: fungsi mana, kebijakan retry mana, konfigurasi mana.

Tim yang menutup lingkaran ini (nama span dipetakan ke sebuah file, file dipetakan ke pemilik dan penjelasannya) memangkas waktu antara "alert menyala" dan "perbaikan dipahami". Ini sebagian besar soal disiplin. Beri nama span sesuai nama fungsi, taruh path repo di atribut span, dan simpan catatan arsitektur singkat untuk setiap service. Asisten AI yang bisa menjawab pertanyaan tentang repo Anda, misalnya "di mana kebijakan retry untuk panggilan pembayaran diatur?", kemudian punya sesuatu yang konkret untuk dijadikan pijakan.

![Developer bekerja dengan editor kode dan dashboard metrik berdampingan](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/codebasechat/2026-10/5fe138-i3.webp)

## Tiga kesalahan yang membuat tim mengira observability tidak berhasil

**Menjadikan dashboard sebagai tujuan.** Dashboard adalah jawaban tersimpan untuk pertanyaan lama. Tim yang membangun empat puluh dashboard dan tidak pernah berlatih query ad-hoc akhirnya hanya punya monitoring dengan bungkus yang lebih bagus. Tanyakan di setiap insiden: apakah kita menjawabnya dari dashboard, atau dengan menjelajahi data mentah?

**Sampling terlalu dini, atau tidak pernah sama sekali.** Menyimpan 100% trace pada service yang sibuk cepat menjadi mahal, sedangkan menyimpan 1% secara acak membuang request gagal yang jarang tetapi justru penting bagi Anda. Tail-based sampling, yang menyimpan trace lambat dan gagal serta membuang sebagian besar trace yang sehat, adalah kompromi yang umum. Putuskan ini sebelum tagihan pertama, bukan sesudahnya.

**Membiarkan nama atribut melenceng.** Satu service menulis `user_id`, service lain `userId`, dan service ketiga `uid`. Sekarang query yang seharusnya mencakup ketiganya hanya mengembalikan sepertiga gambarannya. Sepakati konvensi penamaan kecil untuk atribut tenant, user, versi, dan flag, lalu tuliskan di repo tempat orang akan menemukannya.

Tidak satu pun dari ini adalah masalah tooling. Ini kebiasaan, dan kebiasaan lebih murah diperbaiki daripada mengganti vendor.

## Cara realistis untuk memulai tanpa mencoba membereskan semuanya

Jika hari ini Anda belum punya apa-apa, tahan dorongan untuk menginstrumentasi semuanya di minggu pertama. Urutan ini cocok untuk tim 5 sampai 50 engineer:

- 
**Pilih satu alur pengguna yang kritis.** Checkout, pendaftaran, atau panggilan API utama. Bukan seluruh sistem.

- 
**Tambahkan log terstruktur dengan request ID.** JSON, satu kejadian per baris, dengan trace atau request ID di setiap baris.

- 
**Instrumentasi alur itu dengan trace OpenTelemetry.** Sertakan atribut tenant, versi, dan flag dari contoh di atas.

- 
**Tentukan dua atau tiga service-level objective.** Misalnya, 99,5% request checkout berhasil dalam waktu di bawah 800 ms. Alert digantungkan pada itu, bukan pada CPU.

- 
**Tinjau satu insiden nyata terhadap datanya.** Apakah Anda bisa menemukan penyebabnya tanpa kode baru? Jika tidak, celah yang ditemukan itulah tugas instrumentasi Anda berikutnya.

Langkah 5 adalah yang paling sering dilewatkan, dan hanya langkah itu yang memberi tahu apakah Anda benar-benar observable. Sisanya hanyalah pekerjaan pipa.

## Apa yang akan kami lakukan

Jika tim Anda kurang dari 20 engineer, mulailah dengan instrumentasi OpenTelemetry dan backend yang harganya bisa Anda prediksi. Instrumentasinya portabel, jadi pilihan backend bisa diubah kembali. Jangan membeli platform terbesar hanya karena kompetitor melakukannya.

Jika Anda sudah membayar tool all-in-one, jangan langsung membuangnya. Audit apa yang Anda ingest, buang log yang tidak pernah di-query, dan gunakan penghematannya untuk menginstrumentasi alur yang penting.

Apa pun pilihan Anda, catat bagaimana sebuah span dipetakan kembali ke kode. Dashboard menunjukkan kebakarannya. Seseorang tetap harus membaca sumbernya untuk mengetahui kenapa api itu mulai.

## FAQ

### Apa itu observability dengan bahasa sederhana?

Observability adalah seberapa baik Anda bisa memahami apa yang terjadi di dalam sistem dari data yang dihasilkannya. Jika Anda bisa menemukan penyebab masalah yang tidak Anda prediksi, dengan memakai logs, metrics, dan traces, tanpa men-deploy kode baru, berarti sistem itu observable.

### Apa perbedaan observability dan monitoring?

Monitoring memantau masalah yang sudah diketahui dengan metrik dan ambang batas yang ditentukan sebelumnya. Observability memungkinkan Anda menyelidiki masalah yang belum diketahui dengan mengeksplorasi telemetri yang detail. Monitoring adalah lapisan alerting, sedangkan observability adalah alat untuk mencari penyebab setelah alert menyala.

### Apa tiga pilar observability?

Metrics, logs, dan traces. Metrics adalah angka dari waktu ke waktu, logs adalah catatan kejadian diskret, dan traces mengikuti satu request melintasi beberapa service. Ketiganya paling berguna jika dihubungkan dengan ID yang sama.

### Apakah saya perlu OpenTelemetry agar sistem observable?

Tidak wajib, tetapi sangat membantu. OpenTelemetry adalah standar netral vendor untuk mengeluarkan logs, metrics, dan traces. Dengan instrumentasi ini, Anda bisa mengganti backend observability nanti tanpa menginstrumentasi ulang service.

### Apakah observability hanya untuk microservices?

Tidak. Sistem terdistribusi paling diuntungkan karena satu request menyentuh banyak service, tetapi monolit dengan database, antrean, dan beberapa API pihak ketiga juga mendapat manfaat dari log dan trace yang terstruktur.

### Berapa biaya observability?

Tergantung volume data dan tool-nya. Platform hosted biasanya menagih berdasarkan pemakaian, sehingga tagihan naik seiring trafik, sedangkan stack open source menukar biaya lisensi dengan waktu engineering. Membuang log yang tidak dipakai dan melakukan sampling trace adalah dua cara paling umum untuk mengendalikan pengeluaran.