Kenalan dengan Sentry

Bug lolos ke production. User mengeluh di kolom komentar. Tim engineering sibuk menebak-nebak dari mana asalnya — karena tidak ada rekaman apa yang sebenarnya terjadi di sisi user. Situasi seperti ini bisa dihindari jika ada sistem yang otomatis menangkap dan melaporkan error sebelum user sempat merasakan dampaknya.

Sentry adalah platform error tracking dan performance monitoring yang dirancang untuk menjawab kebutuhan itu. Ketika sebuah exception terjadi di aplikasi, Sentry menangkapnya lengkap dengan stack trace, data request, informasi browser, dan bahkan rekaman visual interaksi user yang memicu error tersebut. Semua konteks itu dikumpulkan dalam satu dashboard sehingga debugging tidak lagi dimulai dari nol.

Platform ini tersedia sebagai layanan cloud di sentry.io dan sebagai proyek open source yang bisa dijalankan sendiri di server. Artikel ini membahas konsep inti Sentry, fitur-fiturnya, dan cara mengintegrasikannya ke aplikasi JavaScript.

Apa yang Membedakan Sentry dari Sekadar Logger

Pendekatan konvensional untuk menangani error di production adalah dengan menulis log ke file atau mengirimnya ke layanan seperti Datadog. Pendekatan ini bekerja, tapi punya kelemahan mendasar: log hanya mencatat apa yang secara eksplisit ditulis developer. Error yang tidak diantisipasi — dan itu adalah error paling berbahaya — tidak tercatat.

Sentry bekerja di lapisan yang berbeda. SDK-nya dipasang langsung di aplikasi dan secara otomatis menangkap uncaught exception tanpa perlu menulis kode penangkap error satu per satu. Yang lebih penting, setiap error yang ditangkap dilengkapi dengan konteks penuh: siapa user yang mengalaminya, browser apa yang dipakai, URL apa yang dibuka, dan kronologi event apa yang terjadi sebelum crash — ini yang Sentry sebut sebagai breadcrumbs.

Perbedaan mendasar lainnya ada di bagaimana error dikelompokkan. Ketika seratus user mengalami error yang sama, Sentry tidak membuat seratus entri terpisah. Error tersebut dikelompokkan menjadi satu issue tunggal dengan counter berapa kali terjadi dan berapa user yang terdampak. Ini yang membuat triage prioritas menjadi jauh lebih efisien.

Ekosistem Fitur Sentry

Sentry berkembang dari tool error tracking menjadi platform observabilitas yang lebih lengkap. Ada beberapa fitur utama yang perlu dipahami sebelum mulai menggunakannya.

Error Monitoring dan Issue Tracking

Ini adalah fitur inti yang membuat Sentry dikenal. Setiap exception yang tidak tertangani secara otomatis dikirim ke dashboard sebagai sebuah issue. Stack trace yang ditampilkan bisa dipetakan ke source code asli menggunakan source maps, sehingga baris kode yang bermasalah terlihat jelas meskipun kode sudah di-minify di production.

Dari setiap issue, tersedia informasi tentang user yang terdampak, frekuensi error, dan rilis mana yang pertama kali memperkenalkan bug tersebut. Integrasi dengan GitHub atau GitLab memungkinkan Sentry menunjukkan suspect commit — commit mana yang kemungkinan besar memperkenalkan regresi.

Performance Monitoring

Sentry melacak performa setiap transaksi di aplikasi — dari request masuk hingga response keluar — dalam bentuk trace. Dari trace ini, terlihat berapa lama setiap operasi berlangsung: query database, pemanggilan API eksternal, render komponen React, dan sebagainya.

Fitur ini juga secara otomatis mendeteksi pola performa yang buruk seperti N+1 query (query database yang dipanggil berulang di dalam loop), consecutive HTTP requests yang seharusnya bisa di-batch, dan operasi lambat yang memengaruhi Core Web Vitals.

Session Replay

Session Replay adalah fitur yang merekam interaksi user seperti rekaman video — tapi bukan screen recording sesungguhnya. Sentry merekonstruksi ulang tampilan DOM berdasarkan event yang ditangkap: klik mouse, scroll, ketikan, perubahan URL, dan error yang terjadi. Hasilnya adalah video reproduksi yang bisa diputar ulang untuk melihat persis apa yang dilakukan user sebelum error terjadi.

Privacy menjadi perhatian di sini. Sentry menyediakan konfigurasi maskAllText dan blockAllMedia untuk memastikan konten sensitif seperti password atau informasi kartu kredit tidak ikut direkam.

Alerting dan Notifikasi

Sentry mendukung pengaturan alert yang fleksibel. Alert bisa dikonfigurasi untuk memicu notifikasi ketika error baru muncul, ketika frekuensi error melampaui threshold tertentu, atau ketika jumlah user yang terdampak mencapai angka yang ditentukan. Notifikasi bisa dikirim ke email, Slack, PagerDuty, atau webhook ke sistem internal.

Konsep DSN

Sebelum mengintegrasikan Sentry, penting memahami konsep DSN (Data Source Name). DSN adalah string unik yang diberikan Sentry untuk setiap proyek — ini yang memberitahu SDK ke server dan proyek mana event harus dikirim.

Strukturnya terlihat seperti URL:

https://<public_key>@<host>/project_id

Setiap proyek punya DSN sendiri. Jika aplikasi terdiri dari beberapa komponen terpisah — misalnya frontend React dan backend Node.js — praktik terbaik adalah membuat proyek terpisah di Sentry dengan DSN masing-masing. Ini memungkinkan pengelolaan error dan konfigurasi alert yang berbeda untuk setiap komponen.

Integrasi ke Aplikasi JavaScript

Ambil contoh aplikasi manajemen proyek berbasis React. Tujuannya adalah menangkap semua error yang tidak tertangani dan memantau performa halaman-halaman utama.

Instalasi SDK

Tambahkan paket Sentry ke proyek dengan perintah:

npm install @sentry/react

Untuk aplikasi Next.js, tersedia paket yang lebih spesifik:

npm install @sentry/nextjs

Inisialisasi di Entry Point Aplikasi

Inisialisasi Sentry harus dilakukan sedini mungkin dalam lifecycle aplikasi — sebelum komponen manapun dirender. Untuk React, tempat yang tepat adalah file entry point seperti main.tsx atau index.tsx.

// src/main.tsx
import * as Sentry from "@sentry/react";
import { StrictMode } from "react";
import { createRoot } from "react-dom/client";
import App from "./App";

Sentry.init({
  dsn: import.meta.env.VITE_SENTRY_DSN,
  environment: import.meta.env.MODE,
  integrations: [
    Sentry.browserTracingIntegration(),
    Sentry.replayIntegration({
      maskAllText: true,
      blockAllMedia: true,
    }),
  ],
  tracesSampleRate: 0.2,
  replaysSessionSampleRate: 0.05,
  replaysOnErrorSampleRate: 1.0,
});

createRoot(document.getElementById("root")!).render(
  <StrictMode>
    <App />
  </StrictMode>
);

Beberapa hal yang perlu diperhatikan dari konfigurasi di atas. tracesSampleRate: 0.2 berarti hanya 20% dari total transaksi yang akan dikirim ke Sentry untuk performance monitoring — angka yang lebih rendah berarti lebih sedikit data yang terkirim dan lebih hemat kuota. replaysOnErrorSampleRate: 1.0 memastikan bahwa setiap sesi yang mengalami error akan selalu direkam, sementara sesi normal hanya direkam 5%.

Menangkap Error yang Ditangani Secara Manual

Untuk error yang sudah diantisipasi dan ditangani dengan try-catch, Sentry tidak akan menangkapnya secara otomatis karena error tersebut tidak “uncaught”. Gunakan Sentry.captureException() untuk tetap melaporkannya:

// src/features/project/api/fetch-project.ts
import * as Sentry from "@sentry/react";

async function loadProjectData(projectId: string) {
  try {
    const response = await fetch(`/api/projects/${projectId}`);
    if (!response.ok) {
      throw new Error(`Gagal memuat proyek: ${response.status}`);
    }
    return response.json();
  } catch (error) {
    Sentry.captureException(error, {
      tags: { projectId },
      level: "error",
    });
    throw error;
  }
}

Properti tags di sini sangat berguna — tag memungkinkan filter error berdasarkan nilai tertentu di dashboard Sentry. Bayangkan bisa mencari semua error yang terjadi pada projectId tertentu dalam hitungan detik.

Menambahkan Konteks User

Secara default, Sentry tidak tahu siapa yang mengalami error. Setelah user login, kirimkan informasi identitasnya agar setiap error bisa dikaitkan ke user spesifik:

// src/hooks/use-auth.ts
import * as Sentry from "@sentry/react";

function useAuth() {
  function onLoginSuccess(profile: UserProfile) {
    Sentry.setUser({
      id: profile.id,
      email: profile.email,
      username: profile.username,
    });
  }

  function onLogout() {
    Sentry.setUser(null);
  }

  return { onLoginSuccess, onLogout };
}

Dengan konteks user yang terpasang, ketika ada laporan error dari user tertentu, langsung bisa dicari sesi mereka di Sentry untuk melihat rekaman Session Replay dan breadcrumbs yang relevan.

Error Boundary untuk React

React merekomendasikan penggunaan Error Boundary untuk menangkap error yang terjadi saat rendering komponen. Sentry menyediakan wrapper ErrorBoundary yang siap pakai:

// src/App.tsx
import * as Sentry from "@sentry/react";

function FallbackComponent({ error }: { error: Error }) {
  return (
    <div className="error-screen">
      <h2>Terjadi kesalahan</h2>
      <p>Tim kami sudah diberitahu. Coba muat ulang halaman.</p>
      <pre>{error.message}</pre>
    </div>
  );
}

export default function App() {
  return (
    <Sentry.ErrorBoundary fallback={FallbackComponent} showDialog>
      <RouterProvider router={appRouter} />
    </Sentry.ErrorBoundary>
  );
}

Prop showDialog akan memunculkan dialog feedback bawaan Sentry ketika error terjadi, meminta user untuk mendeskripsikan apa yang sedang mereka lakukan. Ini adalah sumber insight gratis yang sering diremehkan.

Melihat Hasil di Dashboard Sentry

Setelah SDK terpasang dan aplikasi berjalan, buka sentry.io dan navigasi ke proyek yang dibuat. Di bagian Issues, semua error yang tertangkap akan muncul dikelompokkan berdasarkan kesamaan stack trace.

Klik salah satu issue untuk melihat detailnya: stack trace lengkap, breadcrumbs yang menunjukkan kronologi event sebelum error, informasi device dan browser, serta siapa saja user yang terdampak. Jika Session Replay aktif, akan ada tombol untuk memutar rekaman sesi yang mengalami error tersebut.

Di bagian Performance, bisa dilihat distribusi latency untuk setiap halaman, transaksi paling lambat, dan apakah ada pola N+1 query yang terdeteksi secara otomatis.

Satu fitur yang layak disorot adalah Sentry Seer — asisten AI bawaan yang muncul di setiap halaman issue detail. Seer menganalisis stack trace, breadcrumbs, dan pola error serupa secara otomatis, lalu memberikan penjelasan tentang kemungkinan penyebab dan langkah-langkah yang disarankan untuk menyelesaikannya. Tidak perlu berpindah ke ChatGPT untuk paste stack trace — analisisnya sudah ada tepat di samping error.

Hal yang Perlu Diperhatikan

Ada beberapa gotcha yang sering ditemui saat pertama kali mengintegrasikan Sentry.

Sample rate di production. Jangan gunakan tracesSampleRate: 1.0 di production untuk aplikasi dengan traffic tinggi. Setiap transaksi yang di-sample memakan kuota paket berbayar. Mulai dari 0.1 atau 0.2, lalu sesuaikan berdasarkan kebutuhan.

Source maps harus di-upload. Tanpa source maps, stack trace yang tampil di Sentry akan menunjukkan baris di file hasil build yang sudah di-minify — tidak berguna untuk debugging. Proses upload source maps bisa diotomasi via Sentry CLI atau plugin bundler seperti @sentry/vite-plugin.

Environment yang terpisah. Gunakan konfigurasi environment untuk membedakan error dari development, staging, dan production. Error dari development seharusnya tidak mencemari data production dan sebaliknya.

Kesimpulan

Sentry mengubah debugging dari aktivitas reaktif yang bergantung pada laporan user menjadi proses proaktif berbasis data nyata. Dengan stack trace yang terhubung ke source code, konteks user yang lengkap, dan rekaman visual interaksi, waktu yang dihabiskan untuk mereproduksi bug bisa dipangkas drastis. Untuk ekplorasi lebih lanjut, dokumentasi Sentry Platforms menyediakan panduan spesifik untuk setiap bahasa dan framework — dari Python, Go, hingga React Native.

Referensi

1. 1Sentry Basics — Dokumentasi Resmi Sentry
2. 2Sentry JavaScript SDK — Dokumentasi Resmi Sentry
3. 3Session Replay — Sentry Product Page
4. 4Data Source Name (DSN) — Dokumentasi Resmi Sentry