Sentry — какво е, принципи и събиране на грешки

Какво е Sentry в разработката

Sentry е платформа с отворен код за докладване на сривове и мониторинг на производителността, основана през 2012 г. Тя позволява на разработчиците да получават известия за грешки в реално време с пълен диагностичен контекст: стек от извиквания, стойности на променливи в момента на срива, последователност от потребителски действия преди грешката и състояние на средата.

За разлика от агрегираните услуги за докладване на сривове (Google Play Console, App Store Connect), които предоставят само статистики и основни графики, Sentry показва всяко събитие поотделно с възможност за групиране по тип грешка и филтриране по версия на приложението. Issue в Sentry е група от събития с еднакъв stacktrace, което позволява да не се удавите в хиляди идентични сривове, а да се съсредоточите върху премахването на първопричината с пълен контекст.

По данни на Sentry (2025), средното време за откриване на грешка се намалява от 30 минути на 30 секунди след внедряване на Sentry SDK, а времето за диагностика — с 60% благодарение на автоматичните breadcrumbs и контекста на средата. Платформата се използва от повече от 100 000 организации по целия свят, включително Airbnb, Microsoft, Instagram и PayPal, обработвайки милиарди събития дневно.

Архитектура на Sentry: SDK, Relay и обработка на събития

Системата Sentry се състои от три основни компонента: SDK от страна на приложението, Relay (прокси сървър) и бекенд за обработка на събития. Sentry SDK е библиотека, вградена в приложението, която прихваща изключения, събира контекст и изпраща събития до Relay чрез протокол JSON/HTTPS.

Sentry Relay

Relay е междинен сървър, който може да бъде разгърнат в инфраструктурата на компанията. Той приема събития от SDK, филтрира според правила (PII данни, ненужни събития), буферира и препраща към Sentry SaaS или собствена инстанция. Relay осигурява ниска латентност на изпращане — типичното време за получаване на събитие е 500–1500 ms.

Inbound Data Filter

Sentry предоставя вградени филтри за отхвърляне на нежелани събития без изпращането им до сървъра: грешки от тестови среди, грешки от стари версии на приложението, повтарящи се събития с еднакъв fingerprint. Filtering спестява до 70% от обема данни в типичен продукционен проект, намалявайки разходите за потребление и натоварването на комуникационния канал на устройството.

Настройка на Sentry SDK за iOS и Android

Инсталирането на Sentry SDK за мобилни платформи отнема 5–10 минути и изисква добавяне на зависимост и инициализация с DSN ключ. DSN (Data Source Name) е уникален идентификатор на проекта в Sentry, който показва накъде да се изпращат събитията.

Настройка на Android

За Android Sentry предоставя автоматична инструментация чрез Gradle плъгин. Плъгинът модифицира байткода на етапа на компилация, добавяйки обвивки за всички Activity, Fragment и мрежови повиквания. Auto-instrumentation се включва с една опция в build.gradle и позволява получаване на breadcrumbs от жизнения цикъл на приложението без промяна на кода.

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

Кодът инициализира Sentry SDK в Android приложение. Параметърът tracesSampleRate = 0.2 включва performance tracing за 20% от сесиите, enableAutoSessionTracking автоматично създава сесии за всяко стартиране на приложението.

Настройка на iOS

SDK за iOS поддържа CocoaPods, Swift Package Manager и Carthage. След инсталиране SDK автоматично прихваща NSException, сигнали (SIGABRT, SIGSEGV) и Swift грешки. Sentry Cocoa SDK е съвместим с iOS 12+ и macOS 10.13+, поддържа Swift Concurrency (async/await) и автоматична инструментация на 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
    }
}

Кодът на Swift активира Sentry SDK с автоматично събиране на метрики за производителност. enableAutoPerformanceTracing включва мониторинг на времето за зареждане на екрани и HTTP заявки без допълнителен код.

Breadcrumbs и контекст на грешката

Breadcrumbs е хронологична последователност от събития, предхождащи грешката. Sentry автоматично записва breadcrumbs за кликвания на бутони, преходи между екрани, HTTP заявки и системни известия. Разработчикът може да добавя персонализирани breadcrumbs за бизнес логика.

Всеки breadcrumb съдържа времеви клеймо, тип събитие (navigation, http, ui, error), категория и произволни данни. При възникване на грешка всички breadcrumbs от последните 2–5 минути (конфигурируемо) се прикрепят към събитието. Този контекст често е по-важен от самия stacktrace: разработчикът вижда, че потребителят е кликнал върху „Плати“ след избор на продукт и едва тогава е настъпил сривът. Максималният брой breadcrumbs по подразбиране е 200, след което най-старите записи се изтриват автоматично.

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

Кодът добавя персонализиран breadcrumb за потребителско действие в сценарий за плащане. Ако след това действие възникне грешка, разработчикът ще види в Sentry, че потребителят е кликнал върху „Pay“ със сума 19.99 USD, което позволява бързо локализиране на проблема в потока на плащане.

User context

Sentry позволява прикрепяне на информация за потребителя към събития: ID, потребителско име, имейл. User context се предава автоматично с всички събития от една сесия, позволявайки групиране на грешки по потребители и определяне колко потребители са засегнати от конкретен бъг. Важно е да се спазва политиката за поверителност и да не се предават лични данни, ако това не е разрешено от политиката на приложението.

Source maps и символи за отстраняване на грешки

В продукционните версии на iOS и Android кодът обикновено е минифициран или объркан. Без обработка стекът на грешката ще съдържа неразбираеми имена като „a.b()“ вместо „UserViewModel.fetchData()“. Source maps (JavaScript) и debug symbols (dSYM за iOS, ProGuard mapping за Android) възстановяват четим стек.

За Android Sentry автоматично качва ProGuard mapping файлове чрез Gradle плъгина при изграждане на release версия. За iOS се изисква качване на dSYM файлове — Sentry предоставя скрипт за автоматично качване на етапа на архивиране. Без символи за отстраняване на грешки, стекът на грешката в Sentry ще бъде безполезен за разработчика, поради което процесът на тяхното качване трябва да бъде задължителна стъпка в CI/CD пайплайна.

Мониторинг на производителността чрез Sentry

От версия 2020 Sentry включва мониторинг на производителността — събиране на метрики за времето за изпълнение на транзакции с distributed tracing. Transaction в Sentry е измерима работна единица: зареждане на екран, изпълнение на API заявка, обработка на фонова задача. Всяка транзакция съдържа дъщерни span, които показват кои стъпки са отнели най-много време.

Мониторингът на производителността в Sentry е интегриран с проследяването на грешки: ако транзакция приключи с грешка, съответният span се маркира със статус „error“ и разработчикът може да премине от метриката за производителност към детайлите на изключението. Trace ID свързва всички събития (грешки, транзакции, breadcrumbs) в една сесия за цялостен анализ, осигурявайки безпроблемен преход между разделите Issues и Performance в единния табло на платформата Sentry.

По данни на Sentry Performance Benchmark (2024), приложение с включен мониторинг на производителността (честота на вземане на проби 10%) консумира 2–5% повече трафик и 1–2% повече CPU ресурси на устройството. Това натоварване се компенсира от намаляване на времето за диагностика на производителността с 70% в сравнение с ръчното профилиране.