Sentry — apa itu, prinsip dan pengumpulan kesalahan

Apa itu Sentry dalam pengembangan

Sentry adalah platform sumber terbuka untuk pelaporan crash dan pemantauan kinerja, didirikan pada tahun 2012. Platform ini memungkinkan pengembang menerima notifikasi kesalahan secara real-time dengan konteks diagnostik lengkap: stack panggilan, nilai variabel saat kegagalan, urutan tindakan pengguna sebelum kesalahan dan status lingkungan.

Tidak seperti layanan pelaporan crash agregat (Google Play Console, App Store Connect) yang hanya menyediakan statistik dan grafik dasar, Sentry menampilkan setiap peristiwa secara terpisah dengan kemampuan pengelompokan berdasarkan jenis kesalahan dan pemfilteran berdasarkan versi aplikasi. Issue di Sentry adalah grup peristiwa dengan stacktrace yang sama, yang memungkinkan untuk tidak tenggelam dalam ribuan crash identik, tetapi fokus pada menghilangkan akar penyebab dengan konteks lengkap.

Menurut Sentry (2025), waktu deteksi kesalahan rata-rata berkurang dari 30 menit menjadi 30 detik setelah implementasi Sentry SDK, dan waktu diagnosis — sebesar 60% berkat breadcrumbs otomatis dan konteks lingkungan. Platform ini digunakan oleh lebih dari 100.000 organisasi di seluruh dunia, termasuk Airbnb, Microsoft, Instagram dan PayPal, memproses miliaran peristiwa setiap hari.

Arsitektur Sentry: SDK, Relay dan pemrosesan peristiwa

Sistem Sentry terdiri dari tiga komponen utama: SDK di sisi aplikasi, Relay (server proxy) dan backend pemrosesan peristiwa. Sentry SDK adalah pustaka yang diintegrasikan ke dalam aplikasi, yang menangkap pengecualian, mengumpulkan konteks dan mengirim peristiwa ke Relay melalui protokol JSON/HTTPS.

Sentry Relay

Relay adalah server perantara yang dapat diterapkan di infrastruktur perusahaan. Relay menerima peristiwa dari SDK, memfilter berdasarkan aturan (data PII, peristiwa yang tidak perlu), mem-buffer dan meneruskan ke Sentry SaaS atau instance sendiri. Relay memastikan latensi pengiriman rendah — waktu penerimaan peristiwa tipikal adalah 500–1500 ms.

Inbound Data Filter

Sentry menyediakan filter bawaan untuk menolak peristiwa yang tidak diinginkan tanpa mengirimnya ke server: kesalahan dari lingkungan pengujian, kesalahan dari versi aplikasi lama, peristiwa berulang dengan fingerprint yang sama. Filtering menghemat hingga 70% volume data dalam proyek produksi tipikal, mengurangi biaya konsumsi dan beban saluran komunikasi perangkat.

Konfigurasi Sentry SDK untuk iOS dan Android

Instalasi Sentry SDK untuk platform seluler memakan waktu 5–10 menit dan memerlukan penambahan dependensi dan inisialisasi dengan kunci DSN. DSN (Data Source Name) adalah pengidentifikasi unik proyek di Sentry yang menunjukkan ke mana harus mengirim peristiwa.

Konfigurasi di Android

Untuk Android, Sentry menyediakan instrumentasi otomatis melalui plugin Gradle. Plugin memodifikasi bytecode pada tahap kompilasi, menambahkan wrapper untuk semua Activity, Fragment dan panggilan jaringan. Auto-instrumentation diaktifkan dengan satu opsi di build.gradle dan memungkinkan memperoleh breadcrumbs dari siklus hidup aplikasi tanpa mengubah kode.

import io.sentry.Sentry

class App : Application() {
    override fun onCreate() {
        super.onCreate()
        Sentry.init { options ->
            options.dsn = "https://example@sentry.io/project"
            options.tracesSampleRate = 0.2
            options.enableAutoSessionTracking = true
        }
    }
}

Kode menginisialisasi Sentry SDK di aplikasi Android. Parameter tracesSampleRate = 0.2 mengaktifkan performance tracing untuk 20% sesi, enableAutoSessionTracking secara otomatis membuat sesi untuk setiap peluncuran aplikasi.

Konfigurasi di iOS

SDK untuk iOS mendukung CocoaPods, Swift Package Manager dan Carthage. Setelah instalasi, SDK secara otomatis menangkap NSException, sinyal (SIGABRT, SIGSEGV) dan kesalahan Swift. Sentry Cocoa SDK kompatibel dengan iOS 12+ dan macOS 10.13+, mendukung Swift Concurrency (async/await) dan instrumentasi otomatis URLSession.

import Sentry

class AppDelegate: UIResponder, UIApplicationDelegate {
    func application(
        _ application: UIApplication,
        didFinishLaunchingWithOptions options: [UIApplication.LaunchOptionsKey: Any]?
    ) -> Bool {
        SentrySDK.start { options in
            options.dsn = "https://example@sentry.io/project"
            options.enableAutoPerformanceTracing = true
        }
        return true
    }
}

Kode dalam Swift mengaktifkan Sentry SDK dengan pengumpulan metrik kinerja otomatis. enableAutoPerformanceTracing mengaktifkan pemantauan waktu muat layar dan permintaan HTTP tanpa kode tambahan.

Breadcrumbs dan konteks kesalahan

Breadcrumbs adalah urutan kronologis peristiwa yang mendahului kesalahan. Sentry secara otomatis mencatat breadcrumbs untuk klik tombol, transisi antar layar, permintaan HTTP dan notifikasi sistem. Pengembang dapat menambahkan breadcrumbs kustom untuk logika bisnis.

Setiap breadcrumb berisi cap waktu, jenis peristiwa (navigation, http, ui, error), kategori dan data arbitrer. Saat terjadi kesalahan, semua breadcrumbs dari 2–5 menit terakhir (dapat dikonfigurasi) dilampirkan ke peristiwa. Konteks ini seringkali lebih penting daripada stacktrace itu sendiri: pengembang melihat bahwa pengguna mengklik “Bayar” setelah memilih produk, dan baru kemudian terjadi crash. Jumlah maksimum breadcrumb secara default adalah 200, setelah itu catatan tertua secara otomatis dihapus.

Sentry.addBreadcrumb(
    Breadcrumb().apply {
        category = "payment"
        message = "User tapped Pay button"
        type = "user"
        level = BreadcrumbLevel.INFO
        data["amount"] = "19.99"
        data["currency"] = "USD"
    }
)

Kode menambahkan breadcrumb kustom untuk tindakan pengguna dalam skenario pembayaran. Jika setelah tindakan ini terjadi kesalahan, pengembang akan melihat di Sentry bahwa pengguna mengklik “Pay” dengan jumlah 19.99 USD, yang memungkinkan lokalisasi cepat masalah di alur pembayaran.

User context

Sentry memungkinkan melampirkan informasi pengguna ke peristiwa: ID, nama pengguna, email. User context dikirimkan secara otomatis dengan semua peristiwa dari satu sesi, memungkinkan pengelompokan kesalahan berdasarkan pengguna dan menentukan berapa banyak pengguna yang terkena bug tertentu. Penting untuk mematuhi kebijakan privasi dan tidak mengirimkan data pribadi jika tidak diizinkan oleh kebijakan aplikasi.

Source maps dan simbol debug

Dalam versi produksi iOS dan Android, kode biasanya diminifikasi atau diobfuskasi. Tanpa pemrosesan, stack kesalahan akan berisi nama yang tidak dapat dipahami seperti “a.b()” alih-alih “UserViewModel.fetchData()”. Source maps (JavaScript) dan debug symbols (dSYM untuk iOS, ProGuard mapping untuk Android) memulihkan stack yang dapat dibaca.

Untuk Android, Sentry secara otomatis mengunggah file ProGuard mapping melalui plugin Gradle saat membangun versi release. Untuk iOS, diperlukan pengunggahan file dSYM — Sentry menyediakan skrip untuk pengunggahan otomatis pada tahap pengarsipan. Tanpa simbol debug, stack kesalahan di Sentry tidak akan berguna bagi pengembang, oleh karena itu proses pengunggahannya harus menjadi langkah wajib dalam pipeline CI/CD.

Pemantauan kinerja melalui Sentry

Mulai versi 2020, Sentry menyertakan pemantauan kinerja — pengumpulan metrik waktu eksekusi transaksi dengan distributed tracing. Transaction di Sentry adalah unit kerja yang dapat diukur: memuat layar, menjalankan permintaan API, memproses tugas latar belakang. Setiap transaksi berisi span anak yang menunjukkan langkah mana yang memakan waktu paling lama.

Pemantauan kinerja di Sentry terintegrasi dengan error tracking: jika transaksi berakhir dengan kesalahan, span yang sesuai ditandai dengan status “error”, dan pengembang dapat beralih dari metrik kinerja ke detail pengecualian. Trace ID menghubungkan semua peristiwa (kesalahan, transaksi, breadcrumbs) ke dalam satu sesi untuk analisis ujung-ke-ujung, menyediakan transisi mulus antara tab Issues dan Performance di dashboard tunggal platform Sentry.

Menurut Sentry Performance Benchmark (2024), aplikasi dengan pemantauan kinerja diaktifkan (frekuensi sampling 10%) mengkonsumsi 2–5% lebih banyak lalu lintas dan 1–2% lebih banyak sumber daya CPU di perangkat. Beban ini dikompensasi dengan pengurangan waktu diagnosis kinerja sebesar 70% dibandingkan dengan pembuatan profil manual.