Sentry — ano ito, mga prinsipyo at pagkolekta ng error

Ano ang Sentry sa pag-develop

Sentry ay isang open-source platform para sa crash reporting at pag-monitor ng performance, na itinatag noong 2012. Pinapayagan nito ang mga developer na makatanggap ng mga notification ng error sa real-time na may kumpletong diagnostic context: call stack, mga halaga ng variable sa oras ng pag-crash, pagkakasunod-sunod ng mga aksyon ng user bago ang error at estado ng kapaligiran.

Hindi tulad ng mga aggregated crash reporting services (Google Play Console, App Store Connect) na nagbibigay lamang ng mga istatistika at pangunahing graph, ipinapakita ng Sentry ang bawat event nang hiwalay na may kakayahang mag-grupo ayon sa uri ng error at mag-filter ayon sa bersyon ng app. Issue sa Sentry ay isang grupo ng mga event na may parehong stacktrace, na nagbibigay-daan upang hindi malunod sa libu-libong magkakaparehong crash, ngunit tumutok sa pag-aalis ng ugat na sanhi na may kumpletong konteksto.

Ayon sa Sentry (2025), ang average na oras ng pag-detect ng error ay nababawasan mula 30 minuto hanggang 30 segundo pagkatapos ng pagpapatupad ng Sentry SDK, at ang oras ng diagnosis — ng 60% salamat sa awtomatikong breadcrumbs at konteksto ng kapaligiran. Ang platform ay ginagamit ng higit sa 100,000 organisasyon sa buong mundo, kabilang ang Airbnb, Microsoft, Instagram at PayPal, na nagpoproseso ng bilyong event araw-araw.

Arkitektura ng Sentry: SDK, Relay at pagproseso ng event

Ang sistema ng Sentry ay binubuo ng tatlong pangunahing bahagi: SDK sa gilid ng app, Relay (proxy server) at backend ng pagproseso ng event. Sentry SDK ay isang library na isinasama sa app, na kumukuha ng mga exception, nangongolekta ng konteksto at nagpapadala ng mga event sa Relay sa pamamagitan ng JSON/HTTPS protocol.

Sentry Relay

Relay ay isang intermediate server na maaaring i-deploy sa imprastraktura ng kumpanya. Tumatanggap ito ng mga event mula sa SDK, nagfa-filter ayon sa mga patakaran (PII data, hindi kinakailangang event), nagbu-buffer at nagpapadala sa Sentry SaaS o sariling instance. Tinitiyak ng Relay ang mababang latency ng pagpapadala — tipikal na oras ng pagtanggap ng event ay 500–1500 ms.

Inbound Data Filter

Nagbibigay ang Sentry ng mga built-in na filter para sa pagtanggi ng mga hindi kanais-nais na event nang hindi ipinapadala ang mga ito sa server: mga error mula sa test environment, mga error mula sa lumang bersyon ng app, mga paulit-ulit na event na may parehong fingerprint. Filtering ay nakakatipid ng hanggang 70% ng dami ng data sa isang tipikal na production project, na nagpapababa ng gastos sa pagkonsumo at load sa communication channel ng device.

Pag-configure ng Sentry SDK para sa iOS at Android

Ang pag-install ng Sentry SDK para sa mobile platform ay tumatagal ng 5–10 minuto at nangangailangan ng pagdaragdag ng dependency at pagsisimula gamit ang DSN key. DSN (Data Source Name) ay ang natatanging identifier ng proyekto sa Sentry na nagpapakita kung saan ipapadala ang mga event.

Pag-configure sa Android

Para sa Android, nagbibigay ang Sentry ng awtomatikong instrumentasyon sa pamamagitan ng Gradle plugin. Binabago ng plugin ang bytecode sa yugto ng compilation, nagdaragdag ng mga wrapper para sa lahat ng Activity, Fragment at network calls. Auto-instrumentation ay naa-activate sa isang opsyon sa build.gradle at pinapayagan ang pagkuha ng breadcrumbs mula sa lifecycle ng app nang hindi binabago ang code.

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
        }
    }
}

Ang code ay nag-i-initiate ng Sentry SDK sa Android app. Ang parameter na tracesSampleRate = 0.2 ay nag-a-activate ng performance tracing para sa 20% ng mga session, enableAutoSessionTracking ay awtomatikong gumagawa ng mga session para sa bawat paglunsad ng app.

Pag-configure sa iOS

Ang SDK para sa iOS ay sumusuporta sa CocoaPods, Swift Package Manager at Carthage. Pagkatapos ng pag-install, awtomatikong kumukuha ang SDK ng NSException, mga signal (SIGABRT, SIGSEGV) at mga error sa Swift. Sentry Cocoa SDK ay compatible sa iOS 12+ at macOS 10.13+, sumusuporta sa Swift Concurrency (async/await) at awtomatikong instrumentasyon ng 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
    }
}

Ang code sa Swift ay nag-a-activate ng Sentry SDK na may awtomatikong pagkolekta ng performance metrics. enableAutoPerformanceTracing ay nag-a-activate ng pag-monitor ng oras ng pag-load ng screen at HTTP requests nang walang karagdagang code.

Breadcrumbs at konteksto ng error

Breadcrumbs ay isang kronolohikal na pagkakasunod-sunod ng mga event bago ang error. Awtomatikong nagre-record ang Sentry ng breadcrumbs para sa mga pag-click ng button, paglipat sa pagitan ng screen, HTTP requests at system notification. Ang developer ay maaaring magdagdag ng custom na breadcrumbs para sa business logic.

Ang bawat breadcrumb ay naglalaman ng timestamp, uri ng event (navigation, http, ui, error), kategorya at arbitraryong data. Kapag nangyari ang error, lahat ng breadcrumbs mula sa huling 2–5 minuto (na-configure) ay nakakabit sa event. Ang kontekstong ito ay madalas na mas mahalaga kaysa sa stacktrace mismo: nakikita ng developer na nag-click ang user ng “Magbayad” pagkatapos pumili ng produkto, at pagkatapos ay nangyari ang crash. Ang maximum na bilang ng breadcrumbs bilang default ay 200, pagkatapos nito ang mga pinakalumang record ay awtomatikong tinatanggal.

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

Ang code ay nagdaragdag ng custom na breadcrumb para sa aksyon ng user sa payment scenario. Kung pagkatapos ng aksyong ito ay may error na mangyari, makikita ng developer sa Sentry na nag-click ang user ng “Pay” na may halagang 19.99 USD, na nagbibigay-daan sa mabilis na lokalisasyon ng problema sa payment flow.

User context

Pinapayagan ng Sentry na mag-attach ng impormasyon tungkol sa user sa mga event: ID, username, email. User context ay awtomatikong naipapasa sa lahat ng event mula sa isang session, na nagbibigay-daan sa pag-grupo ng mga error ayon sa user at pagtukoy kung ilang user ang naapektuhan ng isang partikular na bug. Mahalagang sumunod sa privacy policy at huwag magpadala ng personal na data kung hindi ito pinapayagan ng patakaran ng app.

Source maps at mga simbolo ng debug

Sa production version ng iOS at Android, ang code ay karaniwang minified o obfuscated. Kung walang pagproseso, ang error stack ay maglalaman ng mga hindi maintindihang pangalan tulad ng “a.b()” sa halip na “UserViewModel.fetchData()”. Source maps (JavaScript) at debug symbols (dSYM para sa iOS, ProGuard mapping para sa Android) ay nagpapanumbalik ng nababasang stack.

Para sa Android, awtomatikong nag-u-upload ang Sentry ng ProGuard mapping file sa pamamagitan ng Gradle plugin kapag nagbu-build ng release version. Para sa iOS, kinakailangan ang pag-upload ng dSYM file — nagbibigay ang Sentry ng script para sa awtomatikong pag-upload sa yugto ng pag-archive. Kung walang debug symbols, ang error stack sa Sentry ay magiging walang silbi para sa developer, kaya ang proseso ng pag-upload ay dapat na isang mandatoryong hakbang sa CI/CD pipeline.

Pag-monitor ng performance sa pamamagitan ng Sentry

Simula sa bersyon 2020, ang Sentry ay may kasamang performance monitoring — pagkolekta ng metrics ng oras ng pag-execute ng mga transaksyon na may distributed tracing. Transaction sa Sentry ay isang nasusukat na unit ng trabaho: pag-load ng screen, pag-execute ng API request, pagproseso ng background task. Ang bawat transaksyon ay naglalaman ng child spans na nagpapakita kung aling mga hakbang ang tumagal ng pinakamaraming oras.

Ang performance monitoring sa Sentry ay integrated sa error tracking: kung ang isang transaksyon ay natapos na may error, ang kaukulang span ay minamarkahan ng status na “error”, at ang developer ay maaaring lumipat mula sa performance metric patungo sa detalye ng exception. Trace ID ay nag-uugnay sa lahat ng event (errors, transactions, breadcrumbs) sa iisang session para sa end-to-end analysis, na nagbibigay ng seamless transition sa pagitan ng Issues at Performance tab sa iisang dashboard ng Sentry platform.

Ayon sa Sentry Performance Benchmark (2024), ang app na may naka-activate na performance monitoring (sampling frequency 10%) ay kumukonsumo ng 2–5% mas maraming traffic at 1–2% mas maraming CPU resources sa device. Ang load na ito ay binabayaran ng pagbawas ng oras ng diagnosis ng performance ng 70% kumpara sa manual profiling.