Error Tracking für Production
Exceptions aus deinen Apps sammeln, gruppieren und abarbeiten.
Uptime-Monitoring beantwortet, ob ein Dienst erreichbar ist. Error Tracking beantwortet die unangenehmere Frage: was in einem erreichbaren Dienst gerade schiefläuft. Ein Server kann mit 200 antworten und trotzdem bei jedem zehnten Nutzer eine Exception werfen. Im Uptime-Chart bleibt das unsichtbar. Mit dem Error-Tracking-Add-on schickst du Fehler-Events direkt aus deinen Anwendungen an UptimeAlien und siehst neben der Verfügbarkeit auch die Fehler, die deine Nutzer tatsächlich treffen. An einer Stelle, ohne dafür ein zweites Tool zu betreiben.
Wie es funktioniert
Deine Anwendung meldet Fehler per HTTP-POST an den Ingest-Endpunkt, authentifiziert über einen Projekt-API-Key. Ein Event trägt einen Level (error, warning, info oder fatal), die Fehlermeldung, optional den Stacktrace sowie frei wählbare Tags und Kontextdaten. Für jedes Event bilden wir einen Fingerprint aus Service, normalisierter Meldung und erstem Stackframe. In der Übersicht landen Events mit demselben Fingerprint in einer Zeile mit Zähler: tausend Auftreten desselben Fehlers sind ein Eintrag, nicht tausend Zeilen. Ein Klick auf „Erledigen“ schließt die ganze Gruppe.
Deine Vorteile
- Fehler aus mehreren Apps und Services an einer Stelle
- Gleichartige Fehler werden zu einem Eintrag mit Zähler zusammengefasst
- Nach Häufigkeit sortieren und die lautesten Fehler zuerst angehen
- Stacktraces mitliefern und direkt im Dashboard lesen
- Offene von erledigten Fehlern trennen und den Fortschritt sehen
- Über Tags nach Service, Umgebung oder Release filtern
- Uptime und Fehler im selben Tool, ohne zweites Abo
Was du bekommst
Eine Übersicht der Fehler, je mit Anzahl der Vorkommen, letztem Auftreten, Level und Meldung. In der Detailansicht kommen Stacktrace, Tags, Kontextdaten und die Liste der einzelnen Vorkommen dazu.
Verfügbarkeit
Als kostenpflichtiges Add-on zubuchbar und in Plänen mit Error-Monitoring bereits enthalten. Nicht im Free-Tier.
Uptime-Monitoring sieht die Startseite, nicht die Exception im Checkout
Ein Uptime-Check betrachtet deine Anwendung von außen und meist über einen einzigen Pfad. Er erkennt zuverlässig, dass die Startseite antwortet. Nicht aber, dass der Checkout seit dem letzten Deploy bei jeder Bestellung mit einer NullReferenceException abbricht, dass ein Hintergrundjob still scheitert oder dass ein Drittanbieter-API-Aufruf reihenweise Timeouts wirft. Diese Fehler passieren innerhalb einer Anwendung, die nach außen völlig gesund aussieht. Error Tracking schließt die Lücke, indem die Anwendung selbst meldet, was in ihr passiert.
Wie Fehler gruppiert werden
Ohne Gruppierung wäre Error Tracking nur ein weiteres Logfile. Eine Warnung, die alle 30 Sekunden feuert, erzeugt an einem Tag knapp dreitausend Zeilen und begräbt alles andere unter sich. UptimeAlien bildet deshalb für jedes Event einen Fingerprint aus Service, normalisierter Meldung und erstem Stackframe und fasst Events mit demselben Fingerprint in der Übersicht zu einer Zeile zusammen, mit der Anzahl der Vorkommen daneben. Sortieren lässt sich nach letztem Auftreten oder nach Häufigkeit, du priorisierst also nach dem, was am lautesten schreit, statt nach Zufall. Wichtig dabei: zusammengefasst wird erst bei der Anzeige, nicht beim Empfangen. Jedes einzelne Vorkommen bleibt mit seinem exakten Zeitpunkt, seinen Tags und seinem Kontext erhalten und ist in der Detailansicht weiter einsehbar. Du verlierst also keine Daten, nur die Unübersichtlichkeit.
Anbindung deiner Anwendung
Die Anbindung ist ein einfacher HTTP-Endpunkt und kein SDK, das wir für jede Sprache pflegen müssten. Du erstellst im Dashboard einen API-Key für dein Projekt und schickst aus dem Exception-Handler deiner Anwendung ein JSON-Objekt an den Ingest-Endpunkt. Das funktioniert aus jeder Sprache und jedem Framework, das HTTP sprechen kann: Node, PHP, Python, Go, Rust, .NET oder ein Shell-Skript im Cronjob. Über das Tag „service“ trennst du mehrere Anwendungen innerhalb desselben Projekts.
Häufige Fragen
Was ist Error Tracking?
Error-Tracking-Software sammelt Fehler und Exceptions aus deinen laufenden Anwendungen an einer zentralen Stelle, gruppiert gleichartige Vorfälle und macht sichtbar, welche Probleme wie häufig auftreten. Anders als beim Uptime-Monitoring geht es nicht um Erreichbarkeit, sondern um die Fehler innerhalb einer erreichbaren Anwendung.
Werden gleichartige Fehler zusammengefasst?
Ja. Fehler mit demselben Fingerprint, gebildet aus Service, normalisierter Meldung und erstem Stackframe, erscheinen als eine Zeile mit Zähler statt als viele identische Einträge. Erledigst du diese Zeile, werden alle offenen Vorkommen der Gruppe auf einmal geschlossen. Tritt der Fehler danach erneut auf, taucht die Gruppe wieder unter „Offen“ auf, damit ein Rückfall nicht untergeht.
Worin unterscheidet sich Error Tracking von Exception Tracking?
Die Begriffe werden meist synonym verwendet. Exception Tracking betont die von der Programmiersprache geworfenen Ausnahmen samt Stacktrace, Error Tracking ist etwas weiter gefasst und schließt zum Beispiel Warnungen und selbst gemeldete Fehlerzustände ein. UptimeAlien deckt beides über dieselben Events ab, der Level unterscheidet zwischen error, warning, info und fatal.
Wie sende ich Fehler aus meiner App?
Per HTTP-POST an den Ingest-Endpunkt, authentifiziert mit einem Projekt-API-Key. Der Body enthält Level und Meldung, optional Stacktrace, Tags und Kontext. Ein SDK ist nicht nötig, jede Sprache, die HTTP-Requests senden kann, reicht aus.
Werden Stacktraces gespeichert?
Ja. Du kannst zu jedem Event einen Stacktrace mitschicken, er wird gespeichert und im Dashboard zur Fehlergruppe angezeigt. Pflicht ist er nicht, Events ohne Stacktrace nehmen wir ebenfalls an.
Ist Error Tracking im Free-Tier enthalten?
Nein. Error-Monitoring ist ein kostenpflichtiges Add-on und in den Plänen enthalten, die es mitbringen. Schickt ein Projekt ohne diese Berechtigung Events, weist der Ingest-Endpunkt sie ab. Das Uptime-Monitoring selbst bleibt im Free-Tier kostenlos.
Kann ich Fehler aus mehreren Anwendungen trennen?
Ja, auf zwei Wegen. Entweder legst du pro Anwendung ein eigenes Projekt an, oder du bleibst in einem Projekt und kennzeichnest die Herkunft über das Tag „service“. Danach lässt sich später filtern.