Sentry — co to jest, zasady i zbieranie błędów

Czym jest Sentry w programowaniu

Sentry — to platforma o otwartym kodzie źródłowym do raportowania awarii i monitorowania wydajności, założona w 2012 roku. Pozwala programistom otrzymywać powiadomienia o błędach w czasie rzeczywistym z pełnym kontekstem diagnostycznym: stos wywołań, wartości zmiennych w momencie awarii, sekwencja działań użytkownika przed błędem i stan środowiska.

W przeciwieństwie do zagregowanych usług raportowania awarii (Google Play Console, App Store Connect), które dostarczają jedynie statystyki i podstawowe wykresy, Sentry pokazuje każde zdarzenie osobno z możliwością grupowania według typu błędu i filtrowania według wersji aplikacji. Issue w Sentry — to grupa zdarzeń z tym samym stack traced, co pozwala nie tonąć w tysiącach identycznych crashy, ale skupić się na usunięciu pierwotnej przyczyny z pełnym kontekstem.

Według danych Sentry (2025), średni czas wykrycia błędu skraca się z 30 minut do 30 sekund po wdrożeniu Sentry SDK, a czas diagnozy — o 60% dzięki automatic breadcrumbs i kontekstowi środowiska. Platforma jest używana przez ponad 100 000 organizacji na całym świecie, w tym Airbnb, Microsoft, Instagram i PayPal, przetwarzając miliardy zdarzeń dziennie.

Architektura Sentry: SDK, Relay i przetwarzanie zdarzeń

System Sentry składa się z trzech głównych komponentów: SDK po stronie aplikacji, Relay (serwer proxy) i backendu przetwarzania zdarzeń. Sentry SDK — to biblioteka wdrażana w aplikacji, która przechwytuje wyjątki, zbiera kontekst i wysyła zdarzenia do Relay przez protokół JSON/HTTPS.

Sentry Relay

Relay — to pośredniczący serwer, który może być wdrożony w infrastrukturze firmy. Przyjmuje zdarzenia od SDK, filtruje według reguł (dane PII, niepotrzebne zdarzenia), buforuje i przekazuje do Sentry SaaS lub własnej instancji. Relay zapewnia niskie opóźnienie wysyłki — typowy czas otrzymania zdarzenia wynosi 500–1500 ms.

Inbound Data Filter

Sentry udostępnia wbudowane filtry do odrzucania niepożądanych zdarzeń bez wysyłania ich na serwer: błędy ze środowisk testowych, błędy ze starych wersji aplikacji, powtarzające się zdarzenia z identycznym fingerprint. Filtering oszczędza do 70% objętości danych w typowym projekcie produkcyjnym, zmniejszając koszt zużycia i obciążenie kanału komunikacji urządzenia.

Konfiguracja Sentry SDK dla iOS i Android

Instalacja Sentry SDK dla platform mobilnych zajmuje 5–10 minut i wymaga dodania zależności oraz inicjalizacji z kluczem DSN. DSN (Data Source Name) — unikalny identyfikator projektu w Sentry, który wskazuje, gdzie wysyłać zdarzenia.

Konfiguracja na Android

Dla Android Sentry udostępnia automatyczną instrumentację przez wtyczkę Gradle. Wtyczka modyfikuje bytecode na etapie kompilacji, dodając otoczki dla wszystkich Activity, Fragment i wywołań sieciowych. Auto-instrumentation włącza się jedną opcją w build.gradle i pozwala otrzymywać breadcrumbs z cyklu życia aplikacji bez zmiany kodu.

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

Kod inicjalizuje Sentry SDK w aplikacji Android. Parametr tracesSampleRate = 0.2 włącza performance tracing dla 20% sesji, enableAutoSessionTracking automatycznie tworzy sesje dla każdego uruchomienia aplikacji.

Konfiguracja na iOS

SDK dla iOS obsługuje CocoaPods, Swift Package Manager i Carthage. Po instalacji SDK automatycznie przechwytuje NSException, sygnały (SIGABRT, SIGSEGV) i błędy Swift. Sentry Cocoa SDK jest kompatybilny z iOS 12+ i macOS 10.13+, obsługuje Swift Concurrency (async/await) i automatyczną instrumentację 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
    }
}

Kod w Swift aktywuje Sentry SDK z automatycznym zbieraniem metryk wydajności. enableAutoPerformanceTracing włącza monitorowanie czasu ładowania ekranów i żądań HTTP bez dodatkowego kodu.

Breadcrumbs i kontekst błędu

Breadcrumbs — to chronologiczna sekwencja zdarzeń poprzedzających błąd. Sentry automatycznie zapisuje breadcrumbs dla kliknięć przycisków, przejść między ekranami, żądań HTTP i powiadomień systemowych. Programista może dodawać niestandardowe breadcrumbs dla logiki biznesowej.

Każdy breadcrumb zawiera znacznik czasu, typ zdarzenia (navigation, http, ui, error), kategorię i dowolne dane. W przypadku wystąpienia błędu wszystkie breadcrumbs z ostatnich 2–5 minut (konfigurowalne) są dołączane do zdarzenia. Ten kontekst jest często ważniejszy niż sam stack trace: programista widzi, że użytkownik kliknął „Zapłać” po wyborze produktu, a dopiero potem nastąpił crash. Maksymalna liczba breadcrumbs domyślnie wynosi 200, po czym najstarsze wpisy są automatycznie usuwane.

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

Kod dodaje niestandardowy breadcrumb dla działania użytkownika w scenariuszu płatności. Jeśli po tym działaniu wystąpi błąd, programista zobaczy w Sentry, że użytkownik kliknął „Pay” z kwotą 19.99 USD, co pozwala szybko zlokalizować problem w flow płatności.

User context

Sentry pozwala dołączać do zdarzeń informacje o użytkowniku: ID, nazwę użytkownika, email. User context jest przekazywany automatycznie ze wszystkimi zdarzeniami z jednej sesji, umożliwiając grupowanie błędów według użytkowników i określanie, ilu użytkowników dotknął konkretny bug. Ważne jest przestrzeganie polityki prywatności i nieprzekazywanie danych osobowych, jeśli nie jest to dozwolone przez politykę aplikacji.

Source maps i symbole debugowania

W wersjach produkcyjnych iOS i Android kod jest zwykle zminimalizowany lub zaciemniony. Bez przetworzenia stack błędu będzie zawierał niezrozumiałe nazwy w rodzaju „a.b()” zamiast „UserViewModel.fetchData()”. Source maps (JavaScript) i debug symbols (dSYM dla iOS, ProGuard mapping dla Android) przywracają czytelny stack.

Dla Android Sentry automatycznie ładuje pliki ProGuard mapping przez wtyczkę Gradle podczas budowania wersji release. Dla iOS wymagane jest przesłanie plików dSYM — Sentry udostępnia skrypt do automatycznego przesyłania na etapie archiwizacji. Bez symboli debugowania stack błędu w Sentry będzie bezużyteczny dla programisty, dlatego proces ich przesyłania powinien być obowiązkowym krokiem w pipeline CI/CD.

Monitorowanie wydajności przez Sentry

Począwszy od wersji 2020, Sentry zawiera performance monitoring — zbieranie metryk czasu wykonywania transakcji z distributed tracing. Transaction w Sentry — to mierzalna jednostka pracy: ładowanie ekranu, wykonanie żądania API, przetwarzanie zadania w tle. Każda transakcja zawiera podrzędne spany, które pokazują, które kroki zajęły najwięcej czasu.

Performance monitoring w Sentry jest zintegrowany z error tracking: jeśli transakcja zakończyła się błędem, odpowiedni span jest oznaczony statusem „error”, a programista może przejść od metryki wydajności do szczegółów wyjątku. Trace ID łączy wszystkie zdarzenia (błędy, transakcje, breadcrumbs) w jedną sesję do kompleksowej analizy, zapewniając bezszwowe przejście między zakładkami Issues i Performance w jednym dashboardzie platformy Sentry.

Według danych Sentry Performance Benchmark (2024), aplikacja z włączonym performance monitoring (częstotliwość próbkowania 10%) zużywa o 2–5% więcej ruchu i o 1–2% więcej zasobów CPU na urządzeniu. To obciążenie jest kompensowane skróceniem czasu diagnozy wydajności o 70% w porównaniu z ręcznym profilowaniem.