Um frontend retorna um 500. O stack trace aponta para um componente React. O problema real está a três serviços de distância, em um pool de conexões de banco de dados esgotado por um job em background com vazamento.

Você poderia clicar através de waterfalls de trace, correlacionar timestamps e ler histórico de commits. Ou você poderia entregá-lo ao Seer do Sentry, um agent de debugging powered by LLM que lê suas traces, erros e código, e então lhe diz o que quebrou.

O Seer é bom nisso. Ele não é um vidente. A lacuna entre essas duas afirmações é sobre o que este post trata.

O que o statistical debugging realmente significa

O statistical debugging usa padrões através de muitas execuções para identificar bugs. Debuggers tradicionais lhe mostram uma execução. Abordagens estatísticas olham para distribuições: quais funções falham juntas, quais traces se correlacionam com erros, quais commits precederam um pico de crash.

O Sentry fez a parte estatística por anos. O Seer adiciona um LLM para raciocinar sobre causalidade em cima desses dados. Ele não substitui as estatísticas. Ele as interpreta.

O Seer não alucina causas raiz do nada. Ele olha para as mesmas traces e stack traces que você olharia, mas lê milhares de spans em segundos e as correlaciona com seu codebase.

Como o Seer lê uma trace sem se afogar em spans

Uma trace distribuída pode conter milhares de spans. Alimentar todos eles em uma janela de contexto de LLM é uma receita para confusão. O modelo se fixa em detalhes irrelevantes e perde o sinal.

O Sentry resolve isso construindo uma trace tree condensada. Em vez de cada span, o Seer vê uma hierarquia de transactions, os service boundaries que agrupam spans em unidades significativas. A árvore mostra quais transactions chamaram quais outras, quanto tempo levaram, e se ocorreu algum erro dentro delas.

Aqui está o que uma trace bruta se parece conceitualmente:

GET /api/checkout
├── POST /payment-service/process
│   ├── SELECT * FROM orders
│   └── UPDATE inventory
├── GET /user-service/profile
│   └── SELECT * FROM users WHERE id = ?
└── POST /notification-service/email
    └── SMTP send

O Seer recebe essa árvore anotada com timing e status de erro. Ele vê que a requisição de checkout chamou três serviços downstream. Ele não vê cada query individual de banco de dados a menos que peça por elas.

A palavra-chave é “a menos que”. O Seer tem ferramentas. Se a árvore sugere que o serviço de pagamento é o problema, ele pode buscar os spans completos dentro dessa transaction, events de erro conectados por ID, ou perfis de CPU. Ele decide o que olhar em seguida.

Essa abordagem agentic é a diferença entre “colar essa trace no ChatGPT” e o que o Seer realmente faz. Um chatbot tem uma chance só. O Seer tem um loop: observar, raciocinar, buscar mais dados, raciocinar novamente.

O problema cross-service que o Seer foi construído para resolver

Antes das traces, o Seer (então chamado Autofix) dependia de stack traces e breadcrumbs. Isso funcionava para monolitos. Falhava para sistemas distribuídos.

Considere um erro 500 no frontend. O stack trace aponta para uma chamada fetch. Sem traces, o Seer concluiria que o frontend estava quebrado. Com traces, ele vê que o frontend chamou o API gateway, que chamou o serviço de auth, que lançou um erro de validação de token porque um certificado foi rotacionado.

A própria equipe do Sentry enfrentou isso internamente. Um problema de autenticação entre o backend do Sentry e o microserviço do Seer persistiu por dias. O Seer, dada a trace tree e acesso a ambos os repositories, identificou a causa raiz e abriu pull requests em ambos os serviços.

Essa é a promessa. O problema é a configuração.

O que o Seer precisa antes de poder ajudá-lo

O Seer precisa de três coisas para funcionar bem:

1. Traces conectadas.

Se seus serviços usam projetos diferentes do Sentry sem distributed tracing, o Seer vê erros isolados, não uma trace tree. Você precisa do Sentry SDK em cada serviço e da propagação de headers de trace.

Em Python:

import sentry_sdk

sentry_sdk.init(
    dsn="https://your-dsn.ingest.sentry.io/project-id",
    traces_sample_rate=0.1,  # Adjust for your volume
)

Para propagação cross-service, o SDK lê e escreve os headers sentry-trace e baggage automaticamente em clientes HTTP suportados. Se você tem seu próprio cliente, anexe os headers manualmente:

from sentry_sdk import continue_trace

headers = {}
continue_trace(headers).apply_to_request(headers)
response = my_custom_http_client.get(
    "http:// downstream-service/api",
    headers=headers,
)

Sem isso, o Seer vê erros de frontend e backend como incidents não relacionados. A trace tree nunca se forma.

2. Código conectado.

O Seer busca no seu codebase para correlacionar traces com implementação. Isso requer a integração com GitHub e o mapeamento de repositories para projetos do Sentry. O Seer não pode ler seu código de um arquivo zip ou caminho local.

3. Sinal suficiente.

Uma trace com apenas spans HTTP auto-instrumentadas diz ao Seer que o serviço A chamou o serviço B. Ela não diz ao Seer qual lógica de negócio aconteceu no meio. Custom spans importam.

from sentry_sdk import start_span

def process_payment(order_id):
    with start_span(op="payment.process", description="Validate and charge"):
        validate_order(order_id)
        charge_customer(order_id)

Sem essas, o Seer vê uma caixa preta entre a requisição HTTP e a query de banco de dados.

As compensações que ninguém coloca no material de marketing

O Seer tem limitações reais, e o Sentry é razoavelmente honesto sobre elas.

Acurácia é alta, mas não é 100%.

O Sentry reporta uma taxa de identificação de causa raiz de 94,5%. Isso significa que aproximadamente um em cada vinte problemas é diagnosticado incorretamente. Para incidents de alta severidade, você ainda precisa de um humano para verificar a conclusão do Seer antes de deployar uma correção.

Custa dinheiro por execução.

As execuções do Seer custam aproximadamente US$ 1 por análise de causa raiz, mais uma assinatura mensal. Scans automatizados são mais baratos, a US$ 0,003 por problema. Para uma equipe que lida com dezenas de problemas diariamente, isso se acumula. Configure os thresholds de automação com cuidado.

Ele não pode corrigir o que não consegue ver.

Se suas traces são amostradas em 1% e o bug só se manifesta nos outros 99%, o Seer não vai encontrá-lo. Se a causa raiz está em um serviço de terceiros que não envia traces para o Sentry, o Seer vai bater em uma parede. Se o problema é um bug lógico que nunca lança um erro, o Seer nunca vai disparar.

LLMs ainda são ruins em alguns tipos de raciocínio.

Um estudo da Microsoft confirmou o que a maioria dos desenvolvedores suspeita: agents de IA se destacam em localizar problemas, mas lutam com análise de causa raiz quando a causa está distante do sintoma. Causalidade através do tempo, especialmente com race conditions ou corrupção de estado, continua difícil.

Quando o Seer brilha e quando ignorá-lo

O Seer vale a pena tentar quando:

  • Você tem um sistema distribuído com traces conectadas através de múltiplos serviços
  • O problema envolve um event de erro claro que o Sentry capturou
  • A causa raiz provavelmente está no seu próprio código, não em uma dependency de terceiros
  • Você tem volume de traces suficiente para que a investigação manual seja tediosa

Ignore-o quando:

  • Suas traces não estão conectadas entre serviços
  • O problema é intermitente e raramente capturado em traces
  • Você precisa de resolução sub-minuto para um incident ativo (o Seer leva minutos para executar)
  • A causa raiz é quase certamente infraestrutura, não código

Como realmente experimentá-lo

Se você já está em um plano pago do Sentry, o Seer está disponível como um trial de 14 dias.

  1. Conecte o GitHub nas configurações da sua organização no Sentry
  2. Mapeie seus repositories para seus projetos do Sentry nas configurações do Seer
  3. Certifique-se de que o tracing está habilitado em seus SDKs com traces_sample_rate configurado
  4. Abra qualquer problema e clique em Find Root Cause

Para execuções automatizadas, configure um ponto de parada. A maioria das equipes começa com Stop after Root Cause. Uma vez que você confia na acurácia, pode deixá-lo propor soluções ou rascunhar pull requests.

Se você usa Cursor ou Claude Code, pode invocar o Seer através do MCP server do Sentry diretamente no chat da sua IDE.

A conclusão honesta

O Seer pode encontrar causas raiz em traces construindo trace trees condensadas, buscando dados detalhados sob demanda, e raciocinando através do seu codebase. Para sistemas distribuídos conectados e bem instrumentados, ele é genuinamente útil. Os próprios engenheiros do Sentry economizaram dias de tempo de debugging em problemas cross-service.

Ele não é um substituto para entender seu próprio sistema. Ele é um estagiário muito rápido e muito bem lido que pode ler traces e código, mas ainda ocasionalmente culpa o serviço errado. Use-o para acelerar a investigação, não para eliminá-la.

Se suas traces estão limpas, conectadas e cheias de spans úteis, o Seer provavelmente vai impressioná-lo. Se não estiverem, corrija as traces primeiro. Nenhum LLM pode debugar o que você nunca se incomodou em instrumentar.

Perguntas frequentes

O Seer funciona com Sentry auto-hospedado? Não. O Seer é um serviço em nuvem que requer sentry.io. Ele depende da própria infraestrutura do Sentry para executar o agent de LLM e acessar sua telemetry. Instâncias auto-hospedadas não têm acesso ao Seer.

O Seer pode analisar traces de linguagens além de Python e JavaScript? Sim. O Seer lê dados de trace do Sentry, não telemetry bruta específica de linguagem. Qualquer serviço instrumentado com um Sentry SDK que produza traces pode alimentar o Seer. A etapa de análise de código requer integração com GitHub, que funciona com qualquer linguagem.

O que acontece se o Seer errar a causa raiz? Você pode fornecer feedback durante a análise, e o Seer o incorporará. A saída final sempre requer aprovação humana antes que quaisquer mudanças de código sejam aplicadas ou PRs sejam abertos. Nada é enviado automaticamente a menos que você configure explicitamente para isso.

Como isso é diferente de apenas colar um stack trace no Claude ou ChatGPT? Um chatbot recebe uma única janela de contexto com o que quer que você cole. O Seer recebe um loop agentic com acesso à sua trace tree completa, erros conectados, perfis de CPU e codebase. Ele pode buscar mais dados conforme raciocina, e conhece a estrutura do seu sistema porque lê o código real.