Un frontend lanza un 500. El stack trace apunta a un componente de React. El problema real está a tres servicios de distancia, en un pool de conexiones a base de datos agotado por un trabajo en segundo plano con fugas.

Podrías hacer clic a través de cascadas de trazas, correlacionar marcas de tiempo y leer el historial de commits. O podrías entregárselo a Seer de Sentry, un agent de debugging impulsado por LLM que lee tus trazas, errores y código, y luego te dice qué se rompió.

Seer es bueno en esto. No es un psíquico. La brecha entre esas dos afirmaciones es de lo que trata esta publicación.

Qué significa realmente la depuración estadística

La depuración estadística usa patrones a través de muchas ejecuciones para identificar bugs exactos. Los debuggers tradicionales te muestran una ejecución. Los enfoques estadísticos miran distribuciones: qué funciones fallan juntas, qué trazas se correlacionan con errores, qué commits precedieron un pico de crashes.

Sentry ha hecho la parte estadística durante años. Seer agrega un LLM para razonar sobre la causalidad sobre esos datos. No reemplaza las estadísticas. Las interpreta.

Seer no alucina causas raíz de la nada. Mira las mismas trazas y stack traces que tú mirarías, pero lee miles de spans en segundos y las correlaciona con tu codebase.

Cómo Seer lee una traza sin ahogarse en spans

Una traza distribuida puede contener miles de spans. Alimentar todos ellos en una ventana de contexto de LLM es una receta para la confusión. El modelo se fija en detalles irrelevantes y pierde la señal.

Sentry resuelve esto construyendo un árbol de trazas condensado. En lugar de cada span, Seer ve una jerarquía de transactions, los service boundaries que agrupan spans en unidades significativas. El árbol muestra qué transactions llamaron a cuáles otras, cuánto tiempo tomaron, y si ocurrieron errores dentro de ellas.

Así es como se ve conceptualmente una traza en bruto:

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

Seer recibe este árbol anotado con tiempo y estado de error. Ve que la petición de checkout llamó a tres servicios descendentes. No ve cada query individual a la base de datos a menos que las pida.

La palabra clave es “a menos que”. Seer tiene herramientas. Si el árbol sugiere que el servicio de pagos es el problema, puede obtener los spans completos dentro de esa transaction, events de error conectados por ID, o perfiles de CPU. Decide qué mirar a continuación.

Este enfoque agentico es la diferencia entre “pegar esta traza en ChatGPT” y lo que Seer realmente hace. Un chatbot tiene una sola oportunidad. Seer tiene un bucle: observar, razonar, obtener más datos, razonar de nuevo.

El problema entre servicios que Seer fue construido para resolver

Antes de las trazas, Seer (entonces llamado Autofix) dependía de stack traces y breadcrumbs. Esto funcionaba para monolitos. Fallaba para sistemas distribuidos.

Considera un error 500 en el frontend. El stack trace apunta a una llamada fetch. Sin trazas, Seer concluiría que el frontend estaba roto. Con trazas, ve que el frontend llamó al API gateway, que llamó al servicio de autenticación, que lanzó un error de validación de token porque un certificado se rotó.

El propio equipo de Sentry enfrentó esto internamente. Un problema de autenticación entre el backend de Sentry y el microservicio de Seer había persistido durante días. Seer, dado el árbol de trazas y acceso a ambos repositories, identificó la causa raíz y abrió pull requests en ambos servicios.

Esa es la promesa. El truco es la configuración.

Qué necesita Seer antes de poder ayudarte

Seer necesita tres cosas para funcionar bien:

1. Trazas conectadas.

Si tus servicios usan diferentes proyectos de Sentry sin distributed tracing, Seer ve errores aislados, no un árbol de trazas. Necesitas el Sentry SDK en cada servicio y la propagación de headers de traza.

En 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 la propagación entre servicios, el SDK lee y escribe los headers sentry-trace y baggage automáticamente en clientes HTTP soportados. Si usas tu propio cliente, adjunta los 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,
)

Sin esto, Seer ve errores de frontend y backend como incidents no relacionados. El árbol de trazas nunca se forma.

2. Código conectado.

Seer busca en tu codebase para correlacionar trazas con implementación. Esto requiere la integración de GitHub y mapear repositories a proyectos de Sentry. Seer no puede leer tu código desde un archivo zip o una ruta local.

3. Suficiente señal.

Una traza con solo spans de HTTP auto-instrumentados le dice a Seer que el servicio A llamó al servicio B. No le dice a Seer qué lógica de negocio ocurrió en medio. Los spans personalizados importan.

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)

Sin estos, Seer ve una caja negra entre la petición HTTP y la query a la base de datos.

Las compensaciones que nadie pone en el material de marketing

Seer tiene limitaciones reales, y Sentry es razonablemente honesto sobre ellas.

La precisión es alta, pero no del 100%.

Sentry reporta una tasa de identificación de causa raíz del 94,5%. Eso significa que aproximadamente uno de cada veinte problemas es diagnosticado incorrectamente. Para incidents de alta severidad, todavía necesitas un humano que verifique la conclusión de Seer antes de desplegar una corrección.

Cuesta dinero por ejecución.

Las ejecuciones de Seer cuestan aproximadamente $1 por análisis de causa raíz, más una subscription mensual. Los escaneos automatizados son más baratos a $0,003 por problema. Para un equipo que maneja docenas de problemas diariamente, esto se acumula. Configura los umbrales de automatización cuidadosamente.

No puede corregir lo que no puede ver.

Si tus trazas se muestrean al 1% y el bug solo se manifiesta en el otro 99%, Seer no lo encontrará. Si la causa raíz está en un servicio de terceros que no envía trazas a Sentry, Seer chocará contra una pared. Si el problema es un bug lógico que nunca lanza un error, Seer nunca se activará.

Los LLMs todavía son malos en algunos tipos de razonamiento.

Un estudio de Microsoft confirmó lo que la mayoría de los desarrolladores sospechan: los agents de IA se destacan en localizar problemas pero luchan con el análisis de causa raíz cuando la causa está lejos del síntoma. La causalidad a través del tiempo, especialmente con race conditions o corrupción de estado, sigue siendo difícil.

Cuándo Seer brilla y cuándo omitirlo

Seer vale la pena probarlo cuando:

  • Tienes un sistema distribuido con trazas conectadas a través de múltiples servicios
  • El problema involucra un event de error claro que Sentry ha capturado
  • La causa raíz probablemente está en tu propio código, no en una dependencia de terceros
  • Tienes suficiente volumen de trazas como para que la investigación manual sea tediosa

Omítelo cuando:

  • Tus trazas no están conectadas entre servicios
  • El problema es intermitente y raramente se captura en las trazas
  • Necesitas resolución de menos de un minuto para un incident activo (Seer tarda minutos en ejecutarse)
  • La causa raíz es casi con seguridad infraestructura, no código

Cómo probarlo realmente

Si ya estás en un plan pagado de Sentry, Seer está disponible como una prueba de 14 días.

  1. Conecta GitHub en la configuración de tu organización de Sentry
  2. Mapea tus repositories a tus proyectos de Sentry en la configuración de Seer
  3. Asegúrate de que el tracing esté habilitado en tus SDKs con traces_sample_rate configurado
  4. Abre cualquier problema y haz clic en Find Root Cause

Para ejecuciones automatizadas, configura un punto de parada. La mayoría de los equipos comienzan con Stop after Root Cause. Una vez que confías en la precisión, puedes dejar que proponga soluciones o redacte pull requests.

Si usas Cursor o Claude Code, puedes invocar a Seer a través del MCP server de Sentry directamente en el chat de tu IDE.

La conclusión honesta

Seer puede encontrar causas raíz en trazas construyendo árboles de trazas condensados, obteniendo datos detallados bajo demanda, y razonando a través de tu codebase. Para sistemas distribuidos conectados y bien instrumentados, es genuinamente útil. Los propios ingenieros de Sentry han ahorrado días de tiempo de debugging en problemas entre servicios.

No es un reemplazo para entender tu propio sistema. Es un pasante muy rápido y muy leído que puede leer trazas y código pero todavía ocasionalmente blame al servicio equivocado. Úsalo para acelerar la investigación, no para eliminarla.

Si tus trazas están limpias, conectadas y llenas de spans útiles, Seer probablemente te impresionará. Si no lo están, corrige las trazas primero. Ningún LLM puede hacer debugging de lo que nunca te molestaste en instrumentar.

Preguntas frecuentes

¿Seer funciona con Sentry autoalojado? No. Seer es un servicio en la nube que requiere sentry.io. Depende de la infraestructura propia de Sentry para ejecutar el agent de LLM y acceder a tu telemetry. Las instancias autoalojadas no tienen acceso a Seer.

¿Seer puede analizar trazas de lenguajes distintos a Python y JavaScript? Sí. Seer lee datos de trazas de Sentry, no telemetry específica del lenguaje en bruto. Cualquier servicio instrumentado con un Sentry SDK que produzca trazas puede alimentar a Seer. El paso de análisis de código requiere la integración de GitHub, que funciona con cualquier lenguaje.

¿Qué pasa si Seer se equivoca con la causa raíz? Puedes proporcionar retroalimentación durante el análisis, y Seer la incorporará. La salida final siempre requiere aprobación humana antes de que se apliquen cambios de código o se abran PRs. Nada se envía automáticamente a menos que lo configures explícitamente para que lo haga.

¿En qué se diferencia esto de simplemente pegar un stack trace en Claude o ChatGPT? Un chatbot obtiene una sola ventana de contexto con lo que pegues. Seer obtiene un bucle agentico con acceso a tu árbol completo de trazas, errores conectados, perfiles de CPU y codebase. Puede obtener más datos a medida que razona, y conoce la estructura de tu sistema porque lee el código real.