Belajar Next.js - Observability & Monitoring

#Pendahuluan

Aplikasi yang sudah online tidak berhenti butuh perhatian. Bug muncul di production, halaman melambat untuk sebagian pengguna, dan error terjadi di perangkat yang tidak pernah kalian uji. Tanpa visibilitas, semua ini baru terasa saat pengguna mengeluh — atau pergi.

Episode 22 membahas observability: memantau performa frontend dan web vitals, logging error dengan Sentry, real user monitoring dan analytics, serta dukungan produksi dan deteksi insiden.

#Monitoring Frontend Performance dan Web Vitals

#Memantau Metrik Nyata

Web vitals dari episode 15 perlu dipantau pada pengguna nyata, bukan hanya di laptop developer. Field data berbeda dari lab data: kecepatan internet, perangkat, dan lokasi pengguna memengaruhi metrik. Sebelum memasang layanan apa pun, tentukan dulu metrik kunci — error rate, LCP, dan durasi request adalah tiga yang paling umum. Tanpa metrik kunci, dashboard penuh data tapi tidak memberi keputusan. Kirim metrik ke layanan analitik setiap kali diukur:

"use client"
 
export function reportWebVitals(metric) {
  const body = JSON.stringify({
    name: metric.name,
    value: metric.value,
    id: metric.id,
  })
 
  fetch("/api/web-vitals", {
    method: "POST",
    body,
  })
}

Fungsi reportWebVitals(metric) di atas mengirim tiap pengukuran ke route handler sendiri. Akumulasi data ini menunjukkan tren performa lintas versi aplikasi dan jenis perangkat. Jangan lupa memantau dependency eksternal: kegagalan API pihak ketiga sering kali terlihat sebagai error aplikasi — logging yang mencatat status code upstream membantu membedakan penyebabnya. Pastikan laporan metrik bisa difilter per versi dan per browser — perbedaan kecil sering menandakan masalah khusus lingkungan.

Mulai memantau sejak dini, bahkan sebelum rilis publik. Baseline yang dikumpulkan di preview environment memudahkan mendeteksi regresi saat fitur baru masuk produksi.

Pastikan metrik yang dikumpulkan memiliki tipe nilai yang konsisten lintas versi — perubahan format data metrik bisa merusak perbandingan tren.

#Memantau Server dan Edge

Di sisi server, pantau TTFB dan durasi eksekusi route. Platform deployment menyediakan log dan metrik dasar, tapi untuk gambaran lengkap, integrasikan dengan layanan observability seperti Sentry atau OpenTelemetry yang melacak performa dan error sekaligus. Tren metrik yang penting diperhatikan: peningkatan TTFB bisa menandakan masalah database atau cold start, sementara peningkatan LCP di perangkat mobile bisa menandakan bundle yang membengkak. Hubungkan metrik dengan rilis — dashboard yang menampilkan performa per versi memudahkan menemukan penyebab. Simpan log dengan masa retensi yang sesuai regulasi — log terlalu lama menambah biaya, terlalu pendek menyulitkan investigasi.

Pastikan juga log berisi konteks yang cukup: request ID, versi aplikasi, dan timestamp. Konteks ini menjadi jembatan antara log, metrik, dan trace saat investigasi insiden berlangsung.

Terapkan alert bertingkat: level warning untuk penurunan kecil yang perlu diamati, level critical untuk masalah yang langsung memengaruhi pengguna. Hierarki ini menjaga notifikasi tetap relevan dan tidak membunyikan alarm untuk hal sepele. Semua alert harus punya pemilik dan runbook singkat — alert tanpa pemilik hanyalah kebisingan.

#Logging Errors dengan Sentry

#Setup Sentry untuk Next.js

Sentry adalah platform error tracking paling populer untuk JavaScript. Sentry menangkap error di server, klien, dan edge dalam satu dashboard — ini alasan utama popularitasnya di ekosistem Next.js. Pasang SDK resminya:```bash icon="iBash" title="Install Sentry SDK" npm install --save-dev @sentry/nextjs npx @sentry/nextjs@latest wizard@latest -s

 
Perintah `npx @sentry/nextjs@latest wizard@latest -s{:bash}` mengonfigurasi project secara interaktif: membuat file `sentry.server.config.ts` dan `sentry.client.config.ts` serta menyuntikkan DSN. Setelah itu, inisialisasi di konfigurasi server:
 
```typescript icon="iTs" title="Inisialisasi Sentry di server"
import * as Sentry from "@sentry/nextjs"
 
Sentry.init({
  dsn: process.env.SENTRY_DSN,
  tracesSampleRate: 1.0,
})

tracesSampleRate: 1.0 merekam seluruh transaksi — di production, turunkan nilainya untuk mengendalikan biaya. DSN dari process.env.SENTRY_DSN diambil dari secrets, bukan dicommit. Mulai dengan nilai sampling yang rendah, lalu naikkan bertahap setelah memvalidasi biaya. Sentry juga bisa diintegrasikan dengan pipeline rilis: buat release baru saat deploy, lalu Sentry menautkan error ke versi dan commit yang menyebabkannya — ini mempercepat diagnosis dari laporan error.

#Membaca Error di Dashboard

Sentry mengumpulkan error beserta stack trace, jalur pengguna, dan konteks perangkat. Fitur unggulannya: source maps yang memetakan error production kembali ke kode sumber TypeScript, grouping error yang serupa, dan alert otomatis saat error meningkat. Ini mengubah daftar error yang tak terbaca menjadi insiden yang bisa ditindaklanjuti. Pantau juga error rate per halaman: halaman dengan error tertinggi biasanya adalah fitur yang paling perlu perbaikan cepat.

Error yang sama bisa datang dari banyak jalur: pengguna, crawler, dan bot. Segmentasi error per sumber membantu membedakan bug sungguhan dari kebisingan otomatis.

#Real User Monitoring dan Analytics

#RUM dan Product Analytics

Real User Monitoring (RUM) merekam interaksi pengguna nyata: klik, navigasi, error frontend, dan metrik kinerja. Untuk analitik produk — halaman mana yang paling banyak dilihat, dari mana pengguna datang, di mana mereka berhenti — gunakan layanan seperti Plausible, Umami, atau Google Analytics. Data ini menjawab pertanyaan bisnis sekaligus mengidentifikasi halaman yang bermasalah performanya. Mulailah dengan satu atau dua metrik kunci alih-alih memasang semua layanan sekaligus, lalu tambahkan pelacakan bertahap — halaman utama dulu, kemudian alur konversi — agar data tidak membanjiri tanpa arah. Untuk aplikasi dengan volume besar, sampling data real user masuk akal: sebagian kecil lalu lintas sudah cukup mewakili tren tanpa membebani biaya. Analitik juga membantu prioritas produk: halaman yang paling banyak dilihat layak mendapat perhatian performa paling tinggi.

#Menghormati Privasi

Saat memakai analytics, hormati privasi pengguna: berikan opsi consent untuk cookie pelacakan, anonimkan alamat IP, dan sampaikan kebijakan privasi dengan jelas. Kebijakan yang ramah privasi juga mengurangi beban regulasi seperti GDPR saat aplikasi diakses dari Eropa.

#Production Support dan Incident Detection

#Deteksi Dini dengan Alert

Observability tidak lengkap tanpa alert. Aturan yang efektif: kirim notifikasi saat error rate naik di atas ambang, saat metrik web vitals memburuk, dan saat uptime endpoint kritis menurun. Alert yang terlalu banyak membuat tim mati rasa; fokus pada insiden yang memengaruhi pengguna.

#Respons dan Umpan Balik

Ketika insiden terdeteksi: cek dashboards, baca log, identifikasi versi yang bermasalah, lalu perbaiki dan deploy. Setelah insiden, dokumentasikan apa yang terjadi, bagaimana terdeteksi, dan langkah pencegahan. Setiap insiden adalah pelajaran yang membuat sistem berikutnya lebih kuat — dan observability yang baik memastikan insiden tidak berlarut. Bentuk tim on-call sesuai skala: untuk project kecil, alert ke Slack cukup; untuk layanan penting, rotasi on-call dengan runbook memastikan insiden ditangani cepat oleh orang yang tepat.

Setelah insiden ditutup, terbitkan laporan singkat ke seluruh tim: kronologi, dampak, dan langkah pencegahan. Transparansi ini membangun kepercayaan terhadap proses dan mencegah kesalahan yang sama terulang.

#Penutup

Inti yang harus dibawa pulang:

• Pantau web vitals dari data pengguna nyata, bukan hanya di development.
• Sentry menangkap error dengan konteks dan source maps.
• DSN dan secrets disuntikkan dari environment, bukan dicommit.
• RUM dan product analytics melengkapi data performa dan bisnis.
• Hormati privasi pengguna dalam pengumpulan analytics.
• Alert fokus pada insiden yang benar-benar memengaruhi pengguna.

Di episode 23 selanjutnya — episode terakhir series ini — kita akan membahas stable modern features dan future trends: fitur stabil terbaru App Router, server components, dan streaming, strategi adopsi React Server Components secara bertahap, tren pengembangan frontend dan fullstack, serta strategi agar skill Next.js kalian selalu relevan.