Log makin banyak, jawaban makin sedikit: pelajaran survei observability 2026 untuk bisnis

Dua laporan observability yang terbit bulan ini sampai pada kesimpulan yang mirip: banyak perusahaan menyimpan data teknis jauh lebih banyak dari yang mereka pakai, dan data itu jarang ikut menentukan keputusan bisnis. Cisco merilis State of Observability 2026 pada 20 Oktober 2026, berdasarkan survei terhadap 2.050 profesional ITOps dan engineering di sepuluh negara dan enam belas industri. Grafana Labs bersama ETR menerbitkan The State of Observability, 2026 dari survei 300 pengambil keputusan IT tingkat direktur ke atas yang dilakukan Juni 2026.

Observability adalah kemampuan memahami apa yang terjadi di dalam sistem dari data yang dikeluarkannya: log, metrik, dan trace. Topik ini terdengar sangat teknis, tetapi temuannya menyentuh hal yang dekat dengan pemilik bisnis: tagihan yang terus naik, dan pertanyaan "apa yang kita dapat dari semua data ini?"

Biang biayanya bukan AI, tetapi log yang terlalu cerewet

Penulis laporan Cisco, Kamal Hathi, mengaku memperkirakan infrastruktur AI akan menjadi pendorong biaya observability terbesar. Ternyata hanya 6% responden yang menyebut AI sebagai pendorong biaya utama. Yang menduduki peringkat teratas justru log yang terlalu verbose, yaitu kebiasaan lama mengumpulkan data "untuk jaga-jaga".

Laporan Grafana menunjukkan tekanan biaya itu nyata. Sebanyak 78% responden mengatakan belanja observability naik dalam setahun terakhir, dan 73% memperkirakan naik lagi dalam 12 bulan ke depan. Alasannya beragam: produk baru yang ditambahkan ke tumpukan observability (61%), cakupan yang meluas karena pengembangan yang dipercepat AI menghasilkan lebih banyak yang perlu dipantau (60%), pertumbuhan bisnis (51%), dan kenaikan harga vendor (49%).

Hampir semua responden Grafana (97%) melihat setidaknya ada nilai dari kenaikan belanja itu. Namun 36% di antaranya mengaku belum bisa mengukur nilainya dengan jelas. Di sisi Cisco, hampir separuh responden mengakui bahwa data telemetri bukan faktor penting dalam perencanaan strategis organisasi mereka.

Gabungan dua temuan ini adalah polanya: data menumpuk, biaya naik, tetapi hubungan ke keputusan bisnis tidak dibangun.

Apa yang dilakukan kelompok "leaders" secara berbeda

Cisco memisahkan sekelompok responden berkinerja tinggi yang disebut leaders. Ada tiga kebiasaan yang mereka jalankan bersamaan: memakai agen AI secara rutin untuk memperbaiki dan mencegah masalah, memperluas observability untuk mengawasi perilaku AI (kualitas model, biaya, pemakaian, keamanan, privasi), dan memasukkan telemetri langsung ke perencanaan bisnis.

Yang menarik, mereka tidak menyimpan lebih banyak data. Mereka justru lebih disiplin. Menurut Cisco, leaders melakukan sampling dan routing data jauh lebih agresif, sehingga hanya membayar sinyal yang bernilai tinggi. Hasilnya, mereka lebih dari dua kali lebih mungkin mengatakan seluruh data observability mereka mudah diakses dan langsung bisa di-query. Mereka juga 2,4 kali lebih mungkin mengatakan ROI observability jauh melampaui ekspektasi, dan 54% melaporkan nilai bisnis tahunan minimal 5 juta dolar AS.

Soal AI, leaders lebih jujur tentang kesulitannya. Sebanyak 57% dari mereka mengatakan memantau AI menambah kompleksitas pekerjaan, dibanding 38% responden lain. Tetapi 91% sudah menetapkan dengan jelas siapa pemilik dan penanggung jawab pemantauan AI, dibanding 59% responden lain, dan 76% mengatakan bisa mengendalikan biaya AI dengan akurat.

Kepercayaan pada AI masih bertingkat

Laporan Grafana memberi gambaran batas otonomi yang realistis. Sebanyak 85% responden nyaman membiarkan AI melakukan investigasi yang hanya membaca data, dan 84% nyaman AI merekomendasikan perbaikan. Angkanya turun menjadi 56% untuk AI yang mengubah kode atau konfigurasi, 52% untuk remediasi otomatis penuh, dan 50% untuk deploy perubahan ke produksi.

Untuk aplikasi berbasis LLM, 80% organisasi responden sedang membangun atau menjalankannya, 42% sudah di produksi. Namun hanya 44% dari yang membangun atau mengujicoba aplikasi itu memantau atribusi biaya, dan atribusi biaya yang tidak jelas antarmodel dan antartim menjadi tantangan teratas (25%).

Apa artinya bagi bisnis di Indonesia

Perusahaan di Indonesia, dari e-commerce, fintech, logistik, sampai klinik dan hotel, tidak harus punya ribuan server untuk mengalami pola yang sama. Tagihan logging di cloud, langganan tool monitoring yang bertumpuk, dan dashboard yang tidak dibuka siapa pun adalah gejala yang umum. Berikut langkah praktis yang bisa dimulai tanpa membeli tool baru:

1. Mulai dari pertanyaan bisnis, bukan dari data. Tulis lima sampai sepuluh pertanyaan yang benar-benar ingin dijawab manajemen, misalnya "berapa persen pembayaran gagal di jam sibuk?" atau "berapa lama pesanan tertahan sebelum dikirim?". Data yang tidak membantu menjawab pertanyaan operasional atau bisnis patut dipertanyakan.
2. Audit volume log per layanan. Cari layanan yang paling banyak menghasilkan log dan periksa level-nya. Log debug yang terus menyala di produksi sering menjadi penyumbang besar. Turunkan level-nya, dan pindahkan log yang hanya diperlukan untuk audit ke penyimpanan yang lebih murah.
3. Terapkan sampling dengan aturan yang jelas. Dokumentasi OpenTelemetry menjelaskan bahwa untuk sistem bervolume tinggi, sampling 1% atau lebih rendah sering sudah sangat representatif. Dengan tail sampling, trace yang berisi error atau latensi tinggi tetap bisa selalu disimpan, sementara trafik sehat cukup diambil sebagian. Pastikan aturan ini tidak bertentangan dengan kewajiban retensi data yang berlaku untuk bisnis Anda.
4. Tetapkan pemilik untuk setiap dashboard dan alert. Alert tanpa pemilik cenderung diabaikan. Prinsip yang sama berlaku untuk biaya, seperti kami bahas di biaya cloud butuh pemilik.
5. Hubungkan metrik teknis ke metrik bisnis. Tampilkan latensi checkout berdampingan dengan tingkat konversi, atau waktu respons API kurir berdampingan dengan keterlambatan pengiriman. Satu dashboard bersama untuk tim teknis dan bisnis lebih berguna daripada sepuluh dashboard terpisah.
6. Ukur AI sejak hari pertama. Jika Anda menjalankan chatbot atau agen AI, catat pemakaian token, biaya per fitur atau per tim, latensi, dan kualitas jawaban. Ini sejalan dengan catatan kami soal biaya dan kendali agen AI di produksi.
7. Naikkan otonomi AI bertahap. Mulai dari AI yang hanya membaca dan merekomendasikan, lalu beri hak mengubah konfigurasi setelah ada catatan akurasi dan persetujuan manusia yang jelas.

Peran MarkasDev

MarkasDev bekerja sebagai Technology Partner, dengan tiga fase:

• Diagnose: memetakan sumber log, metrik, dan trace yang ada, biaya per sumber, dan pertanyaan bisnis yang seharusnya bisa dijawab, lalu menandai data yang mahal tetapi tidak dipakai.
• Deliver: menata pipeline telemetri, aturan sampling dan retensi, alert yang punya pemilik, serta dashboard yang menghubungkan metrik teknis dengan metrik bisnis, dengan kriteria penerimaan tertulis.
• Operate: retainer dengan SLA dan monitoring untuk menjaga aturan itu tetap relevan saat sistem berubah. Perbedaannya dengan sekadar perbaikan kami jelaskan di Maintenance vs Operate.

Jika tagihan logging dan monitoring Anda terus naik tetapi rapat manajemen masih berjalan tanpa data operasional, jadwalkan sesi Diagnose untuk memeriksa apa yang benar-benar perlu disimpan.

Sumber

• Cisco Blogs, Kamal Hathi, "State of Observability 2026 Reveals How Leaders Are Restoring Predictability to the Agentic Era" (20 Oktober 2026): https://blogs.cisco.com/news/state-of-observability-2026-reveals-how-leaders-are-restoring-predictability-to-the-agentic-era
• Grafana Labs dan ETR, "The State of Observability, 2026" (survei Juni 2026): https://grafana.com/analyst-reports/executive-survey/
• OpenTelemetry, "Sampling" (dokumentasi konsep): https://opentelemetry.io/docs/concepts/sampling/