Besser zentral: Professionelles Logging

Beispiel, Teil 2

Anzeige

Der Logfaces-Client wird von der Website des Herstellers heruntergeladen. Er baut auf Eclipse RCP auf. Beim ersten Start interessiert er sich für die URL und den Port des Log-Servers. Beim Einsatz von LDAP fragt er noch nach Nutzername und Kennwort.

Einmal gestartet, wählt der Nutzer zunächst die passende Sicht auf die Daten. Abbildung 6 zeigt, wie mehrere Anwendungen (rechts oben) ausgewählt wurden, um deren Log-Einträge in einer Ansicht anzeigen zu lassen (Mitte). Dort taucht auch der apache-ftpserver-dev mit dem zuvor konfigurierten log4j auf.

In Farbe und aufs Wesentliche reduziert, so werden Zusammenhänge und Details verständlich (Abb. 6).

Die Liste enthält pro Zeile einen Log-Eintrag. Sie gibt dem Nutzer vor allem einen zeitlichen Überblick. Er kann definieren, welche Spalten er sehen möchte sowie in welcher Reihenfolge und Breite diese dargestellt werden sollen. In der Abbildung sind zwischen zahlreichen Log-Ereignissen auf Info-Level auch zwei Warnungen sowie ein Error-Eintrag zu sehen. Letzterer ist ausgewählt, und so wird der Stack Trace in der Detail-Ansicht "Exception" (Mitte unten) angezeigt. Über die Ansicht "Event Details" rechts davon kann sich der Anwender weitere Details anzeigen lassen, für die die Übersichtsliste keinen Platz bietet.

Allein die gemeinsame Sicht auf zeitlich zusammenhängende Log-Einträge der Clients und des Servers vereinfacht das Auffinden und Lesen schon wesentlich. Die farbliche Kategorisierung hilft beim Auffinden wichtiger Ereignisse. Insbesondere ist die einheitliche Auflistung der Einträge deutlich übersichtlicher als die homogenen Textmassen herkömmlicher Log-Dateien (vgl. Abb. 7).

In herkömmlichen Log-Dateien sind wichtige Informationen nicht offensichtlich (Abb. 7).

Auf Grundlage der angezeigten Einträge kann der Nutzer eine Reihe weiterer praktischer Filtermöglichkeiten nutzen (vgl. Abb. 8). Im Beispiel könnte interessieren, was im Zeitfenster plusminus eine Minute um das Ereignis passiert ist. Dabei könnten alle Ereignisse interessant sein oder etwa bloß jene, die laut dem MDC-Feld userName denselben Nutzer betreffen.

Mit Textdateien schier undenkbar: Filtern um ein Ereignis herum (Abb. 8)

Auf diese Weise lassen sich zeitlich und kontextuell zusammengehörige Einträge schnell und einfach herausarbeiten. Neben den gezeigten Analysewerkzeugen existieren noch weitere zur Suche, Filterung und grafischen Auswertung.

Es ist möglich und sinnvoll, ein Anwendungslogging zu einem zentralen Logging auszubauen. Nicht nur sind Logs auf diese Weise ohne nennenswerten Aufwand zu jeder Phase im Lebenszyklus der Anwendung zugänglich, sie sind auch einfach lesbar. Als gemeinsames Werkzeug von Betrieb und Entwicklung baut das zentrale Logging eine Brücke, die zu einer frühen gemeinsamen Abstimmung einlädt. Dennoch kann das zentrale Logging lediglich ein Vehikel sein. Was zählt, sind die passenden Inhalte.

Vor diesem Hintergrund stellt sich die eher grundsätzliche Frage: Wo sollte man was loggen? Die Antwort auf diese Frage ist natürlich abhängig von der Anwendung. Dennoch lassen sich einige Best Practices aufzählen:

  • Wer erwartet was: Einen guten Einstieg bereitet das Erstellen einer kurzen Liste von Stakeholdern, die einen Nutzen aus den Logs ziehen wollen. Zu ihnen gehören meistens Operatoren/Systemadministratoren, gegebenenfalls aber auch Auditoren oder Analysten z. B. aus dem Marketing. Zu jeder Rolle sollte deutlich werden, welche Erkenntnisse sie aus den aufgezeichneten Daten gewinnen möchte. Beispiele sind fachliche Protokollierungen, wer wann was mit welchen Daten gemacht hat, eine Heartbeat-Ausgabe für das Monitoring oder wann, wie oft und wo auf der Welt welche Produktseiten angesehen werden.
  • Abbildung der Struktur: Jede Dimension physischer, logischer und dynamischer Aufteilung sollte sich in jedem Log-Eintrag widerspiegeln. Zur physischen Aufteilung zählt, um welches System es sich handelt (z. B. Backend, Datenbank) und auf welcher Maschine es läuft. Hinsichtlich der logischen Aufteilung sollten Verweise auf die Komponente sowie die Klasse innerhalb eines Systems existieren. Dynamische Aufteilungen ergeben sich bei parallel arbeitenden Systemen (etwa Mehrnutzersysteme und parallele Berechnungen). Diese Aufteilungen bestehen nur zur Laufzeit und machen das Lesen von Log-Einträgen oft besonders kniffelig. Aus dem Ausführungskontext sollten die Log-Einträge daher eine möglichst durchgängige Information anzeigen, die den Kontrollfluss identifiziert und ihn nachvollziehbar macht. Bewährte Beispiele sind hier Session- und User-IDs oder Nutzer-Pseudonyme, Request-IDs sowie die eindeutige Nummer eines Worker aus einem Pool. Das Mittel der Wahl sind hier diagnostische Kontexte (siehe oben).
  • DRY (Don't repeat yourself): Was für den Code der Anwendung gilt, trifft auch für das Logging zu. Der Code zum Sammeln von Strukturinformationen für die Log-Einträge und zum Schreiben der Logs verunreinigt den eigentlichen Code, der eine fachliche oder technische Aufgabe erledigt. Daher sollte ein Großteil des Logging-Codes nach Möglichkeit zentral an einer Stelle platziert werden. Abhängig von der konkreten Architektur der Anwendung kann das in Aspekten, selbst definierten Annotationen, Interzeptoren oder in einer Oberklasse geschehen.
  • Einheitlichkeit: Die Entwickler sollten sich darüber verständigt haben, wann, was und mit welchem Level protokolliert wird. Nur für gleichartige Belange lässt sich der Code für das Logging nach dem DRY-Prinzip zentralisieren. An vielen Stellen müssen Log-Einträge so erzeugt werden, dass sie eine individuelle Information, Warnung oder ein Zwischenergebnis wiedergeben sollen. Damit Logs über alle Teile des Anwendungssystems hinweg konsistent bleiben, lohnt sich ein Logging-Konzept. In der Regel braucht es dazu nicht mehr als eine Handvoll einfacher Regeln. Eine könnte beispielsweise lauten: "An jedem Zweig im Programm (bei Fallunterscheidungen und vor Schleifen) wird auf Level DEBUG geloggt, welcher Pfad durchlaufen wird."
  • Werkzeug der Wahl: Das Lesen und Analysieren zentraler Logs auch zusammen mit den Kollegen aus dem Betrieb sollte früh zur Gewohnheit werden. Zentrales Logging sollte sich bereits zur Entwicklungszeit zum Debugging und der Fehlerverfolgung etablieren. Auf diese Weise fallen fehlende Informationen auf und das Logging lässt sich sukzessive verbessern. Die Entwickler lernen typische Fehlermuster ihrer Anwendung kennen. Diese Erkenntnisse können sie direkt oder in einem Betriebshandbuch an die Administratoren weitergeben. Diese Operatoren erhalten ihrerseits einen echten Mehrwert, wenn ihre Anforderungen berücksichtigt werden und ihnen das zentrale Logging die für das Monitoring relevanten Daten passend serviert.
Anzeige