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 geprüft werden.
Aus diesem Grund möchte ich heute einen alternativen Ansatz vorstellen. Dieser wird bereits von Tausenden Entwicklern eingesetzt. Auch wenn ich selbst PHP Entwickler bin, möchte ich hier schon einmal betonen, dass die vorgestellte Technik sprachübergreifend funktioniert.
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 passieren 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 entscheiden wie die Informationen nun eskaliert werden.
Zum einen möchte man 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 einziges Mal eine Mail erhalten und alle weiteren gleichen Fehler werden nur in der Weboberfläche grafisch dargestellt. Sagen wir später, dass der Fehler behoben ist, dann wird er bei Wiederauftreten erneut 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.
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, weil es sich nur um eine Kleinigkeit handeln.
Sentry bietet einem viele Möglichkeiten Daten anzugeben. Nutzt man dort 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.
Weitere eigene Daten können entsprechend ergänzt werden. Denkbar sind hier eine Nutzer ID um ggf. beim Nutzer etwas nachzufragen oder zu sehen ob bestimmte Fehler nur bei bestimmten Nutzern 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.
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 dieser nicht ein weiteres mal eskaliert.
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.
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. Für alle die gerne mit Docker arbeiten, können hier eine Anleitung finden, wie sie in kurzer Zeit Sentry ans Laufen bekommen.
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.
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.
Neben Sentry gibt es natürlich auch noch weitere Projekte die in dieselbe Kerbe schlagen. Mögliche alternativen sind da, bugsnag oder auch logentries.
Ähnlich wie die Nutzung einer Versionsverwaltung wie GIT, kann ich mir nicht mehr vorstellen, ohne ein Error Tracking zu arbeiten. Keine Anwendung ist fehlerfrei und über die Zeit entstehen immer mehr recht komplexe Anwendungen. Viele haben sicher noch nie Tests für ihre Anwendung geschrieben, da ist ein Tracking der Fehler ein Muss.