Apa Itu Observability? Panduan Praktis untuk Tim Dev

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.

Survei Grafana 2025 terhadap 1.255 praktisi menunjukkan posisi tim saat ini. Survei observability dari Grafana 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 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.

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:

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

2. 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.

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:

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

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

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

4. 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.

5. 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.