Karsten Sitterberg Freiberufler

Ein Produkt wie das hier verwendete Sentry ist bei einer Webanwendung mit einem nicht trivialem Nutzerkreis eine große Hilfe, um Fehler finden und nachstellen zu können.

Aufgrund der zunehmenden Komplexität von Anwendungen bleiben Fehler nicht aus. Nicht jeder Fehler wird in der Testphase entdeckt – viele Fehler sind auch in den Produktionsumgebungen noch vorhanden. Mit Sentry gibt es eine praktikable Softwarelösung für eine umfassende Fehleranalyse.

Nutzer, die Programmfehler beobachten, melden diese leider meist nicht: Zum einen ist es eine mühselige Angelegenheit, zum anderen ist selten ein klarer Weg erkennbar, um geeignetes Feedback zu übermitteln. Doch selbst wenn ein Nutzer Feedback gibt, ist das nicht immer verwendbar: Genaue Angaben zur verwendeten Plattform (Betriebssystem, Browser, Auflösung etc.) sind vielen Anwendern selbst nicht bekannt, geschweige denn, dass diese Informationen vollständig und korrekt übermittelt werden. Zu diesen Informationen gehören auch weitere Kontextinformationen: Manche Fehler treten erst durch Kombination mehrerer Aktionen bzw. in einem bestimmten Anwendungszustand zu Tage.

Spätestens hier sind regelmäßig Anwender und selbst manche Tester überfordert, eine präzise und umfassende Fehlerbeschreibung bereitzustellen. Abhilfe schafft speziell für Crash-Reporting konzipierte Software. Das umfangreiche Angebot am Markt verfügbarer Software vermittelt einen Eindruck davon, wie hoch der Bedarf ist. Eine dieser Lösungen ist Sentry, das zu 100 Prozent als Open Source vorliegt und im Folgenden exemplarisch verwendet wird. Die Konzepte und grundsätzlichen Herangehensweisen lassen sich leicht auch auf andere Produkte übertragen.

Um einen besseren Eindruck davon zu gewinnen, welche Anforderungen an Crash-Reporting-Lösungen gestellt werden, und wieso es sich dabei um etwas anderes als einen einfachen Logger handelt, werden im Folgenden einige Features von Sentry aufgezeigt. Anschließend werden die Einrichtung eines Sentry-Projekts und der praktische Einsatz in einer Beispielanwendung mit Angular erklärt.

Die feinen Unterschiede

Zentrales Logging, z. B. mit Graylog oder dem ELK-Stack, ist bei großen und verteilten Anwendungen ein Muss. Anders lassen sich die über viele Instanzen und Maschinen verteilt anfallenden Informationen nicht sinnvoll handhaben. Logging-Lösungen sind in der Regel darauf spezialisiert, Protokolldaten zu verarbeiten und ggf. daraus zusätzliche Informationen, wie beispielsweise Metriken, abzuleiten. Logging ist damit ohne Frage sehr nützlich. Doch jeder, der öfter anhand von Logstreams Fehler analysiert, hat sich früher oder später zusätzliche Hilfsmittel gebaut. Seien es reguläre Ausdrücke, vordefinierte Filter der jeweiligen Logging-Systeme oder sogar Hilfsprogramme.

Allen Ansätzen ist gemeinsam, dass sie versuchen, aus den unstrukturierten Textdaten wieder strukturierte Daten zu extrahieren und eine Gesamtsicht zu aggregieren. Mit dem durch Graylog eingeführten gelf-Logformat hat sich ein JSON-basiertes, strukturiertes Logformat etabliert, mit dem alle marktüblichen Produkte umgehen können. Durch ein Format, dass sich gleichermaßen für Menschen wie auch für Maschinen eignet, ist das fehleranfällige, mühevolle Parsen der Logdaten entfallen. Gleichzeitig ist es durch das erweiterbare Format leicht möglich, dynamisch zusätzliche Daten bereitzustellen.

Den vollständigen Artikel lesen Sie in der Ausgabe:

Windows Developer 3.18 - "Web und Desktop ergänzen sich"

Alle Infos zum Heft
579828111Sentry: Fehlermanagement im Produktiveinsatz
X
- Gib Deinen Standort ein -
- or -