Un frontend lève une 500. La stack trace pointe vers un composant React. Le vrai problème est à trois services de distance, dans un pool de connexions à base de données épuisé par un job en arrière-plan qui fuit.

Vous pourriez cliquer à travers des waterfalls de traces, corréler des horodatages, et lire l’historique des commits. Ou vous pourriez le confier à Seer de Sentry, un agent de débogage propulsé par LLM qui lit vos traces, erreurs, et code, puis vous dit ce qui a cassé.

Seer est bon pour ça. Ce n’est pas un médium. L’écart entre ces deux affirmations est le sujet de cet article.

Ce que signifie réellement le statistical debugging

Le statistical debugging utilise des patterns à travers de nombreuses exécutions pour localiser les bugs. Les débogueurs traditionnels vous montrent une exécution. Les approches statistiques regardent les distributions : quelles fonctions échouent ensemble, quelles traces corrèlent avec des erreurs, quels commits ont précédé un pic de crashes.

Sentry fait la partie statistique depuis des années. Seer ajoute un LLM pour raisonner sur la causalité au-dessus de ces données. Il ne remplace pas les statistiques. Il les interprète.

Seer n’hallucine pas de causes racines à partir de rien. Il regarde les mêmes traces et stack traces que vous regarderiez, mais il lit des milliers de spans en quelques secondes et les corrèle avec votre codebase.

Comment Seer lit une trace sans se noyer dans les spans

Une trace distribuée peut contenir des milliers de spans. Tout les injecter dans une fenêtre de contexte LLM est une recette pour la confusion. Le modèle se fixe sur des détails non pertinents et manque le signal.

Sentry résout cela en construisant un arbre de trace condensé. Au lieu de chaque span, Seer voit une hiérarchie de transactions, les service boundaries qui regroupent les spans en unités significatives. L’arbre montre quelles transactions ont appelé lesquelles, combien de temps elles ont pris, et si des erreurs se sont produites à l’intérieur.

Voici à quoi ressemble conceptuellement une trace brute :

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 reçoit cet arbre annoté avec les timings et le statut d’erreur. Il voit que la requête de checkout a appelé trois services en aval. Il ne voit pas chaque requête de base de données individuelle à moins qu’il ne les demande.

Le mot clé est « à moins que ». Seer a des outils. Si l’arbre suggère que le service de paiement est le problème, il peut récupérer les spans complètes à l’intérieur de cette transaction, les événements d’erreur connectés par ID, ou les profils CPU. Il décide quoi regarder ensuite.

Cette approche agentique est la différence entre « collez cette trace dans ChatGPT » et ce que Seer fait réellement. Un chatbot a une seule chance. Seer a une boucle : observer, raisonner, récupérer plus de données, raisonner à nouveau.

Le problème inter-services que Seer a été conçu pour résoudre

Avant les traces, Seer (alors appelé Autofix) s’appuyait sur les stack traces et les breadcrumbs. Cela fonctionnait pour les monolithes. Cela échouait pour les systèmes distribués.

Considérez une erreur 500 frontend. La stack trace pointe vers un appel fetch. Sans traces, Seer conclurait que le frontend était cassé. Avec des traces, il voit que le frontend a appelé la passerelle API, qui a appelé le service d’authentification, qui a levé une erreur de validation de token parce qu’un certificat a tourné.

L’équipe de Sentry elle-même a rencontré ce problème en interne. Un problème d’authentification entre le backend de Sentry et le microservice de Seer persistait depuis des jours. Seer, avec l’arbre de trace et l’accès aux deux repositories, a identifié la cause racine et ouvert des pull requests dans les deux services.

C’est la promesse. Le hic, c’est la mise en place.

Ce dont Seer a besoin avant de pouvoir vous aider

Seer a besoin de trois choses pour bien fonctionner :

1. Des traces connectées.

Si vos services utilisent différents projets Sentry sans distributed tracing, Seer voit des erreurs isolées, pas un arbre de trace. Vous avez besoin du SDK Sentry dans chaque service et de la propagation des en-têtes de trace.

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
)

Pour la propagation inter-services, le SDK lit et écrit automatiquement les en-têtes sentry-trace et baggage sur les clients HTTP supportés. Si vous utilisez votre propre client, attachez les en-têtes manuellement :

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,
)

Sans cela, Seer voit les erreurs frontend et backend comme des incidents non liés. L’arbre de trace ne se forme jamais.

2. Du code connecté.

Seer recherche dans votre codebase pour corréler les traces avec l’implémentation. Cela nécessite l’intégration GitHub et le mapping des repositories aux projets Sentry. Seer ne peut pas lire votre code à partir d’un fichier zip ou d’un chemin local.

3. Assez de signal.

Une trace avec seulement des spans HTTP auto-instrumentées dit à Seer que le service A a appelé le service B. Cela ne dit pas à Seer quelle logique métier s’est passée entre les deux. Les spans personnalisées comptent.

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)

Sans celles-ci, Seer voit une boîte noire entre la requête HTTP et la requête de base de données.

Les compromis que personne ne met dans le marketing

Seer a de vraies limitations, et Sentry est raisonnablement honnête à leur sujet.

La précision est élevée, mais pas de 100 %.

Sentry rapporte un taux d’identification de cause racine de 94,5 %. Cela signifie qu’environ un incident sur vingt est mal diagnostiqué. Pour les incidents de haute sévérité, vous avez toujours besoin d’un humain pour vérifier la conclusion de Seer avant de déployer un correctif.

Ça coûte de l’argent par exécution.

Les exécutions de Seer coûtent environ 1 $ par analyse de cause racine, plus un abonnement mensuel. Les scans automatisés sont moins chers à 0,003 $ par issue. Pour une équipe gérant des dizaines d’issues quotidiennement, cela s’accumule. Configurez soigneusement les seuils d’automatisation.

Il ne peut pas réparer ce qu’il ne voit pas.

Si vos traces sont échantillonnées à 1 % et que le bug ne se manifeste que dans les 99 % restants, Seer ne le trouvera pas. Si la cause racine est dans un service tiers qui n’envoie pas de traces à Sentry, Seer heurtera un mur. Si le problème est un bug logique qui ne lève jamais d’erreur, Seer ne se déclenchera jamais.

Les LLM sont toujours mauvais pour certains types de raisonnement.

Une étude de Microsoft a confirmé ce que la plupart des développeurs soupçonnent : les agents AI excellent pour localiser les problèmes mais peinent avec l’analyse de cause racine quand la cause est éloignée du symptôme. La causalité à travers le temps, surtout avec les race conditions ou la corruption d’état, reste difficile.

Quand Seer brille et quand l’éviter

Seer vaut la peine d’être essayé quand :

  • Vous avez un système distribué avec des traces connectées à travers plusieurs services
  • Le problème implique un événement d’erreur clair que Sentry a capturé
  • La cause racine est probablement dans votre propre code, pas dans une dépendance tierce
  • Vous avez assez de volume de traces pour que l’investigation manuelle soit fastidieuse

Évitez-le quand :

  • Vos traces ne sont pas connectées entre les services
  • Le problème est intermittent et rarement capturé dans les traces
  • Vous avez besoin d’une résolution sous la minute pour un incident actif (Seer prend des minutes à s’exécuter)
  • La cause racine est presque certainement de l’infrastructure, pas du code

Comment l’essayer concrètement

Si vous êtes déjà sur un plan Sentry payant, Seer est disponible sous forme d’essai de 14 jours.

  1. Connectez GitHub dans les paramètres de votre organisation Sentry
  2. Mappez vos repositories à vos projets Sentry dans les paramètres de Seer
  3. Assurez-vous que le tracing est activé dans vos SDKs avec traces_sample_rate défini
  4. Ouvrez n’importe quelle issue et cliquez sur Find Root Cause

Pour les exécutions automatisées, configurez un point d’arrêt. La plupart des équipes commencent avec Stop after Root Cause. Une fois que vous faites confiance à la précision, vous pouvez lui laisser proposer des solutions ou rédiger des pull requests.

Si vous utilisez Cursor ou Claude Code, vous pouvez invoquer Seer via le MCP server de Sentry directement dans le chat de votre IDE.

La conclusion honnête

Seer peut trouver des causes racines dans les traces en construisant des arbres de traces condensés, en récupérant des données détaillées à la demande, et en raisonnant à travers votre codebase. Pour les systèmes distribués bien connectés et bien instrumentés, c’est réellement utile. Les propres ingénieurs de Sentry ont économisé des jours de temps de débogage sur des problèmes inter-services.

Ce n’est pas un remplacement pour comprendre votre propre système. C’est un stagiaire très rapide et très cultivé qui peut lire des traces et du code mais qui blâme encore occasionnellement le mauvais service. Utilisez-le pour accélérer l’investigation, pas pour l’éliminer.

Si vos traces sont propres, connectées, et pleines de spans utiles, Seer vous impressionnera probablement. Si ce n’est pas le cas, corrigez d’abord les traces. Aucun LLM ne peut déboguer ce que vous ne vous êtes jamais donné la peine d’instrumenter.

FAQ

Seer fonctionne-t-il avec Sentry auto-hébergé ? Non. Seer est un service cloud qui nécessite sentry.io. Il s’appuie sur l’infrastructure propre de Sentry pour exécuter l’agent LLM et accéder à votre télémétrie. Les instances auto-hébergées n’ont pas accès à Seer.

Seer peut-il analyser des traces provenant de langages autres que Python et JavaScript ? Oui. Seer lit les données de trace de Sentry, pas la télémétrie brute spécifique à un langage. N’importe quel service instrumenté avec un SDK Sentry qui produit des traces peut alimenter Seer. L’étape d’analyse de code nécessite l’intégration GitHub, qui fonctionne avec n’importe quel langage.

Que se passe-t-il si Seer se trompe de cause racine ? Vous pouvez fournir un retour pendant l’analyse, et Seer l’incorporera. La sortie finale nécessite toujours l’approbation humaine avant que des changements de code ne soient appliqués ou des PR ouverts. Rien n’est livré automatiquement à moins que vous ne le configuriez explicitement pour.

En quoi est-ce différent de coller simplement une stack trace dans Claude ou ChatGPT ? Un chatbot obtient une seule fenêtre de contexte avec ce que vous collez. Seer obtient une boucle agentique avec accès à votre arbre de trace complet, erreurs connectées, profils CPU, et codebase. Il peut récupérer plus de données au fur et à mesure qu’il raisonne, et il connaît la structure de votre système parce qu’il lit le code réel.