Fehler-Tracking, das aus Exceptions gelöste Issues macht

Was ist Fehler-Tracking?

Fehler-Tracking (Error Tracking) bezeichnet das Erfassen von Exceptions und Fehlschlägen aus laufender Software, das Gruppieren identischer Probleme und deren Verwaltung als Issues, bis sie behoben sind. Ein gutes Fehler-Tracking beantwortet drei Fragen schnell: Was ist kaputt, wie viele Nutzer sind betroffen und was hat sich geändert? Es liegt zwischen rohen Logs, die zwar jeden Fehler enthalten, aber keine Struktur bieten, und dem Incident Management, das sich um echte Ausfälle kümmert.

Ohne Gruppierung erzeugt ein einziger Bug in einem stark genutzten Service schnell Hunderttausende Logzeilen pro Stunde. Fehler-Tracking fasst diese Vorkommen zu einem Issue zusammen, mit Anzahl, Trend, Zeitpunkt des ersten und letzten Auftretens sowie einem repräsentativen Stack Trace. Engineers arbeiten an Issues, nicht an einzelnen Logzeilen.

Warum Fehler-Tracking wichtig ist

Nicht jeder Fehler löst einen Alarm aus, und nicht jeder Alarm hat einen Fehler als Ursache. Viele Exceptions bleiben still: ein fehlgeschlagener Retry, ein Validierungsfehler in einem selten genutzten Formular, ein Absturz auf einer bestimmten mobilen OS-Version. Solche stillen Fehler kosten Vertrauen und Conversion, lange bevor sie in Uptime-Metriken auftauchen.

• Schnellere Erkennung: Neue Fehlertypen sind Sekunden nach ihrem ersten Auftreten sichtbar, oft direkt nach einem Deployment.
• Bessere Priorisierung: Daten zu betroffenen Nutzern und Sessions trennen kritische Bugs von harmlosem Rauschen.
• Verantwortlichkeit: Klare Zuständigkeiten und Status verhindern, dass ein Issue von allen gesehen und von niemandem behoben wird.
• Niedrigere MTTR: Vollständiger Kontext inklusive Trace und Release erspart das lokale Nachstellen von Fehlern.

So funktioniert die Errors Inbox: gruppieren, zuweisen, lösen

Die Errors Inbox ist der zentrale Ort, an dem Ihre Teams Fehler aus allen Quellen bearbeiten, also aus Backend-Services, Browser-Anwendungen und Mobile Apps.

1. Gruppieren. Für jedes Vorkommen wird ein Fingerprint aus Exception-Typ, einer normalisierten Nachricht ohne variable Werte und den eigenen Stack Frames gebildet. Vorkommen mit gleichem Fingerprint bilden ein Issue. Bei Bedarf führen Sie Issues zusammen oder passen Gruppierungsregeln an.
2. Priorisieren. Issues werden nach Vorkommen, betroffenen Nutzern, Trend und Kritikalität des Services sortiert. Neue Issues und Regressionen stehen oben.
3. Zuweisen. Weisen Sie Issues manuell oder per Regel einem Team oder einer Person zu, etwa auf Basis der Service-Ownership aus dem Service-Katalog. Kommentare halten die Diskussion direkt am Issue.
4. Lösen. Markieren Sie ein Issue als gelöst, optional für ein bestimmtes Release. Taucht derselbe Fingerprint in einer späteren Version wieder auf, öffnet Obseria das Issue als Regression und benachrichtigt die verantwortliche Person.

Fehler-Tracking mit Obseria

Obseria erfasst Exceptions über OpenTelemetry-Span-Events und Logs, über den Obseria Agent sowie über die RUM- und Mobile-SDKs. Da Fehler in Obseria Lake Teil derselben Daten sind wie Traces, Logs und Metriken, bringt jedes Vorkommen seinen vollständigen Kontext mit: den Distributed Trace, der zeigt, welcher Upstream-Call den Fehler ausgelöst hat, die Logs unmittelbar davor, den Host oder Pod und das Deployment, das den Fehler eingeführt hat.

Obseria Pipeline maskiert personenbezogene Daten in Fehlermeldungen und Attributen vor der Speicherung. Obseria Intelligence analysiert neue Issues gemeinsam mit Topologie und Deployment-Ereignissen und erklärt etwa, dass ein Fehleranstieg begann, weil eine Downstream-Abhängigkeit Timeouts lieferte. Mit OQL fragen Sie Fehler direkt ab, zum Beispiel fetch logs | filter level == "error" | summarize count(), by:{service, exception.type}, und definieren Alerts und SLOs auf Fehlerraten.

Best Practices für Fehler-Tracking

• Jedes Event mit einer Release-Version versehen, damit neue Issues Deployments zugeordnet und Regressionen erkannt werden.
• Source Maps und Debug-Symbole in der CI-Pipeline hochladen, um lesbare Stack Traces zu erhalten.
• Ownership definieren über Service-Metadaten, damit Issues automatisch beim richtigen Team landen.
• Täglich triagieren und die Inbox klein halten. Bekannte, harmlose Fehler bewusst ignorieren, statt sie anwachsen zu lassen.
• Auf Veränderung alarmieren, nicht auf Volumen. Benachrichtigen Sie bei neuen Issues, Regressionen und plötzlichen Spitzen statt bei absoluten Zahlen.
• Keine Secrets oder personenbezogenen Daten in Fehlermeldungen schreiben und die Maskierung beim Ingest als Sicherheitsnetz nutzen.