Tracing und Logging in Java-basierten Serversystemen

Transkript

1 Student: Philipp Cornelius Plum Matrikel-Nummer: Betreuer: Prof. Dr. Volker Sander 2. Betreuer: Andrè Güldenberg Fachhochschule Aachen Studiengang: Scientific Programming Atos Worldline GmbH Pascalstraße Aachen Atos, das Atos-Logo, Atos Consulting, Atos Worldline, Atos Sphere, Atos Cloud, Atos World- Grid sind eingetragene Warenzeichen von Atos SA. Juni Atos Worldline. Dieses Dokument, sowie Teile des Dokuments dürfen weder reproduziert, kopiert, in Umlauf gebracht werden und/oder verteilt noch zitiert werden, ohne die vorherige schriftliche Zustimmung von Atos Worldline. Vertrauliche Informationen sind Eigentum von Atos Worldline und nur vom Empfänger zu verwenden. DOKUMENTINFORMATION Titel Seminararbeit Thema Dateiname Seminararbeit_ docx Anzahl Seiten 35 Version 1.0 Datum der Version Vertraulichkeit public Autor Philipp C. Plum 2013 Atos Worldline GmbH Version 1.0 / Seminararbeit_ docx - public - Seite: 1 / 35

2 - public - Seite: 2 / 35

3 Inhaltsverzeichnis 1 EINLEITUNG Motivation Ziel Aufbau und Inhalt der Arbeit GRUNDLAGEN Was ist Tracing und Logging? Tracing Logging Warum brauchen wir Tracing und Logging in Java? ANFORDERUNGEN Fachliche Anforderungen Was soll geloggt werden? Was soll getract werden? Technische Anforderungen Funktionale Anforderungen LOGGING-BIBLIOTHEKEN FÜR JAVA Logging-Bibliotheken Die Entscheidung: Logback LOGBACK Logging-Level Konfiguration Konfigurationsdatei Appender ConsoleAppender FileAppender DBAppender AsyncAppender SLF4J Was ist und was kann SLF4J? Wie funktioniert SLF4J? FAZIT UND AUSBLICK Fazit public - Seite: 3 / 35

4 7.2 Ausblick PRAKTISCHE BEISPIELE Beispiel Konfigurationsdatei Beispiel Implementierung und Auto-Konfiguration Aufbau Konfigurationsdatei Java-Quellcode Ergebnis ABBILDUNGSVERZEICHNIS TABELLENVERZEICHNIS LITERATURVERZEICHNIS EIDESSTATTLICHE ERKLÄRUNG public - Seite: 4 / 35

5 1 E i n l e i t u n g 1.1 Motivation Atos Worldline ist ein Spezialist in der Zahlungsverkehrsbranche. Es wurden bereits viele Großprojekte im Software-Bereich entwickelt, welche nun produktiv ihren Einsatz in Rechenzentren führen. Diese Systeme gehen nicht nur mit sensiblen Daten, wie zum Beispiel Kreditkartendaten oder Versichertendaten der elektronischen Gesundheitskarte, um, sondern müssen auch abgesicherte Prozesse und Transaktionen durchführen. Diese Prozesse dürfen weder angreifbar sein noch Fehler produzieren. Aus diesem Grund werden die Systeme vor dem produktiven Einsatz Stresstests unterzogen und während des Einsatzes überwacht. Tritt dennoch ein Fehler auf, müssen die Kollegen den Fehler binnen kürzester Zeit finden, analysieren und beseitigen, um das System wieder produktiv zu schalten und vor Angriffen zu sichern. Damit dies schnell und effizient geschieht, müssen sie den gelaufenen Prozess nachvollziehen können. Das ist der kritische Punkt an dem zum Einsatz kommt. - Was ist passiert? - Wo ist der Fehler? - Welche Daten sind betroffen? - Diese und weitere Fragen können nur beantwortet werden, wenn zuvor der Tracing- und Loggingmechanismus ausreichend definiert, implementiert und konfiguriert wurde. Analyse, Recherche und Archivierung von Abläufen und Aktivitäten sind immer wieder Herausforderungen in produktiven Serversystemen. Erforderliche Daten müssen effizient während der Verarbeitung geschrieben werden. Eine spätere Analyse und Recherche muss ermöglicht werden. 1.2 Ziel In der Seminararbeit sollen die wesentlichen Anforderungen an den Tracing- und Loggingmechanismus aufgezeigt und analysiert werden. Anschließend sollen Werkzeuge (Softwaretools) evaluiert werden, die effizient die erforderlichen Informationen schreiben. Fokussiert werden soll dabei auf quasi Standardbibliotheken (beispielsweise Logback) und deren Fassaden. Die Bibliotheken sollen anhand einfacher Beispiele auch praktisch zur Anwendung kommen. So stellt diese Seminararbeit einen Teil zum KnowHow-Aufbau im Bereich des Tracings und Loggings dar, um auch ältere Logging-Techniken zu ersetzen. - public - Seite: 5 / 35

6 Auch zukünftige Projekte sollen von den Ergebnissen dieser Arbeit profitieren. 1.3 Aufbau und Inhalt der Arbeit Zunächst werden in dieser Arbeit die Grundlagen aufgezeigt. Die Begriffe Tracing und Logging werden erläutert, die Unterschiede deutlich gemacht und darauf aufbauend die Anforderungen dargestellt. Im darauffolgenden Abschnitt werden gängige Logging- Bibliotheken für Java präsentiert. Im Weiteren werden die Logging- Bibliothek Logback und die Logging-Fassade SLF4J fokussiert. Allgemeine Logging-Techniken werden anhand von Logback erklärt und praktisch dargestellt. 2 G r u n d l a g e n Bevor die detaillierten technischen Aspekte angegangen werden, werden im Folgenden die wesentlichen Grundlagen erläutert. 2.1 Was ist Tracing und Logging? Beim werden relevante Daten von einem laufenden System gespeichert. Sowohl zu verarbeitende Daten, als auch das Erreichen einzelner Prozessschritte müssen zur Analyse gesichert werden. Nur so ist das gesamte System im Nachhinein nachzuvollziehen und zu analysieren. Dieser Mechanismus ist sozusagen der Rettungsfallschirm, wenn das System seine Aufgaben nicht mehr korrekt erfüllt. So ist das keine Kleinigkeit, die beim Entwickeln am Rande nebenbei implementiert wird. Gerade in Software-Groß- Projekten ist ein guter Tracing- und Loggingmechanismus notwendig, denn nur durch Vereinheitlichung bleibt das System für das Team überwachbar und im Fehlerfall schnell reparierbar Tracing Unter Tracing versteht man das Protokollieren des technischen Systems. Dazu zählen nicht die zu verarbeitenden Daten an sich. So werden auf der einen Seite Systemmeldung, wie zum Beispiel die nicht Erreichbarkeit einer Datenbank und auf der anderen Seite eine Art Route der Workflows gespeichert. - public - Seite: 6 / 35

7 Durch diese Route kann die Process-Provenance und die-data Provenance, auch Data-Lineage genannt, ermittelt werden. Das heißt die Herkunft des Prozesses bzw. der Daten ist immer ersichtlich. Hier stehen keine zu verarbeitenden Daten im Vordergrund, sondern lediglich die Information, dass nun jener Wegepunkt erreicht wurde oder jenes Hindernis aufgetreten ist. Durch dieses kontinuierliche Tracing kann man den Weg in einem Workflow nachvollziehen und somit erfüllt das Tracing die technischen Anforderungen an das Protokollieren des Systems und die Systemüberwachung. Abb. 1 - Tracing-Route Logging Im Gegensatz zum Tracing stehen beim Logging genau die zu verarbeitenden Daten im Vordergrund. Wer hat was, wann, womit gemacht? Dazu werden sowohl Parameter, Eingangsdateien als auch die Ergebnisse der durchgeführten Prozesse protokolliert. Die fachlichen Anforderungen, welche durch das Logging erfüllt werden müssen, werden im weiteren Verlauf noch detaillierter behandelt. - public - Seite: 7 / 35

8 11:10:12,835 INFO [PoolLogConfigurationRetriever] Datei wurde gefunden. 12:28:15,253 DEBUG [VsdImporterl] Local IP Adress ist :29:05,441 ERROR [ServerImpl] Übergabeparameter hat die falsche Formatierung. Abb. 2 - Beispiel Loggingausgabe 2.2 Warum brauchen wir Tracing und Logging in Java? Jeder Java-Entwickler fängt mit dem System.out.println() an. Mit dieser Methode lassen sich zur Laufzeit eines Programms Daten im Kommandozeilenfenster ausgeben. Und auch dies ist eine Form des Tracings und Loggings. Man verwendet es zur Überprüfung, ob der geschriebene Code auch wirklich das tut, was er machen soll. So wird ein Softwareprojekt sein Leben lang vom begleitet. Log- und Tracemeldungen werden aber nicht nur zur Überprüfung der Funktionalität der Software genutzt, sondern auch um aufgetretene Fehler, sowie getätigte Aktionen zu protokollieren. In einigen Bereichen ist es notwendig alle getätigten Aktionen verlustfrei zu loggen und diese Logmeldungen für mehrere Jahre zu sichern, um auch im Nachhinein genau nachvollziehen zu können warum jenes Ereignis eingetreten ist. So müssen spätestens im Serverbetrieb, wenn die Prozesse beispielsweise als Batchclients laufen, die Logmeldungen effizient weggeschrieben werden, um diese auch zu jeder Zeit analysieren zu können. Da keine manuelle, kontinuierliche Überwachung möglich ist, kann nur der erstellte Log für Recherchen nach einem Fehler verwendet werden. Aus diesem Grund sollte man sich nicht auf System.out.println() verlassen, da dies in der Regel nur eine flüchtige Information im Kommandozeilenfenster darstellt. Diese Ausgabe kann zwar zu anderen Zielen umgeleitet werden, aber in verteilten Systemen ist dies nicht effizient. Logmeldungen müssen besonders in verteilten Serversystemen aus verschiedenen Threads an ein und demselben Punkt gesichert werden. Nur eine Logging-Bibliothek kann dies leicht und komfortabel bewerkstelligen. 3 A n f o r d e r u n g e n Anhand der folgenden Anforderungen werden im weiteren Verlauf der Arbeit die Logging-Bibliotheken bewertet. - public - Seite: 8 / 35

9 3.1 Fachliche Anforderungen Die fachlichen Anforderungen hängen im Wesentlichen vom zu entwickelnden System ab. Für die Qualität der Logmeldungen muss genau analysiert werden, welche Daten erforderlich sind, um das System untersuchen zu können. Im Folgenden wird daher ein grober Überblick über die wichtigsten Punkte zum gegeben Was soll geloggt werden? Attribut Timestamp Klasse/ Prozess Variablen Parameter Beschreibung Jede Logmeldung muss einen Timestamp haben, um auch bei asynchronem Logging sortiert werden zu können. Es sollte die Klasse bzw. der Prozess von dem die Logmeldung übermittelt wird in die Logmeldung geschrieben werden. So ist auch bei ähnlichen Logmeldungen zwischen verschiedenen Klassen/Prozessen die Differenzierbarkeit gewährleistet. Wie im Folgenden beschrieben muss analysiert werden, welche Werte in der Logmeldung benötigt werden, um eine hohe Qualität der Logmeldung zu gewährleisten. Es müssen auch die Parameter mit der ein Prozess gestartet wurde geloggt werden, um Fehler durch falsche Konfiguration ausschließen zu können. Level Tab. 1 - Logging-Meldung Durch die Anzeige des Logging-Levels kann eine kritische Logmeldung manuell oder automatisch schnell ausfindig gemacht werden. Hierbei sollte beachtet werden, dass die Daten so abstrakt wie möglich, aber auch so genau wie nötig protokolliert werden. Sensible Daten, wie zum Beispiel personenbezogene Daten, Kreditkartendaten oder gar Passwörter dürfen nach aktuellen Richtlinien niemals im Klartext zu lesen sein, um einen hohen Datenschutz zu gewährleisten. Hier kann auf IDs, bzw. Kundennummern ausgewichen werden. - public - Seite: 9 / 35

10 3.1.2 Was soll getract werden? Attribut Timestamp Klasse/ Prozess Status Beschreibung Jede Tracemeldung muss einen Timestamp haben, um auch bei asynchronem Tracing sortiert werden zu können. Es sollte die Klasse bzw. der Prozess von dem die Tracemeldung übermittelt wird in die Tracemeldung geschrieben werden. So ist auch bei ähnlichen Tracemeldungen zwischen verschiedenen Klassen/Prozessen die Differenzierbarkeit gewährleistet. Die Meldung sollte zusätzlich den aktuellen Status eines Prozess beinhalten. Fehlermeldungen Fehlermeldungen zählen zu außergewöhnlichen Ereignissen des Systems und müssen getract werden. Level Tab. 2 - Tracing-Meldung Durch die Anzeige des Logging-Levels kann eine kritische Logmeldung manuell oder automatisch schnell ausfindig gemacht werden. 3.2 Technische Anforderungen Wie man aus den fachlichen Anforderungen erkennen kann, wäre es sinnvoll, wenn der Mechanismus die einfache Implementierung verschiedener Logger/Tracer erlaubt. Allgemein sollte die Implementierung so einfach wie möglich sein. Früher wurden die Logmeldungen einfach in Dateien geschrieben. Dies war langsam und mit der Zeit bildeten sich riesige Log-Dateien, welche kaum noch ausgewertet werden konnten. So ist es wichtig, dass die Daten an verschiedene Endpunkte weitergegebenen werden können. Auf dieses Thema gehe ich im Teil Appender noch genauer ein. 3.3 Funktionale Anforderungen - Das darf die Performance der Software nur wenig beeinträchtigen. In eine Datei schreiben ist langsam, aber dennoch dürfen hunderte von Logmeldungen direkt hintereinander nicht den eigentlichen Prozess blockieren. - public - Seite: 10 / 35

11 - Bei sicherheitsrelevanten Prozessen darf kein Log verloren gehen. Es ist eine hohe Ausfallsicherheit zu gewährleisten. - Die geschriebenen Logmeldungen müssen einfach ausgewertet werden können. Bereits bei der Implementierung ist darauf zu achten, dass die Daten später durch geeignete Softwaretools automatisch aufbereitet und ausgewertet werden können. 4 L o g g i n g - B i b l i o t h e k e n f ü r J a v a In diesem Abschnitt werden gängige Bibliotheken kurz erläutert sowie einige Vor- und Nachteile genannt. 4.1 Logging-Bibliotheken Bibliothek Log4j Beschreibung/Vor- und Nachteile Log4j ist die älteste und erfolgreichste hier vorgestellte Logging-Bibliothek. Zuerst war log4j 1996 nur ein Nebenprojekt, doch Ceki Gülcü entwickelte Log4j weiter und brachte es schließlich nach Apache. Log4j wurde so erfolgreich, dass sogar einige Adaptionen zu anderen Programmiersprachen, wie C++ entwickelt wurden. Log4j hat sich über Jahre etabliert und in Großprojekten bewährt, doch Log4j wird nicht mehr weiterentwickelt. Bereits seit einigen Jahren werden lediglich einige wenige Bugfixes geliefert. In einem neuen Projekt sollte man sich nicht auf ein totes Projekt verlassen. Ein weiterer großer Nachteil liegt im Logging- Aufruf. Es werden bei diesem lediglich Strings akzeptiert. So müssen Variablen beim Aufruf in einen String konvertiert und möglicherweise noch mit anderen Strings zusammengebaut werden. Das kostet Zeit. Meist hat man nur bei Debug- Meldungen mehrere Variablen, welche zu einem String zusammengebaut werden müssen und da diese im Produktiv-Betrieb irrelevant sind, sollte dies kein Problem darstellen. Doch die Überprüfung, ob die Logmeldung geloggt werden soll oder nicht, erfolgt erst nach dem Aufruf. Somit werden - public - Seite: 11 / 35

12 die zeitaufwendigen Stringoperationen in jedem Fall ausgeführt. Um dies zu vermeiden muss vor dem Logaufruf eine Abfrage manuell implementiert werden. Diese muss abfragen, ob das Logginglevel des Aufrufes aktiviert ist. Wenn dies nicht der Fall ist, darf der Logaufruf nicht durchgeführt werden. Abb. 3 - Abfrage: Logginglevel aktiviert Dies macht den Quelltext zusätzlich unübersichtlich. Log4j 2 Das neue Konzept für log4j 2 kam nicht von Ceki Gülcü, welcher seine neuen Ideen in logback und SLF4J einbringt, sondern von Ralph Goers. Dieser arbeitet kontinuierlich an der neuen Version. Diese soll auch alle Annehmlichkeiten von modernen Logging-Bibliotheken bieten, wie etwa der verlustfreien automatischen Konfigurationsänderung bei Änderung der Konfigurationsdatei oder den Logger-Aufruf mittels Variablen. Bis zum heutigen Tag ist jedoch noch keine finale Version veröffentlicht worden und eine Beta- Version sollte nicht in einem kommerziellen Großprojekt verwendet werden. Java.util.logging Java.util.logging ist seit der Java-Version 1.4 fest in Java integriert. Es wird also keine zusätzliche Logging-Bibliothek benötigt. Der Nachteil ist aber das rudimentäre Logging. Java.util.logging kann nicht mit log4j, logback oder log4j 2 verglichen werden. Der Funktionsumfang von den anderen Logging-Bibliotheken ist weitaus größer als der von java.util.logging. Somit ist auch java.util.logging für Großprojekte kaum einsetzbar. Logback Wie bereits erwähnt wird logback von log4j- Entwickler Ceki Gülcü mitentwickelt. Somit flossen und fließen die Erfahrungen durch log4j in die Entwicklung von logback ein. Ein Hauptaugenmerk - public - Seite: 12 / 35

13 bei der Neuentwicklung war die Logging- Performance zu steigern. Somit ist logback bis zu 10 mal schneller als log4j. Logback hat sich auch bereits seit einigen Jahren bewährt und dennoch wird rege weiterentwickelt. Dies spricht für ein zukunftssicheres Projekt. Am ehesten lässt sich logback im Funktionsumfang mit log4j 2 vergleichen. Auch hier ist der parametrisierte Logging-Aufruf Standard. Anders als bei log4j 2 ist die automatische Konfigurationsänderung durch Änderung der Konfigurationsdatei allerdings nicht verlustfrei und somit noch nicht ausgereift. Im Weiteren wird diese Problematik nochmals genauer aufgegriffen. Ein weiterer Vorteil von logback ist der Einsatz von SLF4J. Durch die feste Implementation von SLF4J können einerseits Fremdbibliotheken gespart werden und andererseits erhöht sich die Flexibilität bei der Auswahl der Logging-Bibliothek. Eine genauere Beschreibung findet sich im Folgenden. Ein weiterer Vorteil ist die Identifizierung durch ein Mapped Diagnostic Context. Dies ist eine Map namens MDC, welche nicht explizit angelegt werden muss. Es können Schlüsselwörter mit dazugehörigen Werten in die Map gelegt werden. Ein Übergeben der Map bei einem Logaufruf ist nicht notwendig. So kann beispielsweise ein spezieller Name als Wert für eine bestimmte Art von Loggern hinterlegt werden. Dieser kann dann in den Logmeldungen dokumentiert werden. Durch diese Vorgehensweise kann ein Logger mehrere Logger ersetzen. Tab. 3 - Logging-Bibliotheken 4.2 Die Entscheidung: Logback Im weiteren Verlauf wird Logback genauer betrachtet. Die Entwicklung von Log4j wurde bereits seit Jahren eingestellt und die zusätzlichen If-Abfragen im Quelltext erschweren nicht nur einen strukturierten Aufbau des Quelltextes, sondern erhöhen auch den Programmier- - public - Seite: 13 / 35

14 aufwand durch die Überlegung der Notwendigkeit bei jeder einzelnen Logmeldung. Außerdem gilt Logback als komplette Neuentwicklung performanter als Log4j. Gegenüber der Java.util.logging bietet Logback viel mehr Möglichkeiten und Funktionen, um den Logging- Mechanismus leicht den Bedürfnissen des aktuellen Projekts anzupassen. Log4j 2 ist wohl der stärkste Konkurrent für Logback. Es kann alles, was Logback auch kann. Teilweise kann es das sogar besser, aber Log4j 2 ist bis zum heutigen Stand noch in der Beta-Phase und aus diesem Grund muss Log4j 2 für produktive Systeme ausgeschlossen werden. 5 L o g b a c k Logback wurde wie bereits Log4j von Ceki Gülcü ins Leben gerufen und hat wie bereits erwähnt einige interessante Verbesserungen im Gegensatz zu Log4j. Dennoch ähneln sich beide Bibliotheken sehr und so können viele der folgenden Informationen auf Log4j oder anderen Logging-Bibliotheken angewendet werden. 5.1 Logging-Level Logback bietet genauso wie Log4j oder andere Logging-Bibliotheken verschiedene Logging-Level. Durch diese Logging-Level kann konfiguriert werden, welche Logmeldungen zur Laufzeit tatsächlich geloggt werden sollen oder eben auch nicht. Welchen Vorteil bietet diese Konfiguration? Nicht immer müssen alle möglichen Logmeldungen auch geloggt werden. So kann bei einigen Tausend Log-Meldungen, welche deaktiviert wurden, viel Zeit im Ablauf der Prozesse gespart und das gesamte System so performanter gestaltet werden. Ein weiteres Argument für unterschiedliche Loglevel ist die Speicherkapazität des Systems. Tausende Logmeldung können mehrere Gigabyte in kürzester Zeit belegen. Es besteht nicht nur das Problem, dass das System aufgrund mangelnden Speicherplatzes ausfallen kann, sondern nach heutigen PCI-Standards müssen Logmeldungen auch teilweise über 5 Jahre hinweg gespeichert werden. Die Erstellung von Logmeldungen ist somit auch eine Kostenfrage. Aus diesen Gründen sollten im produktiven System nur notwendige Logmeldungen geschrieben werden. - public - Seite: 14 / 35

15 Die folgende Tabelle zeigt welches Loglevel bei welcher Einstellung geloggt wird: Level Einstellung TRACE DEBUG INFO WARN ERROR FATAL OFF TRACE YES NO NO NO NO NO NO DEBUG YES YES NO NO NO NO NO INFO YES YES YES NO NO NO NO WARN YES YES YES YES NO NO NO ERROR YES YES YES YES YES NO NO FATAL YES YES YES YES YES YES NO Tab. 4 - Loggingeinstellungen Level Trace Debug Info Warn Beschreibung Trace ist die niedrigste Logging-Einstellung. Bei dieser Einstellung wird jeder Status, jeder Parameter und jede Variable protokolliert. Das-Trace-Level ist nur für die Entwicklung und gegebenenfalls für den Test geeignet. Das Debug-Level ist ähnlich zum Trace-Level, welches die Informationen jedoch detaillierter sichert. Bei dieser Einstellung sollte alles geloggt werden, was nötig ist, um den Prozess der Applikation nachvollziehen zu können. Zusätzlich werden alle folgenden Logging-Level- Meldungen geloggt. Dieser Logging-Modus sollte nur für die Entwicklung und den Test der Applikation verwendet werden. Im produktiven System ist diese Stufe nicht aktiviert. Info ist eine Stufe höher als Debug und beschränkt das Logging soweit, dass die Debug-Meldungen nicht geloggt werden. Im Info-Level selber sollten wichtige Informationen, wie Server/Prozess gestartet/beendet o- der auch eingehende und ausgehende Nachrichten geloggt werden. Zusätzlich werden auch hier alle höheren Level mitgeloggt. Im Warn-Level werden hingegen kritische Aktionen geloggt, welche jedoch noch keinen Einfluss auf die Ge- - public - Seite: 15 / 35

16 samtfunktionalität des Systems haben. Dazu zählen zum Beispiel Verbindungsabbrüche zur Datenbank oder eine überfüllte Logging-Queue. Error Fatal Als Error werden alle inhaltlichen Fehler oder auch Exceptions in einzelnen Komponenten geloggt, sofern die Applikation weiterlaufen kann. Je nach System sollte bei diesem Level eine Reaktion gefordert und zum Beispiel dem entsprechenden Service-Team eine geschickt werden. Fatale Log-Meldungen bedeuten meist das Aus der Applikation. Es ist ein so gravierender Fehler aufgetreten, dass die Applikation nicht weiterlaufen kann, blockiert oder sich beendet. In diesem Fall ist bei produktiven Systemen eine sofortige Reaktion notwendig. Off Tab. 5 - Logging-Level Off ist die höchste Stufe und bedeutet, dass das Logging ausgeschaltet wird. Diesen Modus sollte man nur mit Bedacht aktivieren, da nun keine Informationen zu laufenden Prozessen geschrieben werden. Bei Performance-Tests hingegen kann man diesen Modus aktivieren, um zu prüfen, wie das Logging die Performance beeinflusst. Allerdings sollte die Zeitmessung nicht auf dem Logging-Mechanismus beruhen, sondern ein eigener Mechanismus gewählt werden. 5.2 Konfiguration Zuvor wurde bereits erwähnt, dass es verschiedene Logging-Level gibt. In jedem großen Projekt befinden sich deswegen tausende von verschiedenen Logmeldungen mit verschiedenen Logging-Leveln. Um diese Flut an Logmeldungen zu organisieren kann Logback im Programmcode oder besser mittels eines Skriptes in Form von XML bzw. Groovy konfiguriert werden. Dies wird in den nächsten Abschnitten näher erläutert Konfigurationsdatei Eine Konfigurationsdatei kann in XML- oder Groovy-Form vorliegen. Diese Konfigurationsdatei definiert Logger, Appender, etc. von Logback. Eine Konfigurationsdatei kann Logback explizit zugewiesen werden oder die Konfigurationsdatei wird einfach in den Classpath - public - Seite: 16 / 35

17 gelegt. Bei der Suche geht Logback nach folgender Vorgehensweise vor: 1. Logback sucht eine Konfigurationsdatei mit dem Namen logback.groovy im Classpath. 2. Wenn zuvor keine Konfigurationsdatei gefunden wurde, sucht Logback nach einer Konfigurationsdatei mit dem Namen logback-test.xml im Classpath. 3. Wenn zuvor keine Konfigurationsdatei gefunden wurde, sucht Logback nach einer Konfigurationsdatei mit dem Namen logback.xml im Classpath. 4. Wenn nun bisher keine Konfigurationsdatei gefunden wurde, konfiguriert sich Logback mit Hilfe von BasicConfigurer selbst. Diese Konfiguration ist allerdings sehr rudimentär und gibt die Logmeldungen lediglich auf der Kommandozeilenkonsole aus. 5. Im Programmcode selber kann diese Konfiguration nun noch überschrieben werden. Dazu werden die bereits bestehenden Appender verändert oder neue Appender erstellt und dem Logger zugewiesen. Diese Art der Konfiguration ist für produktive Systeme allerdings kaum verwendbar, da für jede Änderung an der Konfiguration das Java-Projekt neu kompiliert werden muss. Somit wäre dies eine schlechte Wahl, denn man könnte im produktiven Betrieb das Loglevel nur durch eine neue Lieferung der gesamten Software bearbeiten. Es fällt natürlich auch auf, dass es sowohl eine lockback-test.xml, als auch eine lockback.xml geben kann. So ist es möglich für den Testbzw. Entwicklungsbetrieb ein eigenständiges Skript im Classpath zu haben, um das Original-Skript für das produktive System unverändert zu lassen. Liegen nun beide XML-Konfigurationsdateien im Classpath wird, wie aus der Aufzählung deutlich, die logback-test.xml bevorzugt. Das ist sinnvoll, denn im Normalfall ist Logback in dieser Konfigurationsdatei konfiguriert mehr zu loggen, als im produktiven System. Darüber hinaus erkennt Logback auch Fehler in der aktuell verwendeten Konfigurationsdatei. Im Falle eines Fehlers beim Parsen, wird der Status von Logback im Kommandozeilenfenster ausgegeben und über die defekte Konfigurationsdatei berichtet. Durch die nicht vorhandene Konfiguration wird durch den Logger-Aufruf im Quelltext eine Exception geworfen. Als weiterer Vorteil gegenüber Log4j sei auch hier die automatische Konfigurationsänderung von Logback erwähnt. Im configuration -Tag kann man das scan-attribut auf true setzen und auch dem Attribut scanperiod eine Zeit in Millisekunden, Sekunden, Minuten oder - public - Seite: 17 / 35

18 Stunden geben. So scannt Logback die Konfigurationsdatei im angegebenen Intervall nach Veränderungen und konfiguriert sich neu. Ein Nachteil hierbei ist allerdings, dass Logback anders als Log4j 2 bei dieser Prozedur Logs verlieren kann. Durch diesen Nachteil ist die Funktion kaum verwendbar, da in einem produktiven System sichergestellt werden muss, dass kein Log verloren geht. Wie gravierend dieser Mangel in Erscheinung tritt zeigt das Beispiel 2 in Kapitel 8.2. Abb. 4 - Aufbau XML-Konfigurationsdatei Die Konfigurationsdatei besteht aus 3 Teilen: Zum einen kann der Root-Logger rudimentär konfiguriert werden. Dieser Logger ist immer verfügbar, hat keinen Namen und es kann ihm lediglich das Logging-Level und Appender zugewiesen werden. Des Weiteren können neue Logger mit eigenem Namen erstellt und so beispielsweise fachliches von technischem Loggen getrennt gehalten werden. Der dritte Teil bezieht sich auf die Appender. Das sind die Zielgeber und können den verschiedenen Loggern zugewiesen werden. 5.3 Appender Appender geben das Ziel an, wohin ein Logger seine Logmeldungen schreibt. Einem Logger können mehrere Appender zugewiesen werden. So kann zum Beispiel die Ausfallsicherheit erhöht werden, indem ein Appender zur Datenbank und ein anderer Appender auf eine Datei zeigt. Diese werden demselben Logger zugewiesen. Wenn nun die Datenbank nicht erreichbar ist, werden die Logmeldungen dennoch weiterhin in die Datei geschrieben. Neben selbstgeschriebenen Appendern gibt es auch bereits implementierte. Im Folgenden werden einige der wichtigsten Appender mit ihren Konfigurationsmöglichkeiten kurz erläutert: - public - Seite: 18 / 35

19 5.3.1 ConsoleAppender Der ConsoleAppender ist wohl der einfachste vorkonfigurierte Appender. Alle an ihn gesendeten Logmeldungen werden im Konsolenfenster ausgegeben. Die Ausgabe kann und sollte vor allem mit Hilfe von einem PatternLayoutEncoder formatiert werden. Auf diesen wird im weiteren Verlauf der Arbeit noch genauer eingegangen. Beispiel ConsoleAppender-Konfiguration: Abb. 5 - Konfiguration ConsoleAppender Die dazugehörige Logausgabe im Konsolenfenster: Abb. 6 - ConsoleAppender-Ausgabe FileAppender Der FileAppender schreibt die übermittelte Logmeldung in ein Textdokument. Dabei werden auch im FileAppender die Logmeldungen mit Hilfe von Pattern formatiert. So erreicht man ein gleichbleibendes Layout in der Datei. Dieses vereinfacht die Analyse der Logmeldungen erheblich, da sich das Auge bei einer manuellen Fehlersuche meist nur auf erheblich unterschiedliche Logmeldungen konzentrieren muss. Auf der anderen Seite ist durch das immer gleiche Muster der Logmeldungen eine automatische Auswertung dieser Logdateien möglich. Der FileAppender prüft, ob die in der Konfiguration angegebene Datei bereits vorhanden ist und legt diese an, wenn sie nicht existiert. Wenn sie existiert, werden alle weiteren Logmeldungen standardmäßig an die bereits vorhandene Datei angehängt. Mit Hilfe des append -Property kann der FileAppender jedoch so konfiguriert werden, dass die Datei überschrieben wird. - public - Seite: 19 / 35

20 Abb. 7 - Konfiguration FileAppender RollingFileAppender Der RollingFileAppender verhält sich wie der Fileappender. Die Besonderheit liegt allerdings in der Speicherung der Logdateien. Während die Logdatei durch das Anhängen von Logmeldungen bei dem FileAppender bis ins Unermessliche wächst oder alte Logmeldungen immer weggekürzt werden, kann man den RollingFileAppender so konfigurieren, dass neue Logdateien erstellt werden. Diese Neuerstellung beruht auf der TriggeringPolicy, welche dem Appender anweist die RollingPolicy durchzuführen. Es können eigene Triggering-Policies erstellt werden, aber die meistverwendete ist die SizeBasedTriggeringPolicy, welche bereits implementiert ist und nur noch konfiguriert werden muss. Diese TriggeringPolicy überwacht die Dateigröße der Logdatei und sobald diese den konfigurierten Wert übersteigt, wird zum Beispiel die FixedWindowRollingPolicy ausgeführt. Bei dieser RollingPolicy wird der feste Dateiname bis zu einer konfigurierten Obergrenze hochgezählt. Sobald diese erreicht ist, wird die älteste Logdatei gelöscht. Es gibt auch Kombinationen, wie die TimeBasedRollingPolicy, welche selber die TriggeringPolicy enthält. Je nach Konfiguration wird die Logdatei täglich oder monatlich gesichert. Dazu muss im angegebenen Dateinamen das Datum mittels %d{yyyy-mm-dd} angegeben werden. Diese Angabe bestimmt die tägliche Sicherung. {yyyymm} wäre hingegen eine monatliche Sicherung. In der TimeBaseRollingPolicy kann zusätzlich die TimeBasedFileNamingAndTriggeringPolicy angewendet werden. Durch diesen Zusatz kann auch eine gleichzeitige Kontrolle der Logdatei-Größe vorgenommen werden. Wenn nun die Dateigröße an einem Tag die konfigurierte maximale Größe erreicht hat, wird für diesen Tag eine Sicherung mit fortlaufender Nummer angelegt. Eine weitere Besonderheit von Logback ist die Möglichkeit diese Sicherung zu komprimieren, um so Speicherplatz zu sparen. Dazu wird dem konfigurierten Dateinamen ein.gz angehängt. - public - Seite: 20 / 35

21 Abb. 8 - Konfiguration RollingFileAppender PatternLayoutEncoder Sowohl der ConcoleAppender als auch die FileAppender sind Unterklassen von OutputStreamAppender. Diese Klasse erwartet ein Byte Array. Um nun die Logmeldung in das gewünschte Format zu überführen, werden Encoder eingesetzt. Der bekannteste ist der Pattern- LayoutEncoder, welcher das PatternLayout verwendet, um die Logmeldung zu formatieren. In der folgenden Tabelle sind die wichtigsten Konvertierungswörter aufgelistet. Ein Beispiel findet sich am Ende dieses Abschnittes. Konvertierungswörter %logger %class %date L / line m / msg / message p / le / level Beschreibung Gibt den Namen des Loggers aus. Gibt den vollständig qualifizierten Klassennamen der Klasse, in der der Logging-Aufruf stattfand, aus. Gibt das Datum des Logging-Events aus. Gibt die Zeilennummer des Logging-Aufrufes aus. Gibt die von der Anwendung bereitgestellte Nachricht, die dem Logging-Event zugeordnet ist, aus. Gibt das Level des Logging-Events aus. exception Tab. 6 - Konvertierungswörter Gibt den stack trace der Exception aus, die mit dem Logging-Event verknüpft ist. - public - Seite: 21 / 35

22 Beispiel: Abb. 9 - Beispiel Pattern Die dazugehörige Logausgabe: Abb Beispiel Pattern - Ausgabe DBAppender Der bereits implementierte DBAppender fügt die übergebenen Logmeldungen in Tabellen einer Datenbank ein. Das Schema ist bereits vorgegeben. Es sind 3 Tabellen mit den Namen logging_event, logging_event_property und logging_event_exception. - logging_event: Diese Tabelle ähnelt einer Logdatei. Es werden alle relevanten Daten in die verschiedenen Spalten geschrieben. Attribut Typ Beschreibung timestamp big int Zeitstempel der Logmeldung formatted _message text die Logmeldung logger_name varchar Name des Loggers level_string varchar das konfigurierte Level reference_flag smallint Dieses Feld dient zur automatischen Identifizierung: 1: enthält ein MDCProperty 2: enthält eine Exception 3: enthält sowohl ein MDCProperty als auch eine Exception caller_filename varchar Name der Datei, die den Logaufruf enthält. caller_class varchar Die Klassen, die den Logaufruf - public - Seite: 22 / 35

23 enthält. caller_method varchar Der Name der Methode, die den Logaufruf enthält. caller_line char Die Zeile in der die Logginganfrage aufgerufen wurde. event_id int Die Datenbank-ID des Logging- Events. Tab. 7 - Datenbank-Tabelle: logging_event - logging_event_property: Die Werte, also key und value, von dem oben erwähnten MDCProperty werden nicht direkt in die logging_event Tabelle geschrieben, sondern in die logging_event_property. Diese enthält nur key, value und die dazugehörige event_id der Logmeldung. Attribut Typ Beschreibung event_id int Die Datenbank-ID des Logging- Events. mapped_key varchar Der Schlüssel der MDCProperty. mapped_value text Der Wert der MDCProperty. Tab. 8 - Datenbank-Tabelle: logging_event_property - logging_event_exception: Sobald eine Fehlermeldung auftritt, wird diese in die logging_event_exception Tabelle geschrieben. Neben der zugehörigen event_id der Logmeldung enthält diese die Zeilennummer des Stack-Traces und die Zeile selbst. Attribut Typ Beschreibung event_id Int Die Datenbank-ID des Logging-Events. i smallint Der Zeilenindex des Stacktraces. trace_line varchar Die zum Zeilenindex zugehörige Zeile. Tab. 9 - Datenbank-Tabelle: logging_event_exception - public - Seite: 23 / 35

24 Bei einem einfach konfigurierten DBAppender besteht allerdings ein großes Performance-Problem. Es besteht lediglch eine einzelne Verbindung zur Datenbank, welche wie ein Flaschenhals auf die Logmeldungen wirkt. Wenn man einen DBAppender beispielsweise auf folgende Art und Weise konfiguriert, werden 5 Sekunden benötigt, um 500 Logmeldungen in eine MySQL-Datenbank zu schreiben. Das sind 10 Millisekunden pro Logmeldung. In einem Softwareprojekt mit mehreren Tausenden Logmeldungen ist diese Zeit nicht akzeptabel. Abb Konfiguration DBAppender Aus diesem Grund sollte eine externe Bibliothek verwendet werden, um einen Verbindungspool verwenden zu können. c3p0 ist eine solche Bibliothek, welche von den Logback-Entwicklern selbst empfohlen wird. Durch diese Bibliothek werden mehrere Verbindungen zur Datenbank aufgebaut und so wird ein Stau der Logmeldungen verhindert. Die Bibliothek muss sich lediglich im Classpath befinden und in der Konfiguration wie im Folgenden eingebunden werden. Abb Konfiguration DBAppender mit c3p AsyncAppender Der AsyncAppender ist kein Appender wie die bisher vorgestellen Appender. Die Logmeldungen werden an den AsyncAppender gesendet, vom Asyncappender gegebenenfalls zwischengespeichert und an ei- - public - Seite: 24 / 35

25 nen anderen Appender weitergeleitet. Das Besondere an ihm ist seine Zwischenspeicherung in einer Queue. Sobald mehrere Threads oder Clients auf einen Logger zugreifen kann es zu gegenseitigen Warteproblemen führen. Ein Beispiel: Wie bereits erwähnt benötigt ein FileAppender eine gewisse Zeit, um die Logmeldungen in eine Datei zu schreiben. Wenn zwei Threads nun ihre Logmeldungen direkt an den FileAppender leiten würden, könnten sich die beiden Threads gegenseitig blockieren. Wird der FileAppender allerdings wie im Folgenden gezeigt in einen AsyncAppender eingebunden, speichert dieser die Logmeldungen temporär und leitet sie nacheinander an den FileAppender weiter. Die Größe der Queue kann bei der Konfiguration angegeben werden. Standardmäßig ist sie für 256 Logmeldungen ausgelegt. Eine Besonderheit von Logback ist das automatische Ignorieren von Logmeldungen, sobald ein konfigurierter Wert erreicht ist. In diesem Fall werden nur noch Meldungen mit dem Level Warn oder Error in der Queue gespeichert und weitergeleitet. Dies trägt wieder zur Performance bei, denn wenn die Queue voll ist, wird wiederum der Sender der Logmeldung blockiert. Standardmäßig werden ab einer 80 prozentigen Füllung der Queue alle Trace, Debug, und Info Meldungen verworfen. Bei dieser Funktion ist allerdings Vorsicht geboten. In Systemen bei denen verlustfreies Logging gefordert ist, dürfen keine Logmeldungen verworfen werden. Bei diesen Systemen befinden sich auch in Info- Meldungen meist wichtige Informationen, welche über Jahre hinweg gespeichert werden müssen. Abb Konfiguration Async-Appender - public - Seite: 25 / 35

26 6 S L F 4 J Nachdem nun Tracing, Logging und Logback behandelt wurden, wird in diesem Abschnitt die Logging-Fassade SLF4J vorgestellt. 6.1 Was ist und was kann SLF4J? Um komplexe Softwaresysteme handhaben zu können, ist eine Modularisierung und lose Kopplung der einzelnen Bestandteile nötig. Hierzu wird in einer Schnittstellendefinition der Kontrakt festgelegt. Dazu zählen unter anderem öffentliche Methoden oder auch geltende Parameter. Gegen eine solche Schnittstelle kann nun die eigentliche Komponente entwickelt werden. Durch diese Einführung des Kontrakt-Konzeptes entsteht eine lose Verbindung zwischen den Komponenten. SLF4J heißt Simple Logging Facade for Java und ist eine solche Schnittstelle für Logging-Bibliotheken. Durch SLF4J ist man in der Lage die verwendete Logging-Bibliothek mit sehr wenig Aufwand zu tauschen. Es stellt eine Schnittstelle zwischen dem eigentlichen Code und der Logging-Bibliothek, wie beispielsweise Logback, dar. SLF4J unterstützt aber nicht nur Logback, sondern alle gängigen Logging-Bibliotheken, wie log4j, log4j 2 oder java.util.logging. Diese Option scheint erst einmal nicht so wichtig zu sein, aber wenn ein Projekt über mehrere Jahre läuft und festgestellt wird, dass die verwendete Logging-Bibliothek den Bedürfnissen nicht mehr gerecht wird, kann diese einfach ausgetauscht werden. 6.2 Wie funktioniert SLF4J? Im eigenen Quellcode bindet man nur die SLF4J-Biliotheken ein und verwendet deren Methoden. Diese arbeiten mit Parameterübergabe, so dass beispielsweise das langsame String zusammenbauen der Strings von log4j nicht auftritt. Selbst wenn man nun log4j hinter der Logging-Fassade verwendet muss man den Logaufruf nicht in eine IF- Abfrage klammern, um das Performance-Problem zu umgehen. Dies erledigt nun SLF4J automatisch. SLF4J wird selber nicht konfiguriert. Die zu verwendende Logging- Bibliothek erkennt SLF4J automatisch anhand der verwendeten Adapter-Bibliothek bzw. direkt anhand der im Classpath zur Verfügung gestellten Logging-Bibliothek. Die Tracer und Logger werden mittels eines Groovy oder XML Skriptes für die Logging-Bibliothek selbst konfiguriert. Um die Flexibilität - public - Seite: 26 / 35

27 von SLF4J nun auszunutzen, muss bei einem Tausch der Logging- Bibliothek ebenfalls die Konfigurationsdatei getauscht werden. Folgendes Schaubild stellt den Aufbau des Logging-Mechanismus dar. Im Quellcode werden wie bereits beschrieben die SLF4J-API eingebunden. Darauf folgt entweder eine Adaption-Bibliothek, welche die Schnittstelle zur eigentlichen Logging-Bibliothek darstellt, oder die Logging-Bibliothek selber. Denn wie im Fall von Logback, können diese SLF4J nativ implementieren und von den Methoden ableiten, um so direkt ohne die Adaptionsebene verwendet werden zu können. SLF4J verbunden mit logback-classic SLF4J verbunden mit log4j SLF4J verbunden mit log4j2 SLF4J verbunden mit java.util.logging Applikation Applikation Applikation Applikation SLF4J API SLF4J API SLF4J API SLF4J API slf4j-api.jar slf4j-api.jar slf4j-api.jar slf4j-api.jar Unterliegendes Logging- Framework Adaption layer slf4j-log4j12.jar Adaption layer slf4j-log4j2.jar Adaption layer slf4j-jdk14.jar logback-classic.jar logback-core.jar Unterliegendes Logging- Framework Unterliegendes Logging- Framework Unterliegendes Logging- Framework log4j.jar log4j2.jar JVM runtime Abb SLF4J Übersicht 7 F a z i t u n d A u s b l i c k Im Folgenden wird ein Überblick der Resultate dieser Arbeit aufgezeigt und ein Ausblick auf mögliche Vertiefung der Ergebnisse dieser Arbeit gegeben. 7.1 Fazit Das einer Software ist genauso wichtig wie das Testen. Nur wenn das sorgfältig und mit Bedacht - public - Seite: 27 / 35

28 implementiert wurde, kann ein Software-Projekt im Fall eines Fehlers effizient analysiert werden. Dabei ist es nicht nur wichtig, dass überhaupt etwas geloggt wird, sondern auch was und wie. Eine Logmeldung muss alle nötigen Elemente enthalten, um aussagen zu können von wem, wann und warum diese Logmeldung geschrieben wurde. Ein einfaches System.out.println() reicht hier nicht mehr aus. Nur ein performantes und gut konfigurierbares Logging-Tool sollte hier eingesetzt werden. Logback erfüllt diese Aufgaben souverän. Bereits seit dem Jahr 2006 ist Logback verfügbar und kann so eine gut strukturierte Dokumentation bieten. Die aktive Weiterentwicklung des OpenSource-Projektes sichert ein stabiles System und bietet auch zukünftig Bugfixes sowie Erweiterungen. Sicherlich konnten nicht alle Funktionalitäten von Logback in dieser Seminararbeit gezeigt werden, aber die bereits gezeigten Funktionalitäten beweisen das große Potential von Logback. Auch wenn sicher noch ein paar Verbesserungspunkte, wie der automatischen Konfigurationsänderung, existieren, gibt es in der Regel eine passende Workaround-Lösung. Die Kombination von Logback und SLF4J ist hervorragend geeignet die Implementierung vom tatsächlichen Logging zu trennen, aber auch mit anderen Logging-Bibliotheken arbeitet SLF4J erfolgreich zusammen. Es ist ein Gewinn an Flexibilität in der Software und so ist auch eine Änderung der Logging-Bibliothek noch nach Jahren leicht zu bewerkstelligen. 7.2 Ausblick Die Logmeldungen können mit diesen Werkzeugen in Logdateien oder Datenbanken geschrieben werden. Was sind die weiteren Schritte? Die Seminararbeit kann Grundlage für vertiefende Projekte in diesem Bereich bilden. Die manuelle Auswertung der Logdaten ist nicht State oft the Art. In kommenden Projekten kann beispielsweise der Schwerpunkt auf die automatische Aufbereitung und Auswertung gelegt werden. In diesem Zusammenhang wäre aufbauend auf den Wahlkurs Entwicklung mobiler Applikationen ein Serversystem zur Analyse und Aufbereitung von Logmeldungen mit dazugehörigem Mobilclient zur Meldung von kritischen Informationen denkbar. 8 P r a k t i s c h e B e i s p i e l e 8.1 Beispiel Konfigurationsdatei - public - Seite: 28 / 35

29 Dies ist eine XML-Konfigurationsdatei für einen einfachen File- Appender. Abb Beispiel-Konfigurationsdatei 8.2 Beispiel Implementierung und Auto-Konfiguration In diesem Beispiel wird nicht nur eine Implementierung eines Loggers dargestellt, sondern auch die Auto-Konfiguration mittels dem scan - Attribut präsentiert und ausgewertet. Es soll automatisch erkannt werden, ob die Konfigurationsdatei geändert wurde und diese dann geladen werden soll. Weiterhin wird gezeigt, dass diese Funktionalität noch nicht ausgereift ist, da einige Logmeldungen verloren gehen Aufbau Es wird ein Logger angelegt, eine Variable in einer Schleife hochgezählt und diese mittels des Loggers in eine Datei geschrieben. Während dieses Prozesses wird manuell der Name der Logdatei in der Konfiguration 2-mal geändert. - public - Seite: 29 / 35

30 8.2.2 Konfigurationsdatei Abb Konfigurationsdatei mit scan-attribut Jede Sekunde wird kontrolliert, ob sich die Konfigurationsdatei geändert hat. Die Logmeldungen werden in die testfile.log-datei geschrieben. Zur Laufzeit wird der Name der Logdatei manuell in testfile1.log bzw. testfile2.log geändert Java-Quellcode Abb Java-Quellcode Logging Es wird ein Logger über die SLF4J-Schnittstelle angelegt. Dieser wird durch die obige Konfiguration von FileLogger konfiguriert. In einer Schleife wird eine Integer-Variable von 0 hochgezählt und geloggt. - public - Seite: 30 / 35

31 8.2.4 Ergebnis 1. Logdatei Logdatei 1. Logdatei Abb testfile.log Abb testfile1.log Abb testfile2.log Zwischen der 1. und 2. Logdatei wurde der Name der Logdatei zur Laufzeit in der Konfiguration geändert. Ebenfalls passierte dies zwischen der 2. und 3. Logdatei. Wie man sieht, sind zwischen der 1. und 2. Logdatei ca Logmeldungen verloren gegangen. Zwischen der 2. und 3. Logdatei sind es sogar ca Logmeldungen. Dieses Ergebnis zeigt, dass die automatische Konfigurationsänderung bei Änderungen der Konfigurationsdatei in produktiven Systemen in denen kein Log verloren gehen darf keine Verwendung finden kann. - public - Seite: 31 / 35

32 9 A b b i l d u n g s v e r z e i c h n i s Abb. 1 - Tracing-Route... 7 Abb. 2 - Beispiel Loggingausgabe... 8 Abb. 3 - Abfrage: Logginglevel aktiviert Abb. 4 - Aufbau XML-Konfigurationsdatei Abb. 5 - Konfiguration ConsoleAppender Abb. 6 - ConsoleAppender-Ausgabe Abb. 7 - Konfiguration FileAppender Abb. 8 - Konfiguration RollingFileAppender Abb. 9 - Beispiel Pattern Abb Beispiel Pattern - Ausgabe Abb Konfiguration DBAppender Abb Konfiguration DBAppender mit c3p Abb Konfiguration Async-Appender Abb SLF4J Übersicht Abb Beispiel-Konfigurationsdatei Abb Konfigurationsdatei mit scan-attribut Abb Java-Quellcode Logging Abb testfile.log Abb testfile1.log Abb testfile2.log T a b e l l e n v e r z e i c h n i s Tab. 1 - Logging-Meldung... 9 Tab. 2 - Tracing-Meldung Tab. 3 - Logging-Bibliotheken Tab. 4 - Loggingeinstellungen Tab. 5 - Logging-Level Tab. 6 - Konvertierungswörter Tab. 7 - Datenbank-Tabelle: logging_event Tab. 8 - Datenbank-Tabelle: logging_event_property Tab. 9 - Datenbank-Tabelle: logging_event_exception public - Seite: 32 / 35

33 11 L i t e r a t u r v e r z e i c h n i s - LOGBack: The logback manual [Abruf: ] - LOGBack: Logback-Parent API [Abruf: ] - DZone-JAVALOBBY: Which one is faster? Log4j or Logback? [Abruf: ] - LOGBack: Reasons to prefer logback over log4j [Abruf: ] - JDJ: Cover Story: Log4j vs java.util.logging [Abruf: ] - Patrick Gotthard: logback der Nachfolger von log4j [Abruf: ] - SLF4J: SLF4J user manual [Abruf: ] - Javadocs: Java Logging Overview erview.html [Abruf: ] - LOG4J: Project history /docs/history.html [Abruf: ] - WebApp-Blogger: Logging-Frameworks in Java ein kleiner Überblick [Abruf: ] - alsternah: Java-Logging mit logback [Abruf: ] - JAXenter: Das Comeback des Jahres: Apache log4j Jahres-Apache-log4j html [Abruf: ] - public - Seite: 33 / 35

34 - LOG4J2: Overview [Abruf: ] - LOG4J2: Download Apache Log4j 2 [Abruf: ] - public - Seite: 34 / 35

35 12 E i d e s s t a t t l i c h e E r k l ä r u n g Hiermit versichere ich, dass ich die Seminararbeit mit dem Thema selbstständig verfasst und keine anderen als die angegebenen Quellen und Hilfsmittel benutzt habe, alle Ausführungen, die anderen Schriften wörtlich oder sinngemäß entnommen wurden, kenntlich gemacht sind und die Arbeit in gleicher oder ähnlicher Fassung noch nicht Bestandteil einer Studien- oder Prüfungsleistung war. Name: Philipp Cornelius Plum Heinsberg, den Unterschrift der Studentin / des Studenten - public - Seite: 35 / 35