Error Tracking mit Sentry

von DaBu, am 09.09

Keine Anwendung ist fehlerfrei, niemals. Deswegen ist es wichtig entsprechend geworfene Fehler in der Anwendung zu sammeln und zu prüfen. Viele Projekte merken sich aufgetretene Fehler gar nicht oder nur in Logdateien. Logdateien müssen allerdings proaktiv, vom Entwickler, geprüft werden.

Aus diesem Grund möchte ich heute einen ergänzenden Ansatz vorstellen. Dieser wird bereits von vielen Entwicklern eingesetzt. Auch wenn ich selbst PHP Entwickler bin, möchte ich hier schon einmal betonen, dass die vorgestellte Technik Sprachunabhängig funktioniert.

Echtzeit Error Tracking

Am Beispiel von Sentry möchte ich den Sinn von Echtzeit Error Tracking erklären. Erst einmal geht es darum, Fehler, welche in der eigenen Anwendung auftreten direkt an ein anderes System zu eskalieren, in diesem Fall Sentry. Dabei wird eine Anfrage mit allen nötigen Informationen an den Dienst geschickt. Dieser interpretiert die Daten und entscheidet wie die Informationen nun eskaliert werden.

Man möchte nicht immer per Mail informiert werden, wenn derselbe Fehler erneut auftritt. Nehmen wir an beim Absenden eines Formulars passiert ein Fehler. Wir würden im Normalfall von Sentry ein einzige Mail erhalten und alle weiteren gleichen Fehler werden nur in der Weboberfläche grafisch dargestellt. Markieren wir später den Fehler als behoben, so wird dieser bei erneutem Auftreten wieder eskaliert.

Grob zusammengefasst, werden alle Fehler an ein zentrales System geschickt und dieses kann anhand der vorgegebenen Konfiguration diese an beliebige Kanäle weiterschicken. So steht neben der klassischen Mail auch beispielsweise Slack zur Verfügung. Zusätzliche gibt es noch viele weitere Plugins, wie zum Beispiel die Anbindung von eigenen Webhooks oder GitHub..

Übersicht behalten

Übersichtsseite
Durch das dauerhafte Sammeln aller Fehler bekommt man schnell einen Gesamtüberblick und kann auch erkennen ob Fehler nach Wochen noch einzeln auftreten. Gleiches gilt für Fehler die vielleicht ständig auftreten, aber nie von Nutzern gemeldet werden, da es sich nur um eine Kleinigkeit handelt.

Informationen

Sentry bietet einem viele Möglichkeiten Daten anzugeben. Nutzt man eine Bibliothek für sein Framework, so werden viele Informationen automatisch ausgefüllt. Beispielsweise können Cookies, HTTP-Header, Error-Level, URL, Servername, PHP Version sowie Useragent mitgeschickt werden. (Screenshot einer Detailansicht)

Weitere eigene Daten können entsprechend ergänzt werden. Denkbar sind hier eine Nutzer ID um gegebenenfalls beim Nutzer etwas nachzufragen oder zu sehen ob bestimmte Fehler nur bei bestimmten Nutzern oder Nutzergruppen auftreten.

Bevor ein Fehler auftritt weiß man selbst nie so genau, welche Informationen wichtig sein könnten. Deswegen lohnt es sich durchaus eher etwas mehr mitzuschicken.

Releases

Setzt man auf eine Versionsverwaltung, so besteht die Möglichkeit den Hash, der aktuellen Release Version, an Sentry mitzuschicken. Dadurch ergeben sich neue Möglichkeiten beim Handling der Fehlermeldungen. Beispielsweise kann angegeben werden, dass ein Fehler in der nächsten Version behoben sein wird. Sollte dieser vor der neuen Version erneut auftreten, wird er nicht wieder eskaliert.

Weiterhin Fehler loggen?

Eine Frage oder vielleicht auch ein Missverständnis was immer wieder bei dem Thema aufkommt ist. Muss ich dann überhaupt noch die Fehler in meiner eigenen Anwendung sammeln und in Log-Dateien schreiben? Die Antwort ist ganz klar, ja.

Es kann immer sein, dass der externe Dienst nicht erreichbar ist. Vielleicht passiert aber auch etwas anderes unerwartetes, sodass die Meldung an Sentry nicht mehr verschickt werden kann. Möglich ist alles und das Loggen direkt in eine Datei ist der sicherste Weg, dass die Informationen niemals verloren gehen.

Bei eigenen Projekten ist es beispielsweise schon passiert, dass der Stacktrace so groß gewesen ist, dass er nicht mehr versendet werden konnte. Dadurch wurde in Sentry zwar ein Fehler angezeigt, allerdings waren keine Details zu finden. Im Projekt selbst waren die Informationen dennoch zu finden.

Betrieb

Eine der wichtigsten Fragen ist wohl, wie man jetzt Sentry betreibt. Wenn man sich ansieht, was dafür alles gebraucht wird, könnte einem schnell schwindelig werden. Wir brauchen ein Redis, PostgreSQL, ein Webserver sowie Supervisord.

Niemand möchte so einen Stack an Software für sein kleines Projekt aufbauen. Deswegen gibt es zwei mögliche Lösungen. Alle die gerne mit Docker arbeiten, können hier eine Anleitung finden, wie sie in kurzer Zeit Sentry in betrieb nehmen können.

Für alle anderen gibt es ein kostenloses Einsteigerpaket, auf sentry.io, dieses sollte für die meisten Projekte ausreichen. Leider gibt es dabei nur eine Historie von 7 Tagen, aber für eine kostenlose Möglichkeit ist dies sicher in Ordnung.

SDKs

Wie eingangs bereits erwähnt, kann Sentry von beliebigen Systemen genutzt werden. Um die Kommunikation zu vereinfachen, gibt es bereits für diverse Sprachen SDKs. PHP, Node.js, C#, Rust und viele weitere. Speziell in PHP gibt es noch eine Integration für Laravel und Symfony, in Javascript wiederum für Angular, React und Vue.js.

Alternativen

Neben Sentry gibt es natürlich auch noch weitere Projekte die in dieselbe Kerbe schlagen. Mögliche Alternativen sind da, bugsnag oder auch logentries. Getestet habe ich diese selbst noch nicht.

Fazit

Ähnlich wie die Nutzung einer Versionsverwaltung, kann ich mir nicht mehr vorstellen, ohne ein Error Tracking zu arbeiten. Keine Anwendung ist fehlerfrei und gerade ein Browsergame ist meist eine recht komplexe Anwendung. Viele haben sicher noch nie Tests für ihre Anwendung geschrieben, da ist ein Tracking für Fehlermeldungen ein Minimum.

Werbung