Sentry — vad är det, principer och felinsamling

Vad är Sentry inom utveckling

Sentry är en plattform med öppen källkod för krashrapportering och prestandaövervakning, grundad 2012. Den gör det möjligt för utvecklare att få feltmeddelanden i realtid med fullständig diagnostisk kontext: anropsstack, variabelvärden vid kraschen, sekvens av användaråtgärder före felet och miljöstatus.

Till skillnad från aggregerade krashrapporteringstjänster (Google Play Console, App Store Connect) som endast tillhandahåller statistik och grundläggande diagram, visar Sentry varje händelse separat med möjlighet att gruppera efter feltyp och filtrera efter appversion. Issue i Sentry är en grupp händelser med samma stacktrace, vilket gör att du inte drunknar i tusentals identiska krascher utan kan fokusera på att eliminera grundorsaken med fullständig kontext.

Enligt Sentry (2025) minskas den genomsnittliga feldetekteringstiden från 30 minuter till 30 sekunder efter implementering av Sentry SDK, och diagnostiden med 60% tack vare automatiska breadcrumbs och miljökontext. Plattformen används av över 100 000 organisationer världen över, inklusive Airbnb, Microsoft, Instagram och PayPal, och bearbetar miljarder händelser dagligen.

Sentrys arkitektur: SDK, Relay och händelsebearbetning

Sentrys system består av tre huvudkomponenter: SDK på appsidan, Relay (proxyserver) och backend för händelsebearbetning. Sentry SDK är ett bibliotek som integreras i appen, som fångar undantag, samlar in kontext och skickar händelser till Relay via JSON/HTTPS-protokollet.

Sentry Relay

Relay är en mellanhandsserver som kan distribueras i företagets infrastruktur. Den tar emot händelser från SDK, filtrerar enligt regler (PII-data, onödiga händelser), buffrar och vidarebefordrar till Sentry SaaS eller egen instans. Relay säkerställer låg sändningsfördröjning — typisk mottagningstid för en händelse är 500–1500 ms.

Inbound Data Filter

Sentry erbjuder inbyggda filter för att avvisa oönskade händelser utan att skicka dem till servern: fel från testmiljöer, fel från gamla appversioner, upprepade händelser med samma fingerprint. Filtering sparar upp till 70% av datavolymen i ett typiskt produktionsprojekt, vilket minskar konsumtionskostnaden och belastningen på enhetens kommunikationskanal.

Konfiguration av Sentry SDK för iOS och Android

Installation av Sentry SDK för mobilplattformar tar 5–10 minuter och kräver att ett beroende läggs till och initiering med en DSN-nyckel. DSN (Data Source Name) är den unika identifieraren för projektet i Sentry som anger vart händelser ska skickas.

Konfiguration på Android

För Android erbjuder Sentry automatisk instrumentering via Gradle-plugin. Plugin modifierar bytekoden vid kompilering och lägger till omslag för alla Activity, Fragment och nätverksanrop. Auto-instrumentation aktiveras med ett alternativ i build.gradle och gör det möjligt att få breadcrumbs från appens livscykel utan att ändra koden.

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

Koden initierar Sentry SDK i en Android-app. Parametern tracesSampleRate = 0.2 aktiverar prestandaspårning för 20% av sessionerna, enableAutoSessionTracking skapar automatiskt sessioner för varje appstart.

Konfiguration på iOS

SDK för iOS stöder CocoaPods, Swift Package Manager och Carthage. Efter installation fångar SDK automatiskt NSException, signaler (SIGABRT, SIGSEGV) och Swift-fel. Sentry Cocoa SDK är kompatibel med iOS 12+ och macOS 10.13+, stöder Swift Concurrency (async/await) och automatisk instrumentering av 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
    }
}

Koden i Swift aktiverar Sentry SDK med automatisk insamling av prestandamått. enableAutoPerformanceTracing aktiverar övervakning av skärmars laddningstid och HTTP-förfrågningar utan extra kod.

Breadcrumbs och felkontext

Breadcrumbs är en kronologisk sekvens av händelser som föregår felet. Sentry registrerar automatiskt breadcrumbs för knapptryckningar, övergångar mellan skärmar, HTTP-förfrågningar och systemmeddelanden. Utvecklaren kan lägga till anpassade breadcrumbs för affärslogik.

Varje breadcrumb innehåller en tidsstämpel, händelsetyp (navigation, http, ui, error), kategori och godtycklig data. När ett fel inträffar bifogas alla breadcrumbs från de senaste 2–5 minuterna (konfigurerbart) till händelsen. Denna kontext är ofta viktigare än själva stacktrace: utvecklaren ser att användaren klickade på "Betala" efter att ha valt en produkt och att kraschen inträffade först därefter. Det maximala antalet breadcrumbs är som standard 200, varefter de äldsta posterna automatiskt tas bort.

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

Koden lägger till en anpassad breadcrumb för en användaråtgärd i betalningsscenariot. Om ett fel inträffar efter denna åtgärd kommer utvecklaren att se i Sentry att användaren klickade på "Pay" med beloppet 19.99 USD, vilket gör det möjligt att snabbt lokalisera problemet i betalningsflödet.

User context

Sentry gör det möjligt att bifoga användarinformation till händelser: ID, användarnamn, e-post. User context skickas automatiskt med alla händelser från en session, vilket gör det möjligt att gruppera fel efter användare och avgöra hur många användare som påverkats av en specifik bugg. Det är viktigt att följa integritetspolicyn och inte överföra personuppgifter om det inte är tillåtet enligt appens policy.

Source maps och felsökningssymboler

I produktionsversioner av iOS och Android är koden vanligtvis minifierad eller obfuskerad. Utan bearbetning kommer felstacken att innehålla obegripliga namn som "a.b()" istället för "UserViewModel.fetchData()". Source maps (JavaScript) och debug symbols (dSYM för iOS, ProGuard mapping för Android) återställer läsbar stack.

För Android laddar Sentry automatiskt upp ProGuard-mappningsfiler via Gradle-plugin vid bygge av release-version. För iOS krävs uppladdning av dSYM-filer — Sentry tillhandahåller ett skript för automatisk uppladdning vid arkivering. Utan felsökningssymboler är felstacken i Sentry oanvändbar för utvecklaren, därför bör uppladdningsprocessen vara ett obligatoriskt steg i CI/CD-pipelinen.

Prestandaövervakning via Sentry

Från och med version 2020 inkluderar Sentry prestandaövervakning — insamling av tidsmått för transaktioner med distributed tracing. Transaction i Sentry är en mätbar arbetsenhet: laddning av skärm, utförande av API-förfrågan, bearbetning av bakgrundsuppgift. Varje transaktion innehåller underordnade span som visar vilka steg som tog mest tid.

Prestandaövervakning i Sentry är integrerad med felspårning: om en transaktion slutar med ett fel markeras motsvarande span med statusen "error" och utvecklaren kan gå från prestandamåttet till undantagsdetaljerna. Trace ID kopplar samman alla händelser (fel, transaktioner, breadcrumbs) i en enda session för end-to-end-analys, vilket ger sömlös övergång mellan flikarna Issues och Performance i den enhetliga instrumentpanelen för Sentry-plattformen.

Enligt Sentry Performance Benchmark (2024) förbrukar en app med aktiverad prestandaövervakning (samplingsfrekvens 10%) 2–5% mer trafik och 1–2% mer CPU-resurser på enheten. Denna belastning kompenseras av en 70% minskning av prestandadiagnostiden jämfört med manuell profilering.