Sentry ist ein Dienst, der im Grunde nichts weiter macht als Nachrichten von beliebigen Applikationen über das Netzwerk entgegen zu nehmen. Diese werden in Echtzeit nach festgelegten Kriterien geordnet, mit weiteren Informationen angereichert, aggregiert und schließlich in einem Web-Frontend dargestellt. 2010 als Exception-Tracker für das Python-Framework Django entwickelt, wird Sentry inzwischen von Unternehmen wie Mozilla oder Pinterest eingesetzt.

Wozu soll man aber überhaupt ein dediziertes Tools verwenden, wenn sich Fehlermeldungen ebenso in Server-Logfiles schreiben und auswerten lassen? Die Frage ist durchaus berechtigt, allerdings bietet Sentry weit mehr Vorteile als ein einfaches, Datei-basierendes Logging – wie die folgende Übersicht verdeutlichen soll:

• Ähnliche Nachrichten werden aggregiert, wodurch häufig auftretende Fehler sofort auffallen und mit erhöhter Priorität behandelt werden können.
• Jeder Nachricht werden umfangreiche Informationen wie ein Stacktrace angehängt, was die Analyse vereinfacht.
• Konventionelle Logfiles muss man aktiv überprüfen, Sentry hingegen benachrichtigt Entwickler automatisch.
• Nachrichten können nach verschiedenen Kriterien wie Tags, Fehler-Level, dem Zeitraum oder dem System, auf dem sie aufgetreten sind, sortiert werden. So bleiben auch große Datenmengen übersichtlich.
• Durch das Web-Frontend mit Rechte- und Rollen-Management besteht die Möglichkeit, die Meldungen auch Dienstleistern, Freelancern oder sogar Projektmanagern zugänglich zu machen.
• Da die Logs auf einem von der Applikation getrennten Server im Netzwerk gespeichert sind, bleiben sie auch dann noch einsehbar, wenn das Produktionssystem einen Totalausfall vermeldet.

Der Nachrichten-Stream im Web-Frontend von Sentry. Die Zahl neben den Einträgen steht für die Eintrittshäufigkeit des Events, die Farbe der Markierung für das Fehler-Level.

Natürlich entsteht beim Einsatz von Sentry durch die Kommunikation und die applikationsseitige Implementierung ein gewisser Overhead. Dieser ist jedoch marginal und in Anbetracht der Vorteile leicht zu verschmerzen.

Sentry basiert auf einer klassischen Client-Server-Architektur. Der Client schickt die Nachrichten wie beschrieben zum Server, der sie speichert, aufbereitet und in einem Web-Frontend darstellt. Wer keinen eigenen Client entwickeln will, kann einfach Raven verwenden. Ursprünglich genau wie Sentry in Python geschrieben, gibt es für Raven Portierungen auf fast alle gängigen Plattformen wie PHP, Ruby oder sogar JavaScript – es spielt daher keine Rolle, auf welcher Plattform die eigentliche Applikation basiert. Selbst für Frameworks wie Symfony2 ist ein Raven-Bundle verfügbar. In der Default-Einstellung kommunizieren Sentry und Raven per HTTP über Port 9000 und neuerdings wird auch UDP unterstützt.

Um Nachrichten zu empfangen, wird im Web-Frontend zunächst ein Projekt auf dem Server angelegt. Der Server kann beliebig viele Projekte verwalten. Von zentraler Bedeutung für die Kommunikation und die Verarbeitung der eingehenden Information ist der projektspezifische DSN (Data Source Name), den Sentry anschließend vergibt und der von Raven bei der Initialisierung verwendet werden muss:

{PROTOCOL}://{PUBLIC_KEY}:{SECRET_KEY}@{HOST}/{PATH}{PROJECT_ID}
# Aufbau des Sentry-DSN

Sentry lässt sich entweder auf einem eigenen Server (Self-Hosted, empfohlen bei sensiblen oder kritischen Daten) installieren oder als SaaS-Lösung betreiben. Letztere ist für bis zu 100 Events am Tag kostenfrei, danach sind je nach anfallender Datenmenge zwischen neun und 99 US-Dollar pro Monat fällig.

Sentry ins eigene Projekt integrieren: so geht’s

Um Sentry auszuprobieren, reicht die kostenfreie SaaS-Variante. Nach dem Anlegen eines neuen Projekts muss zunächst der Raven-PHP-Client von Github geladen werden, alternativ steht auch ein Composer-Package zur Verfügung. Mit dem Sentry-DSN wird eine Instanz von Raven erstellt:

<?php

# Bei der Installation via Composer entfällt dieser Teil
require_once '/path/to/raven/lib/Raven/Autoloader.php';
Raven_Autoloader::register();

# Der von Sentry vergebene DSNdefine('DSN', 'https://public:secret@app.getsentry.com/project-id');

# Initialisierung des Clients
$client = new Raven_Client(DSN, array(
 'logger' => 't3n',
 'tags' => array(
 'foo'=>'bar',    
 ),
));

Bei der Initialisierung des Clients können beliebige Tags sowie ein Name für den Logger angegeben werden. Sentry erstellt daraus automatisch Filter für das Web-Frontend. Um die eigentliche Nachricht zu erzeugen, genügt ein Einzeiler:

# Event loggen, die Daten aus dem Extra-Parameter werden direkt dem Event angehängt
$event_id = $client->captureMessage("Fehler: %s", array('Unbekannt'), array(
 'extra' => array(
 'key' => 'value',
 'lorem' => 'ipsum'
 ),
 'level' => 'info',
 ));

echo $event_id;

Neben der eigentlichen Nachricht werden von Raven weitere Details wie die HTTP-Header des Requests, GET- und POST-Parameter, das $_SERVER-Array sowie Informationen zum Client-OS und Browser gesendet. Optional besteht die Möglichkeit, verschiedene Fehler-Level wie Debug, Warning oder Fatal für jedes Event zu vergeben. Ebenfalls optional ist der Extra-Parameter, der in der neuesten Version des Clients hinzugekommen ist. Mit diesem lassen sich beliebige Key-/Value-Paare (Values können auch Arrays oder Objekte sein) als Zusatzinformation übergeben, die später übersichtlich formatiert im Kontext des Events angezeigt werden. Einen Hash, der all diese Informationen exakt in der Datenbank identifiziert, liefert Raven praktischerweise als Rückgabewert.

Darüber hinaus kennt Raven noch weitere „Convenience Methoden“. Der wichtigste Anwendungsfall ist das Loggen von Exceptions. Analog zu oben genanntem Beispiel kann mit Raven_Client::captureException($e) anstelle einer Nachricht auch ein Exception-Objekt übergeben werden. Intern nutzt Raven dazu ein anderes Nachrichten-Interface, das im Wesentlichen für die ordentliche Darstellung eines Stacktraces in den Logs sorgt. Auch die Verwendung im Rahmen des Standard-Error-Handlings von PHP ist bereits vorgesehen, der Client stellt entsprechende Methoden bereit.

Im Web-Frontend von Sentry laufen alle Nachrichten eines Projekts in Echtzeit zusammen und werden im so genannten „Stream“ dargestellt. Sendet eine Applikation mehrfach dasselbe Event, wird es aggregiert und an den Anfang verschoben. In Kombination mit der Häufigkeit und dem Fehlerlevel ergibt sich so eine Priorisierung für das anschließende Bug-Fixing praktisch von selbst. Neben den (konfigurierbaren) Default-Filtern von Sentry wie nach Host oder Client-Browser lässt sich der Stream auch nach den bei der Client-Instanzierung vergebenen Tags filtern. Sentry informiert außerdem bei einem erstmalig aufgetretenen Bug per Mail oder IM und kann automatisiert ein Ticket in Tools wie Jira eröffnen oder Web-Hooks ausführen.

In der Detail-Ansicht steht dann die volle Bandbreite an Kontext-Informationen zur Verfügung, zum Beispiel die Informationen aus dem extra-Parameter von Raven_Client::captureMessage() oder der Stacktrace einer Exception. Wurde der Auslöser einer Exception korrigiert, lässt sich der daraus resultierende Eintrag entsprechend markieren. Tritt dieselbe Exception erneut auf, wertet Sentry das als Regression-Bug und sendet eine entsprechende Benachrichtigung – so ist es fast unmöglich, aufgetretene Fehler zu übersehen.

In der Praxis merkt man schnell, dass dank Sentry Probleme auffallen, von denen man nicht mal wusste, dass es diese überhaupt gibt. Bekommt zum Beispiel ein Redakteur beim Einpflegen eines Artikels eine Fehlermeldung, erhalten die Entwickler alle wesentlichen Informationen dazu – und zwar noch bevor der Redakteur selbst reagieren kann. Auf den ersten Blick „nur“ ein praktisches Tool für das zentralisierte Logging, können Tools wie Sentry mehr als eine wichtige Komponente bei fast allen größeren Projekten darstellen. Logging kann so nützlich sein, wenn man es richtig macht: mit Sentry.

Der Autor

Daniel Haller studierte in Darmstadt Media System Design und arbeitete seitdem bei verschiedenen Digital-Agenturen.
Derzeit ist er als Senior Entwickler bei Scholz & Volkmer in Wiesbaden tätig und betreut einen Kunden aus der Automobilbranche.