# Apa Itu Observability? Panduan untuk Tim Platform dan SRE URL: https://upstreamapi.com/id/journal/apa-itu-observability Type: blog Locale: id Published: 2026-11-14 Updated: 2026-11-14 --- > Observability adalah kemampuan menjelaskan perilaku sistem dari telemetri yang sudah ada. Panduan ini membahas tiga sinyal, kardinalitas, biaya, dan langkah awal yang realistis bagi tim SRE. Apa itu observability? Kemampuan untuk menjelaskan mengapa sistem Anda berperilaku tidak semestinya hanya dengan telemetri yang sudah dipancarkannya, termasuk untuk kegagalan yang tidak pernah diprediksi siapa pun. Monitoring memberi tahu Anda bahwa latensi checkout sudah melewati 800 ms. Observability memungkinkan Anda bertanya tenant mana, dependensi mana, dan deploy mana yang menyebabkannya, tanpa harus mengirim kode baru jam 3 pagi hanya untuk mencari tahu. Bayangkan skenarionya. Alert menyala: p99 pada API pembayaran naik dari 180 ms menjadi 1400 ms. Dashboard CPU, memori, dan error rate semuanya hijau. Setiap panel bawaan menyatakan layanan baik-baik saja, sementara setiap pelanggan menyatakan sebaliknya. Apa yang Anda lakukan dalam sepuluh menit berikutnya adalah inti dari artikel ini. ## Mengapa definisinya penting sebelum memilih tool? Istilah ini berasal dari teori kendali: sebuah sistem dikatakan observable jika kondisi internalnya bisa disimpulkan dari output eksternalnya. Software meminjam istilah ini, lalu vendor memperluasnya sampai berarti "produk dashboard". Abaikan perluasan itu. Definisi kerja untuk tim engineering lebih sempit dan lebih berguna. Sebuah sistem observable ketika Anda bisa menjawab pertanyaan baru tentang perilakunya, di produksi, tanpa men-deploy instrumentasi baru. Kata yang penting adalah "baru". Alert dengan threshold menjawab pertanyaan yang ditulis seseorang kuartal lalu. Sistem yang observable menjawab pertanyaan yang sedang Anda ajukan sekarang. Ini bukan tes kemurnian. Tidak ada sistem yang sempurna observable, dan tujuannya bukan skor. Tujuannya adalah jalur yang lebih pendek dari "ada yang salah" menuju "perubahan ini penyebabnya". Mean time to detect dan mean time to understand adalah dua angka yang berbeda, dan kebanyakan tim hanya melacak yang pertama. ![Sketsa papan tulis berisi layanan yang saling terhubung dengan panah](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/upstreamapi/2026-11/3a5d62-i1.webp) ## Apa bedanya observability dengan monitoring? Monitoring adalah serangkaian pemeriksaan terhadap mode kegagalan yang sudah Anda kenal. CPU di atas 90 persen selama lima menit, error rate di atas 1 persen, kedalaman antrean di atas 10000. Murah, andal, dan Anda tetap membutuhkannya. Observability tidak menggantikannya. Perbedaannya terlihat ketika kegagalannya baru. Monitoring dibangun dari insiden masa lalu. Observability dibangun untuk insiden berikutnya, yang menurut definisinya belum pernah Anda lihat. Tes yang berguna: lihat tiga insiden terakhir dan tanyakan bagaimana akar masalahnya ditemukan. - Jika seseorang membaca dashboard bawaan dan jawabannya ada di sana, itu berarti monitoring bekerja dengan baik. - Jika seseorang menelusuri log di enam host, menebak hipotesis, lalu menambah baris log dan men-deploy ulang untuk memastikan, itu adalah celah observability. - Jika jawaban sebenarnya datang dari screenshot pelanggan, Anda punya kedua masalah sekaligus. Tidak perlu memperdebatkan apakah keduanya saling bersaing. Keduanya adalah lapisan. Monitoring adalah detektor asap. Observability adalah kemampuan menelusuri gedung setelah kejadian dan mencari tahu sirkuit mana yang memulai kebakaran. ## Apa saja tiga sinyalnya, dan di mana masing-masing gagal? Logs, metrics, dan traces adalah trio standar. Masing-masing menjawab pertanyaan yang berbeda, dan masing-masing punya mode kegagalan yang sering dilewatkan oleh panduan vendor. **Metrics** adalah pengukuran numerik yang diagregasi dari waktu ke waktu: request rate, error rate, persentil latensi, dan saturasi. Metrics murah disimpan dan cepat di-query, sebab itu alerting dibangun di atasnya. Mode kegagalannya adalah agregasi. p99 sebesar 1400 ms memberi tahu Anda bahwa ada yang lambat. Metric itu tidak bisa memberi tahu bahwa setiap request yang lambat berasal dari satu pelanggan di satu shard. **Logs** adalah catatan kejadian diskret yang diberi stempel waktu. Detailnya paling kaya, tetapi strukturnya paling sedikit kecuali Anda memaksakan struktur sejak awal. Mode kegagalannya adalah volume dan biaya. Log tanpa struktur hanya bisa dicari oleh orang yang sudah tahu string apa yang harus dicari, sehingga ia menjadi alat monitoring yang menyamar sebagai alat debugging. **Traces** mengikuti satu request melintasi batas layanan, dengan span untuk setiap hop beserta waktunya. Hanya sinyal ini yang memperlihatkan bentuk sebuah request: panggilan ini menunggu 900 ms pada dependensi hilir yang di-retry tiga kali. Mode kegagalannya adalah cakupan. Satu layanan yang menjatuhkan trace context akan memutus rantai, dan trace yang bolong lebih menyesatkan daripada tidak ada trace sama sekali, karena terlihat seolah-olah lengkap. Memiliki ketiganya belum sama dengan observable. Intinya ada pada korelasi. Anda harus bisa berpindah dari lonjakan metric ke trace yang berkontribusi terhadapnya, dan dari trace ke log untuk request persis itu. Jika ketiganya berada di tool terpisah tanpa identifier bersama, Anda hanya punya tiga sistem monitoring dan seorang engineer yang bertindak sebagai penghubung. ## Mengapa kardinalitas menentukan apakah Anda bisa melakukan debugging? Kardinalitas adalah jumlah nilai berbeda yang bisa diambil sebuah field. `status_code` mungkin hanya punya sekitar dua puluh nilai. `customer_id` bisa punya ratusan ribu. `request_id` punya satu nilai per request. Field yang paling Anda butuhkan saat insiden justru yang berkardinalitas tinggi. "Pelanggan mana yang terdampak" adalah pertanyaan `customer_id`. "Build mana yang melayani request lambat" adalah pertanyaan `deploy_version`. Jika model penyimpanan Anda menghukum field berkardinalitas tinggi, baik dengan menagihnya per series unik maupun dengan diam-diam membuangnya, Anda tidak akan bisa mengajukan pertanyaan yang memecahkan insiden. Inilah garis arsitektur yang sebenarnya antara setup yang hanya berbasis metric dan setup yang observable. Metric yang sudah diagregasi membuang dimensi yang nanti ingin Anda gunakan. Event terstruktur yang lebar menyimpannya, dan Anda memotongnya setelah kejadian. Berikut contoh event yang berguna di tepi sebuah layanan. Satu record terstruktur per request, dengan konteks yang cukup untuk dipotong menurut apa pun yang nanti Anda pedulikan: `logger.info("request.completed", { trace_id: span.traceId, route: "/v1/payments", customer_id: ctx.customerId, deploy_version: process.env.BUILD_SHA, flag_variant: flags.get("new-ledger-path"), db_ms: timings.db, upstream_ms: timings.upstream, status: res.statusCode, duration_ms: elapsed, });`Perhatikan flag variant di dalamnya. Separuh insiden dalam post-mortem yang dipublikasikan bermula dari sebuah perubahan, dan evaluasi flag adalah sebuah perubahan. Jika variant tidak ada di event, Anda tidak bisa bertanya apakah request yang lambat adalah request yang berada di jalur baru. ![Meja kerja dengan laptop yang menampilkan dashboard latensi](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/upstreamapi/2026-11/c95a59-i2.webp) ## Seperti apa insiden dengan dan tanpa observability? Ambil lagi skenario pembayaran tadi. Alert yang sama, p99 1400 ms yang sama. Tanpa observability, lingkarannya begini: buka dashboard layanan, tidak menemukan apa-apa, buka dashboard database, tidak menemukan apa-apa, lalu tanya di kanal insiden apakah ada yang baru di-deploy. Seseorang ingat ada perubahan konfigurasi. Orang lain tidak setuju. Empat puluh menit kemudian Anda me-revert deploy terakhir untuk melihat apakah itu membantu. Ternyata tidak, karena penyebabnya adalah rollout flag ke sebagian tenant. Dengan observability, lingkarannya begini: kelompokkan request lambat menurut `flag_variant` dan lihat bahwa 100 persen berada di `new-ledger-path`. Kelompokkan menurut `customer_id` dan lihat bahwa tiga tenant besar menyumbang sebagian besar volume. Buka satu trace dan lihat panggilan ledger bercabang menjadi 40 query berurutan. Total waktunya: beberapa menit. Anda mematikan flag, bukan men-deploy ulang. Perhatikan apa yang tidak dibutuhkan lingkaran kedua. Ia tidak membutuhkan dashboard yang sudah disiapkan. Ia tidak membutuhkan seseorang yang memprediksi sebelumnya bahwa "flag variant" adalah dimensi yang menarik. Yang dibutuhkan hanyalah data yang sudah tersedia, lebar, dan bisa di-query. Itulah argumen Honeycomb dalam satu paragraf, dan argumen itu bertahan. Yang tidak dikatakannya adalah bahwa ini gratis. ## Berapa biayanya, dan siapa yang sebaiknya melewatkan versi yang mahal? Telemetri adalah masalah volume data sebelum menjadi masalah tooling. Menurut [survei observability 2025 Grafana Labs terhadap 1255 praktisi](https://grafana.com/blog/2025/03/25/observability-survey-takeaways), rata-rata organisasi menjalankan delapan tool observability yang berbeda, dan biaya adalah kriteria yang paling sering disebut saat memilih tool baru. Kedua fakta ini saling terkait. Tim menumpuk tool karena tiap tool menyelesaikan satu bagian, lalu membayar ingestion yang tumpang tindih di semuanya. Aturan praktis yang berlaku untuk sebagian besar ukuran tim: - **Instrumentasi dengan OpenTelemetry, bukan agent proprietary.** Collector memberi Anda satu tempat untuk sampling, filtering, dan routing. Mengganti backend menjadi perubahan konfigurasi, bukan proyek instrumentasi ulang. - **Lakukan sampling trace dengan sengaja.** Simpan setiap error dan setiap request lambat, lalu sampling request sehat yang cepat. Head-based sampling flat 1 persen akan membuang tepat trace yang Anda butuhkan. - **Berikan struktur pada log saat ditulis.** Mem-parsing teks bebas saat query adalah cara termahal untuk mendapatkan field. - **Tetapkan kebijakan retensi per sinyal.** Metric selama satu tahun, event lebar selama dua minggu, dan log debug selama tiga hari. Tidak ada yang pernah membutuhkan log debug kuartal lalu. Lewati pendekatan platform penuh jika Anda hanya menjalankan segelintir layanan dan satu rotasi on-call. Tim kecil mendapat sebagian besar manfaat dari log terstruktur, metric RED, dan trace pada dua atau tiga jalur utama. Kontrak mahal yang serba bisa baru terbayar ketika jumlah layanan sudah sedemikian banyak sehingga tidak ada orang yang memegang seluruh topologinya di kepala. Menurut pengalaman kami, itu terjadi setelah sekitar 30 sampai 40 layanan. ## Tool apa saja yang layak dilihat? Pilihan tool bergantung pada seberapa banyak yang ingin Anda jalankan sendiri, seperti apa kardinalitas Anda, dan berapa tagihan yang sanggup Anda tanggung. Berikut tur singkat yang beropini: Datadog adalah opsi komersial paling luas: metric, log, trace, dan profiling di bawah satu atap, dengan korelasi yang kuat di antara keduanya. Harga integrasi itu adalah tagihan yang naik mengikuti jumlah host, custom metric, dan volume log yang masuk. Layak dipertimbangkan jika Anda ingin satu vendor dan anggarannya memadai. Periksa baris custom metric sebelum berkomitmen. Grafana adalah pilihan default ketika Anda menginginkan komponen terbuka yang bisa di-self-host atau dibeli sebagai stack terkelola. Ia cocok dengan metric bergaya Prometheus dan pipeline OpenTelemetry. Trade-off-nya bersifat operasional: Anda memiliki lebih banyak bagian dari perakitannya, dan angka sprawl dari survei di atas juga berlaku untuk Anda. SigNoz adalah opsi open source yang native OpenTelemetry, dengan log, metric, dan trace dalam satu datastore. Itu penting untuk poin korelasi tadi, karena datastore bersama membuat lompatan dari metric ke trace ke log menjadi sebuah query, bukan perpindahan tab. Cocok untuk tim yang ingin self-host tanpa harus merangkai empat proyek. Better Stack menggabungkan uptime monitoring, alerting insiden, dan manajemen log dengan harga yang ditujukan untuk tim kecil. Ini langkah pertama yang masuk akal jika Anda berpindah dari "kami tahu dari pelanggan" menuju sesuatu yang terstruktur. Kurang cocok untuk service mesh besar dengan kebutuhan trace yang berat. ![Lorong pusat data dengan lampu status](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/upstreamapi/2026-11/63d34b-i3.webp) ## Bagaimana memulai tanpa membuang energi berlebihan? Jangan mulai dengan evaluasi tool. Mulailah dari tiga insiden terakhir dan satu pertanyaan jujur: apa yang kami harap bisa kami tanyakan? Urutan berikut berhasil untuk tim berisi 50 sampai 200 engineer: - **Pilih satu jalur request kritis** dan instrumentasi dari ujung ke ujung dengan OpenTelemetry. Checkout, login, atau apa pun yang membangunkan Anda jam 3 pagi. - **Kirim satu event terstruktur lebar per request** di tepi layanan, dengan pelanggan, versi, variant flag, dan waktu downstream. - **Tetapkan satu SLO pada jalur itu** dan buat alert berdasarkan burn rate, bukan threshold mentah. Alert burn rate membangunkan Anda karena dampaknya ke pengguna, dan telemetri dari langkah 2 memberi tahu mengapa. - **Jalankan game day.** Injeksikan kegagalan yang belum Anda beri alert, lalu lihat berapa lama seseorang yang tidak menulis kode itu membutuhkan waktu untuk menemukannya. Angka itu menjadi baseline Anda. - **Perluas satu jalur demi satu jalur**, dan hanya setelah jalur pertama terbukti berguna dalam insiden nyata. Observability dibeli sebagai platform dan diadopsi sebagai kebiasaan. Kebiasaannya adalah bertanya "apa yang perlu saya ketahui untuk menjelaskan ini?" saat code review, sebelum insiden, bukan selama insiden. Buka tinjauan insiden terakhir Anda. Cari kalimat yang berbunyi "lalu kami menambahkan logging untuk memastikan". Setiap kalimat seperti itu adalah pertanyaan yang tidak bisa dijawab sistem Anda di produksi. Berapa banyak yang tersimpan di arsip Anda, dan berapa di antaranya yang masih tidak bisa dijawab hari ini? ## FAQ ### Apa itu observability dalam satu kalimat? Observability adalah kemampuan menjawab pertanyaan baru tentang perilaku sistem di produksi menggunakan telemetri yang sudah ada, tanpa men-deploy instrumentasi baru. ### Apa bedanya observability dan monitoring? Monitoring memeriksa mode kegagalan yang sudah dikenal dengan alert dan threshold. Observability membantu menemukan penyebab kegagalan yang belum pernah terjadi sebelumnya. ### Apa tiga sinyal utama observability? Tiga sinyal utamanya adalah metrics untuk tren dan alerting, logs untuk catatan kejadian detail, dan traces untuk melihat perjalanan satu request lintas layanan. ### Mengapa kardinalitas penting dalam observability? Field berkardinalitas tinggi seperti customer_id atau deploy_version sering dibutuhkan saat insiden. Jika storage membuangnya atau menagihnya mahal, pertanyaan untuk menemukan penyebab tidak bisa dijawab. ### Apakah observability selalu mahal? Tidak harus. Dengan OpenTelemetry, sampling trace yang disengaja, log terstruktur, dan retensi per sinyal, biaya bisa dikendalikan. Tim kecil sering cukup dengan pendekatan yang lebih sederhana.