Belajar Svelte - Observability & Monitoring

#Pendahuluan

Aplikasi berjalan mulus di mesin developer, tapi produksi adalah dunia lain: perangkat beragam, jaringan lambat, dan error muncul di tempat yang tidak terduga. Tanpa observability, kalian hanya tahu bahwa ada masalah setelah pengguna mengeluh.

Episode ini membahas pemantauan performa frontend dan error, logging masalah klien dan metrik pengguna, real user monitoring dan analytics, serta dukungan produksi dan penanganan insiden.

Setelah selesai, kalian bisa tidur nyenyak dengan aplikasi yang terpantau: error terlihat cepat, performa terukur dari pengguna nyata, dan insiden punya prosedur yang jelas.

Observability bukan sekadar alat, melainkan budaya: setiap keputusan produksi didukung oleh data yang bisa dipertanggungjawabkan.

#Memantau Performa Frontend dan Error

#Error Reporting di Produksi

Error yang terjadi di browser pengguna tidak pernah muncul di log server. Alat seperti Sentry menangkapnya beserta konteks: stack trace, perangkat, dan langkah yang memicu:

npm install -D @sentry/sveltekit
npx sentry-wizard -i sveltekit

npx sentry-wizard -i sveltekit mengonfigurasi plugin Sentry ke SvelteKit secara otomatis, termasuk setup di server dan browser.

#Error Boundaries dan Fallback

Error di load function sebaiknya ditangkap agar halaman tetap bisa ditampilkan sebagian. Tangkap dan berikan fallback yang informatif:

Tangani error di load function

export async function load({ fetch }) {
  try {
    const res = await fetch("/api/laporan")
    if (!res.ok) {
      throw new Error("HTTP " + res.status)
    }
    return { data: await res.json() }
  } catch (err) {
    console.error("Gagal memuat laporan", err)
    return { data: [], error: "Layanan sementara tidak tersedia" }
  }
}

try dan catch mengubah error tak terduga menjadi kondisi yang bisa dirender. console.error menjaga jejak di log sementara pengguna melihat pesan yang ramah.

#Logging Masalah Klien dan Metrik Pengguna

#Kapan Harus Logging di Klien

Tidak semua error pantas dilaporkan. Filter logging ke kejadian yang bermakna: error yang tidak tertangkap, promise yang gagal, dan interaksi kritis. Logging yang berlebihan membanjiri tim dengan noise dan menyembunyikan sinyal.

#Struktur Log yang Konsisten

Pakai konteks terstruktur: nama event, versi aplikasi, dan kunci pengguna yang telah dianonimisasi. Log tanpa konteks tidak bisa ditindaklanjuti.

#Real User Monitoring dan Analytics

#Mengukur Core Web Vitals

Real user monitoring mengukur performa dari perangkat pengguna sungguhan, bukan lab. Library web-vitals mengirim metrik seperti LCP dan INP:

Kirim Core Web Vitals ke endpoint

import { onCLS, onINP, onLCP } from "web-vitals"
 
function kirim(nama, nilai) {
  fetch("/api/vitals", {
    method: "POST",
    body: JSON.stringify({ nama, nilai }),
  })
}
 
onCLS((m) => kirim("CLS", m.value))
onINP((m) => kirim("INP", m.value))
onLCP((m) => kirim("LCP", m.value))

onLCP memanggil callback setiap kali metrik diukur. Data dikirim ke endpoint sendiri atau ke penyedia analytics. Metrik dari pengguna nyata menunjukkan apakah optimasi benar-benar berhasil.

#Analytics yang Menghargai Privasi

Sebelum menambahkan analytics, pikirkan data apa yang dikumpulkan dan berapa lama disimpan. Analytics harus transparan dan sesuai aturan privasi — metrik agregat biasanya cukup untuk mengambil keputusan.

#Dukungan Produksi dan Penanganan Insiden

#Siapkan Runbook

Insiden tidak bisa diprediksi, tapi bisa diantisipasi. Siapkan runbook sederhana: cara cek status, membaca log terbaru, dan memutar kembali rilis yang bermasalah. Runbook mempersingkat waktu pemulihan saat semuanya berjalan buruk.

Simpan runbook di tempat yang mudah dijangkau saat insiden — bukan di folder yang jarang dibuka. Dokumen yang tidak bisa ditemukan saat panik sama saja tidak ada.

#Setelah Insiden

Catat kronologi, akar masalah, dan langkah pencegahan. Setiap insiden adalah masukan untuk memperbaiki monitoring: jika error terjadi tanpa terdeteksi, perbaiki deteksinya lebih dulu sebelum menyalahkan kode.

#Penutup

Inti yang harus dibawa pulang:

• Error klien tidak terlihat di log server tanpa alat khusus.
• Gunakan Sentry atau sejenisnya untuk error reporting di produksi.
• Tangkap error di load function dan beri fallback yang ramah.
• Filter logging ke kejadian yang bermakna dan terstruktur.
• Ukur Core Web Vitals dari pengguna nyata dengan RUM.
• Siapkan runbook dan proses evaluasi untuk setiap insiden.

Di episode 23, episode terakhir series ini, kalian akan belajar stable modern features & future trends — fitur stabil Svelte, tren framework reaktif dan performa web, ekosistem Svelte yang meliputi SvelteKit dan Svelte Native, serta strategi menjaga skill tetap future-proof. Semua yang kalian pelajari akan dirangkum dalam penutup series.