Sentry — o que é, princípios e coleta de erros

O que é Sentry no desenvolvimento

Sentry é uma plataforma de código aberto para crash reporting e monitoramento de desempenho, fundada em 2012. Ela permite que os desenvolvedores recebam notificações de erros em tempo real com contexto de diagnóstico completo: stack de chamadas, valores de variáveis no momento da falha, sequência de ações do usuário antes do erro e estado do ambiente.

Ao contrário dos serviços agregados de crash reporting (Google Play Console, App Store Connect), que fornecem apenas estatísticas e gráficos básicos, o Sentry mostra cada evento individualmente com capacidade de agrupamento por tipo de erro e filtragem por versão do aplicativo. Um Issue no Sentry é um grupo de eventos com o mesmo stack trace, permitindo que você não se afogue em milhares de crashes idênticos, mas se concentre em corrigir a causa raiz com contexto completo.

De acordo com Sentry (2025), o tempo médio de detecção de erros é reduzido de 30 minutos para 30 segundos após a implementação do Sentry SDK, e o tempo de diagnóstico é reduzido em 60% graças aos breadcrumbs automáticos e ao contexto do ambiente. A plataforma é usada por mais de 100.000 organizações em todo o mundo, incluindo Airbnb, Microsoft, Instagram e PayPal, processando bilhões de eventos diariamente.

Arquitetura do Sentry: SDK, Relay e processamento de eventos

O sistema Sentry consiste em três componentes principais: SDK no lado do aplicativo, Relay (servidor proxy) e backend de processamento de eventos. Sentry SDK é uma biblioteca incorporada ao aplicativo que intercepta exceções, coleta contexto e envia eventos para Relay via protocolo JSON/HTTPS.

Sentry Relay

Relay é um servidor intermediário que pode ser implantado na infraestrutura da empresa. Ele recebe eventos do SDK, filtra de acordo com regras (dados PII, eventos desnecessários), armazena em buffer e encaminha para o Sentry SaaS ou uma instância própria. O Relay garante baixa latência — o tempo típico de recebimento de eventos é de 500 a 1500 ms.

Filtro de dados de entrada

O Sentry fornece filtros integrados para descartar eventos indesejados antes de enviá-los ao servidor: erros de ambientes de teste, erros de versões antigas do aplicativo, eventos duplicados com a mesma impressão digital. Filtering economiza até 70% do volume de dados em um projeto de produção típico, reduzindo os custos de consumo e a carga do canal de comunicação do dispositivo.

Configuração do Sentry SDK para iOS e Android

A instalação do Sentry SDK para plataformas móveis leva de 5 a 10 minutos e requer a adição de uma dependência e inicialização com uma chave DSN. DSN (Data Source Name) é um identificador único de projeto no Sentry que indica para onde enviar os eventos.

Configuração no Android

Para Android, o Sentry fornece instrumentação automática através de um plugin Gradle. O plugin modifica o bytecode em tempo de compilação, adicionando wrappers para todas as Activities, Fragments e chamadas de rede. Auto-instrumentation é ativada com uma única opção no build.gradle e permite obter breadcrumbs do ciclo de vida do aplicativo sem alterar o código.

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

O código inicializa o Sentry SDK em um aplicativo Android. O parâmetro tracesSampleRate = 0.2 ativa o performance tracing para 20% das sessões, enableAutoSessionTracking cria automaticamente sessões para cada inicialização do aplicativo.

Configuração no iOS

O SDK para iOS suporta CocoaPods, Swift Package Manager e Carthage. Após a instalação, o SDK intercepta automaticamente NSException, sinais (SIGABRT, SIGSEGV) e erros do Swift. Sentry Cocoa SDK é compatível com iOS 12+ e macOS 10.13+, suporta Swift Concurrency (async/await) e instrumentação automática do 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
    }
}

O código em Swift ativa o Sentry SDK com coleta automática de métricas de desempenho. enableAutoPerformanceTracing ativa o monitoramento do tempo de carregamento de telas e requisições HTTP sem código adicional.

Breadcrumbs e contexto de erro

Breadcrumbs são uma sequência cronológica de eventos que precedem um erro. O Sentry registra automaticamente breadcrumbs para pressionamentos de botões, transições entre telas, requisições HTTP e notificações do sistema. O desenvolvedor pode adicionar breadcrumbs personalizados para a lógica de negócios.

Cada breadcrumb contém um timestamp, tipo de evento (navigation, http, ui, error), categoria e dados arbitrários. Quando ocorre um erro, todos os breadcrumbs dos últimos 2 a 5 minutos (configurável) são anexados ao evento. Este contexto é muitas vezes mais importante que o próprio stack trace: o desenvolvedor vê que o usuário clicou em “Pagar” após selecionar um produto, e só então ocorreu o crash. O número máximo de breadcrumbs por padrão é 200, após o qual os registros mais antigos são automaticamente removidos.

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

O código adiciona um breadcrumb personalizado para uma ação do usuário no cenário de pagamento. Se ocorrer um erro após esta ação, o desenvolvedor verá no Sentry que o usuário clicou em “Pagar” com o valor de 19.99 USD, permitindo localizar rapidamente o problema no fluxo de pagamento.

Contexto do usuário

O Sentry permite anexar informações do usuário aos eventos: ID, nome de usuário, e-mail. User context é transmitido automaticamente com todos os eventos da mesma sessão, permitindo agrupar erros por usuários e determinar quantos usuários foram afetados por um bug específico. É importante seguir a política de privacidade e não transmitir dados pessoais se a política do aplicativo não permitir.

Source maps e símbolos de depuração

Nas compilações de produção do iOS e Android, o código é geralmente minificado ou ofuscado. Sem processamento, a stack de erros conterá nomes incompreensíveis como “a.b()” em vez de “UserViewModel.fetchData()”. Source maps (JavaScript) e debug symbols (dSYM para iOS, ProGuard mapping para Android) restauram uma stack legível.

Para Android, o Sentry carrega automaticamente os arquivos ProGuard mapping através do plugin Gradle durante a compilação da versão release. Para iOS, é necessário carregar os arquivos dSYM — o Sentry fornece um script para upload automático durante o arquivamento. Sem símbolos de depuração, a stack de erros no Sentry será inútil para o desenvolvedor, portanto, o processo de upload deve ser uma etapa obrigatória no pipeline CI/CD.

Monitoramento de desempenho com Sentry

Desde a versão 2020, o Sentry inclui performance monitoring — coleta de métricas de tempo de execução de transações com distributed tracing. Uma Transaction no Sentry é uma unidade de trabalho mensurável: carregamento de tela, execução de requisição de API, processamento de tarefa em segundo plano. Cada transação contém spans filhos que mostram quais etapas específicas levaram mais tempo.

O performance monitoring no Sentry é integrado com error tracking: se uma transação termina com erro, o span correspondente é marcado com o status “error”, e o desenvolvedor pode navegar das métricas de desempenho para os detalhes da exceção. Trace ID vincula todos os eventos (erros, transações, breadcrumbs) em uma única sessão para análise de ponta a ponta, proporcionando transição perfeita entre as abas Issues e Performance em um único dashboard do Sentry.

De acordo com Sentry Performance Benchmark (2024), um aplicativo com performance monitoring ativado (taxa de amostragem de 10%) consome de 2 a 5% mais tráfego e de 1 a 2% mais recursos de CPU no dispositivo. Essa sobrecarga é compensada por uma redução de 70% no tempo de diagnóstico de desempenho em comparação com a criação de perfil manual.