Sentrys Seer kann Ihre Traces lesen. Das heißt nicht, dass es immer die Root Cause findet.

Ein Frontend wirft einen 500er. Der Stacktrace zeigt auf eine React-Komponente. Das echte Problem ist drei Services entfernt, in einem erschöpften Datenbank-Connection-Pool, verursacht durch einen leakenden Background-Job.

Sie könnten durch Trace-Waterfalls klicken, Timestamps korrelieren und Commit-History lesen. Oder Sie könnten es Sentrys Seer übergeben, einem LLM-gestützten Debugging-Agenten, der Ihre Traces, Fehler und Code liest und Ihnen dann sagt, was kaputt gegangen ist.

Seer ist darin gut. Es ist kein Hellseher. Die Lücke zwischen diesen beiden Aussagen ist das Thema dieses Artikels.

Was Statistical Debugging tatsächlich bedeutet

Statistical Debugging nutzt Muster über viele Ausführungen hinweg, um Bugs zu lokalisieren. Traditionelle Debugger zeigen Ihnen einen Durchlauf. Statistische Ansätze betrachten Verteilungen: Welche Funktionen scheitern zusammen, welche Traces korrelieren mit Fehlern, welche Commits gingen einem Absturz-Spike voraus.

Sentry hat den statistischen Teil seit Jahren gemacht. Seer fügt ein LLM hinzu, um über Kausalität auf Basis dieser Daten zu schlussfolgern. Es ersetzt die Statistik nicht. Es interpretiert sie.

Seer halluziniert keine Root Causes aus dem Nichts. Es betrachtet dieselben Traces und Stack Traces, die auch Sie betrachten würden, liest aber Tausende von Spans in Sekunden und korreliert sie mit Ihrem Codebase.

Wie Seer einen Trace liest, ohne in Spans zu ertrinken

Ein Distributed Trace kann Tausende von Spans enthalten. Alle davon in ein LLM-Context-Window zu füttern, ist ein Rezept für Verwirrung. Das Modell fixiert sich auf irrelevante Details und verpasst das Signal.

Sentry löst dies, indem es einen verdichteten Trace-Tree baut. Statt jedes Spans sieht Seer eine Hierarchie von Transactions, die Service Boundaries, die Spans in sinnvolle Einheiten gruppieren. Der Tree zeigt, welche Transactions welche anderen aufgerufen haben, wie lange sie gedauert haben und ob Fehler darin aufgetreten sind.

So sieht ein roher Trace konzeptionell aus:

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 erhält diesen Tree, annotiert mit Timing- und Fehlerstatus. Es sieht, dass die Checkout-Anfrage drei Downstream-Services aufgerufen hat. Es sieht nicht jede einzelne Datenbankabfrage, es sei denn, es fragt danach.

Das Schlüsselwort ist “es sei denn”. Seer hat Tools. Wenn der Tree nahelegt, dass der Payment-Service das Problem ist, kann es die vollständigen Spans innerhalb dieser Transaction abrufen, verbundene Fehlerereignisse per ID oder CPU-Profiles. Es entscheidet, als Nächstes was betrachtet werden soll.

Dieser agentische Ansatz ist der Unterschied zwischen “diesen Trace in ChatGPT einfügen” und dem, was Seer tatsächlich tut. Ein Chatbot bekommt einen Versuch. Seer bekommt eine Schleife: beobachten, schlussfolgern, mehr Daten abrufen, erneut schlussfolgern.

Das Cross-Service-Problem, für das Seer gebaut wurde

Vor Traces verließ sich Seer (damals Autofix genannt) auf Stack Traces und Breadcrumbs. Das funktionierte für Monolithen. Es scheiterte bei verteilten Systemen.

Betrachten Sie einen Frontend-500-Fehler. Der Stacktrace zeigt auf einen Fetch-Aufruf. Ohne Traces würde Seer schlussfolgern, dass das Frontend kaputt ist. Mit Traces sieht es, dass das Frontend das API-Gateway aufgerufen hat, das den Auth-Service aufgerufen hat, der einen Token-Validierungsfehler warf, weil ein Zertifikat rotiert wurde.

Sentrys eigenes Team ist intern darauf gestoßen. Ein Authentifizierungsproblem zwischen Sentrys Backend und Seers Microservice hatte sich über Tage hingezogen. Seer, ausgestattet mit dem Trace-Tree und Zugriff auf beide Repositories, identifizierte die Root Cause und eröffnete Pull Requests in beiden Services.

Das ist das Versprechen. Der Haken ist das Setup.

Was Seer braucht, bevor es Ihnen helfen kann

Seer benötigt drei Dinge, um gut zu funktionieren:

1. Verbundene Traces.

Wenn Ihre Services verschiedene Sentry-Projekte ohne Distributed Tracing nutzen, sieht Seer isolierte Fehler, keinen Trace-Tree. Sie benötigen das Sentry-SDK in jedem Service und Trace-Header-Propagation.

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

Für Cross-Service-Propagation liest und schreibt das SDK sentry-trace und baggage Header automatisch auf unterstützten HTTP-Clients. Wenn Sie Ihren eigenen Client bauen, hängen Sie die Header manuell an:

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

Ohne das sieht Seer Frontend- und Backend-Fehler als unverbundene Vorfälle. Der Trace-Tree bildet sich nie.

2. Verbundener Code.

Seer durchsucht Ihren Codebase, um Traces mit der Implementierung zu korrelieren. Das erfordert die GitHub-Integration und das Zuordnen von Repositories zu Sentry-Projekten. Seer kann Ihren Code nicht aus einer ZIP-Datei oder einem lokalen Pfad lesen.

3. Genug Signal.

Ein Trace mit nur auto-instrumentierten HTTP-Spans sagt Seer, dass Service A Service B aufgerufen hat. Es sagt Seer nicht, welche Geschäftslogik dazwischen passiert ist. Custom Spans sind wichtig.

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)

Ohne diese sieht Seer eine Black Box zwischen dem HTTP-Request und der Datenbankabfrage.

Die Trade-offs, die niemand in den Marketingtext schreibt

Seer hat echte Einschränkungen, und Sentry ist vernünftigerweise ehrlich darüber.

Die Genauigkeit ist hoch, aber nicht 100 %.

Sentry berichtet von einer Root-Cause-Identifikationsrate von 94,5 %. Das bedeutet, dass etwa eine von zwanzig Issues falsch diagnostiziert wird. Für Incidents mit hohem Schweregrad benötigen Sie weiterhin einen Menschen, der Seers Schlussfolgerung verifiziert, bevor Sie einen Fix deployen.

Es kostet Geld pro Durchlauf.

Seer-Durchläufe kosten etwa 1 $ pro Root-Cause-Analyse plus ein monatliches subscription. Automatisierte Scans sind mit 0,003 $ pro Issue günstiger. Für ein Team, das täglich Dutzende von Issues bearbeitet, summiert sich das. Konfigurieren Sie Automatisierungsschwellen sorgfältig.

Es kann nicht beheben, was es nicht sehen kann.

Wenn Ihre Traces mit 1 % gesampelt werden und der Bug nur in den anderen 99 % auftritt, wird Seer ihn nicht finden. Wenn die Root Cause in einem Drittanbieter-Service liegt, der keine Traces an Sentry sendet, wird Seer an eine Wand stoßen. Wenn das Problem ein logischer Bug ist, der nie einen Fehler wirft, wird Seer nie ausgelöst.

LLMs sind bei manchen Arten von Schlussfolgerungen immer noch schlecht.

Eine Microsoft-Studie bestätigte, was die meisten Entwickler vermuten: AI-Agents sind hervorragend darin, Probleme zu lokalisieren, haben aber Schwierigkeiten mit der Root-Cause-Analyse, wenn die Ursache weit vom Symptom entfernt ist. Kausalität über Zeit hinweg, besonders bei Race Conditions oder State Corruption, bleibt schwierig.

Wann Seer glänzt und wann man es überspringen sollte

Seer ist einen Versuch wert, wenn:

• Sie ein verteiltes System mit verbundenen Traces über mehrere Services hinweg haben
• Das Problem ein klares Fehlerereignis beinhaltet, das Sentry erfasst hat
• Die Root Cause wahrscheinlich in Ihrem eigenen Code liegt, nicht in einer Drittanbieter-Dependency
• Sie genug Trace-Volumen haben, sodass manuelle Untersuchung mühsam ist

Überspringen Sie es, wenn:

• Ihre Traces nicht über Services hinweg verbunden sind
• Das Problem intermittierend ist und selten in Traces erfasst wird
• Sie Sub-Minute-Auflösung für einen aktiven Incident benötigen (Seer braucht Minuten zum Ausführen)
• Die Root Cause fast sicher Infrastruktur ist, nicht Code

Wie man es tatsächlich ausprobiert

Wenn Sie bereits einen kostenpflichtigen Sentry-Plan haben, ist Seer als 14-Tage-Testversion verfügbar.

1. Verbinden Sie GitHub in Ihren Sentry-Organisationseinstellungen
2. Ordnen Sie Ihre Repositories Ihren Sentry-Projekten in den Seer-Einstellungen zu
3. Stellen Sie sicher, dass Tracing in Ihren SDKs mit gesetztem traces_sample_rate aktiviert ist
4. Öffnen Sie ein beliebiges Issue und klicken Sie auf Find Root Cause

Für automatisierte Durchläufe konfigurieren Sie einen Stopp-Punkt. Die meisten Teams beginnen mit Stop after Root Cause. Sobald Sie der Genauigkeit vertrauen, können Sie es Lösungen vorschlagen oder Pull Requests entwerfen lassen.

Wenn Sie Cursor oder Claude Code verwenden, können Sie Seer über Sentrys MCP-Server direkt in Ihrem IDE-Chat aufrufen.

Das ehrliche Fazit

Seer kann Root Causes in Traces finden, indem es verdichtete Trace-Trees baut, detaillierte Daten on demand abruft und über Ihren Codebase hinweg schlussfolgert. Für verbundene, gut instrumentierte verteilte Systeme ist es genuin nützlich. Sentrys eigene Ingenieure haben sich bei Cross-Service-Problemen Tage an Debugging-Zeit erspart.

Es ist kein Ersatz dafür, Ihr eigenes System zu verstehen. Es ist ein sehr schneller, sehr belesener Praktikant, der Traces und Code lesen kann, aber gelegentlich immer noch den falschen Service beschuldigt. Verwenden Sie es, um Untersuchungen zu beschleunigen, nicht um sie zu eliminieren.

Wenn Ihre Traces sauber, verbunden und voller nützlicher Spans sind, wird Seer Sie wahrscheinlich beeindrucken. Wenn nicht, beheben Sie zuerst die Traces. Kein LLM kann debuggen, was Sie nie instrumentiert haben.

---

FAQ

Funktioniert Seer mit Self-Hosted-Sentry? Nein. Seer ist ein Cloud-Service, der sentry.io erfordert. Es verlässt sich auf Sentrys eigene Infrastruktur, um den LLM-Agenten auszuführen und auf Ihre Telemetrie zuzugreifen. Self-Hosted-Instanzen haben keinen Zugriff auf Seer.

Kann Seer Traces aus anderen Sprachen als Python und JavaScript analysieren? Ja. Seer liest Trace-Daten von Sentry, keine rohen sprachspezifischen Telemetriedaten. Jeder Service, der mit einem Sentry-SDK instrumentiert ist und Traces produziert, kann in Seer eingespeist werden. Der Code-Analyse-Schritt erfordert die GitHub-Integration, die mit jeder Sprache funktioniert.

Was passiert, wenn Seer die Root Cause falsch hat? Sie können während der Analyse Feedback geben, und Seer wird es einbeziehen. Die endgültige Ausgabe erfordert immer menschliche Freigabe, bevor Code-Änderungen angewendet oder PRs eröffnet werden. Nichts wird automatisch ausgeliefert, es sei denn, Sie konfigurieren das explizit so.

Wie unterscheidet sich das davon, einfach einen Stacktrace in Claude oder ChatGPT einzufügen? Ein Chatbot bekommt ein einzelnes Context-Window mit dem, was Sie einfügen. Seer bekommt einen agentischen Loop mit Zugriff auf Ihren vollständigen Trace-Tree, verbundene Fehler, CPU-Profiles und Codebase. Es kann mehr Daten abrufen, während es schlussfolgert, und es kennt die Struktur Ihres Systems, weil es den tatsächlichen Code liest.