CodeGym /Java-Blog /Random-DE /Java-Protokollierung
Autor
Jesse Haniel
Lead Software Architect at Tribunal de Justiça da Paraíba

Java-Protokollierung

Veröffentlicht in der Gruppe Random-DE
Hallo! Beim Verfassen der Lektionen lege ich besonderen Wert darauf, ob es sich um ein bestimmtes Thema handelt, das in der Praxis unbedingt erforderlich sein wird. Also, HÖRT ZU! Das Thema, das wir heute behandeln, wird Ihnen vom ersten Tag Ihrer Anstellung an bei all Ihren Projekten von Nutzen sein. Wir werden über Java Logging sprechen. Dieses Thema ist überhaupt nicht kompliziert (ich würde sogar sagen: einfach). Aber Sie werden bei Ihrem ersten Job genug offensichtliche Dinge haben, über die Sie sich Sorgen machen müssen, also ist es besser, sie jetzt gründlich zu verstehen :) Nun, fangen wir an.

Was ist Protokollierung in Java?

Beim Protokollieren werden Daten über den Betrieb eines Programms aufgezeichnet. Der Ort, an dem wir diese Daten aufzeichnen, wird als „Protokoll“ bezeichnet. Es stellen sich sofort zwei Fragen: Welche Daten werden wohin geschrieben? Beginnen wir mit dem „Wo“. Sie können an vielen verschiedenen Stellen Daten über die Arbeit eines Programms schreiben. Während Ihres Studiums verwenden Sie beispielsweise häufig System.out.println()um Daten an die Konsole auszugeben. Das ist tatsächlich Protokollierung, wenn auch in seiner einfachsten Form. Dies ist natürlich für Benutzer oder ein Produktsupportteam nicht sehr praktisch: Sie möchten natürlich keine IDE installieren und die Konsole überwachen :) Es gibt ein gebräuchlicheres Format zum Aufzeichnen von Informationen: Textdateien. Menschen können Daten in diesem Format viel besser lesen, und sicherlich ist es viel bequemer zum Speichern von Daten! Nun die zweite Frage: Welche Programmdaten sollen protokolliert werden? Das liegt ganz bei Ihnen! Das Protokollierungssystem von Java ist sehr flexibel. Sie können es so konfigurieren, dass alles protokolliert wird, was Ihr Programm tut. Das ist einerseits gut. Aber stellen Sie sich andererseits vor, wie groß die Protokolle von Facebook oder Twitter wären, wenn sie alles darin schreiben würden. Diese großen Unternehmen verfügen wahrscheinlich über die Möglichkeit, so viele Daten zu speichern. Aber stellen Sie sich vor, wie schwierig es wäre, in 500 Gigabyte Textprotokollen Informationen zu einem kritischen Fehler zu finden? Das wäre schlimmer als die Suche nach der Nadel im Heuhaufen. Dementsprechend kann Java so konfiguriert werden, dass nur Fehlerdaten protokolliert werden. Oder auch nur kritische Fehler! Allerdings ist es nicht ganz korrekt, von Javas nativem Protokollierungssystem zu sprechen. Tatsache ist, dass Programmierer eine Protokollierung benötigten, bevor diese Funktionalität zur Sprache hinzugefügt wurde. Als Java seine eigene Protokollierungsbibliothek einführte, nutzte bereits jeder die log4j-Bibliothek. Die Protokollgeschichte in Java ist tatsächlich sehr lang und aufschlussreich. Kurz gesagt, Java verfügt über eine eigene Protokollierungsbibliothek, aber fast niemand verwendet sie :) Später Als mehrere verschiedene Protokollierungsbibliotheken auftauchten und von Programmierern verwendet wurden, traten Kompatibilitätsprobleme auf. Um zu verhindern, dass das Rad in einem Dutzend verschiedener Bibliotheken mit unterschiedlichen Schnittstellen neu erfunden wird, wurde das abstrakte SLF4J-Framework („Service Logging Facade For Java“) erstellt. Es heißt abstrakt, denn selbst wenn Sie die Methoden von SLF4J-Klassen verwenden und aufrufen, nutzen sie unter der Haube tatsächlich alle Protokollierungsframeworks, die es zuvor gab: log4j, das Standard-java.util.logging und andere. Wenn Sie irgendwann eine bestimmte Funktion von Log4j benötigen, die in anderen Bibliotheken fehlt, Sie Ihr Projekt aber nicht direkt mit dieser Bibliothek verknüpfen möchten, verwenden Sie einfach SLF4J. Und dann lassen Sie es die Log4j-Methoden aufrufen. Wenn Sie Ihre Meinung ändern und entscheiden, dass Sie die Log4j-Funktionen nicht mehr benötigen, müssen Sie nur die „hier und die Log4j-Bibliothek hier . Als nächstes entpacken Sie das Archiv und fügen die JAR-Dateien mit IntelliJ IDEA zum Klassenpfad hinzu. Menüpunkte: Datei -> Projektstruktur -> Bibliotheken Wählen Sie die erforderlichen JAR-Dateien aus und fügen Sie sie dem Projekt hinzu (die von uns heruntergeladenen Archive enthalten viele JAR-Dateien – sehen Sie sich die Bilder an, um die benötigten Dateien zu sehen). Beachten Sie, dass diese Anleitung für diese Schüler gedacht Warum wir Protokollierung brauchen – 2Warum wir Protokollierung brauchen – 3ist die nicht wissen, wie man Maven benutzt. Wenn Sie wissen, wie man Maven verwendet, ist es normalerweise besser (viel einfacher), dort anzufangen. Wenn Sie Maven verwenden , fügen Sie diese Abhängigkeit hinzu:

    	<dependency>
            <groupId>org.apache.logging.log4j</groupId>
            <artifactId>log4j-slf4j-impl</artifactId>
            <version>2.14.0</version>
    	</dependency>
Großartig! Wir haben die Einstellungen herausgefunden :) Mal sehen, wie SLF4J funktioniert. Wie stellen wir sicher, dass die Arbeit des Programms irgendwo aufgezeichnet wird? Dazu benötigen wir zwei Dinge: Logger und Appender. Beginnen wir mit dem ersten. Ein Logger ist ein Objekt, das die vollständige Kontrolle über die Protokollierung bietet. Das Erstellen eines Loggers ist sehr einfach: Wir tun dies mit den statischen LoggerFactory.getLogger()- Methoden. Der Methodenparameter ist die Klasse, deren Vorgang protokolliert wird. Lassen Sie uns unseren Code ausführen:

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

public class MyTestClass {

   public static final Logger LOGGER = LoggerFactory.getLogger(MyTestClass.class);

   public static void main(String[] args) {

       LOGGER.info("Test log entry!!!");
       LOGGER.error("An error occurred!");
   }
}
Konsolenausgabe:

ERROR StatusLogger No Log4j 2 configuration file found. Using default configuration (logging only errors to the console), or user programmatically provided configurations. Set system property 'log4j2.debug' to show Log4j 2 internal initialization logging. See https://logging.apache.org/log4j/2.x/manual/configuration.html for instructions on how to configure Log4j 2 15:49:08.907 [main] ERROR MyTestClass - An error occurred!
Was sehen wir hier? Zuerst sehen wir eine Fehlermeldung. Das liegt daran, dass uns jetzt die nötigen Einstellungen fehlen. Dementsprechend ist unser Logger derzeit nur in der Lage, Fehlermeldungen (ERROR) und nur auf der Konsole auszugeben. Die Methode logger.info() hat nicht funktioniert. Aber logger.error() hat es getan! Auf der Konsole sehen wir das aktuelle Datum, die Methode, bei der der Fehler aufgetreten ist ( main), das Wort „ERROR“ und unsere Nachricht! ERROR ist die Protokollierungsstufe. Wenn ein Protokolleintrag mit dem Wort „ERROR“ gekennzeichnet ist, liegt im Allgemeinen an dieser Stelle im Programm ein Fehler vor. Wenn der Eintrag mit dem Wort „INFO“ gekennzeichnet ist, stellt die Meldung lediglich aktuelle Informationen über den normalen Betrieb des Programms dar. Die SLF4J-Bibliothek verfügt über viele verschiedene Protokollierungsstufen, mit denen Sie die Protokollierung flexibel konfigurieren können. Es ist alles sehr einfach zu verwalten: Die gesamte erforderliche Logik ist bereits in der Java Logger- Klasse enthalten. Sie müssen lediglich die entsprechenden Methoden aufrufen. Wenn Sie eine Routinenachricht protokollieren möchten, rufen Sie die Methode logger.info() auf . Für eine Fehlermeldung verwenden Sie logger.error() . Für eine Warnung verwenden Sie logger.warn()

Lassen Sie uns nun über Appender sprechen

Ein Appender ist der Ort, an dem Ihre Daten gespeichert werden. In gewisser Weise das Gegenteil einer Datenquelle, also „Punkt B“. Standardmäßig werden Daten an die Konsole ausgegeben. Beachten Sie, dass wir im vorherigen Beispiel nichts konfigurieren mussten: Der Text wurde in der Konsole angezeigt und der Logger der Log4j-Bibliothek kann nur Meldungen der Ebene ERROR an die Konsole ausgeben. Offensichtlich ist es für Benutzer bequemer, Protokolle in einer Textdatei zu lesen und zu schreiben. Um das Standardverhalten des Loggers zu ändern, müssen wir unseren Datei-Appender konfigurieren. Um zu beginnen, müssen Sie eine log4j.xml-Datei direkt im src-Ordner erstellen. Sie sind bereits mit dem XML-Format vertraut: Wir hatten kürzlich eine Lektion darüber :) Hier ist der Inhalt der Datei:

<?xml version="1.0" encoding="UTF-8"?>
<Configuration status="INFO">
   <Appenders>
       <File name="MyFileAppender" fileName="C:\Users\Username\Desktop\testlog.txt" immediateFlush="false" append="false">
           <PatternLayout pattern="%d{yyy-MM-dd HH:mm:ss.SSS} [%t] %-5level %logger{36} - %msg%n"/>
       </File>
   </Appenders>
   <Loggers>
       <Root level="INFO">
           <AppenderRef ref="MyFileAppender"/>
       </Root>
   </Loggers>
</Configuration>
Hier gibt es nichts besonders Besonderes oder Schwieriges :) Aber lassen Sie uns dennoch den Inhalt durchgehen.
<Configuration status="INFO">
Dabei handelt es sich um den sogenannten StatusLogger. Es hat nichts mit unserem Logger zu tun und wird in den internen Prozessen von Log4j verwendet. Wenn Sie status="TRACE" anstelle von status="INFO" festlegen, werden alle Informationen über die interne Arbeit von Log4j auf der Konsole angezeigt (StatusLogger zeigt Daten auf der Konsole an, auch wenn unser Appender eine Datei ist). Wir brauchen es jetzt nicht, also lassen wir es so wie es ist.

<Appenders>
   <File name="MyFileAppender" fileName="C:\Users\Evgeny\Desktop\testlog.txt" append="true">
       <PatternLayout pattern="%d{yyy-MM-dd HH:mm:ss.SSS} [%t] %-5level %logger{36} - %msg%n"/>
   </File>
</Appenders>
Hier erstellen wir unseren Appender. Das <File> -Tag gibt an, dass es sich um einen Datei-Appender handelt. name="MyFileAppender" legt den Namen des Appenders fest. fileName="C:\Benutzer\Benutzername\Desktop\testlog.txt" gibt den Pfad zur Protokolldatei an, in die alle Daten geschrieben werden. append="true" gibt an, ob die Daten an das Ende der Datei geschrieben werden sollen. In unserem Fall werden wir genau das tun. Wenn Sie den Wert auf „false“ setzen, wird der alte Inhalt der Protokolldatei bei jedem Programmstart gelöscht. <PatternLayout pattern="%d{yyy-MM-dd HH:mm:ss.SSS} [%t] %-5level %logger{36} - %msg%n"/>gibt die Formatierungseinstellungen an. Hier können wir reguläre Ausdrücke verwenden, um die Textformatierung in unserem Protokoll anzupassen.

<Loggers>
       <Root level="INFO">
           <AppenderRef ref="MyFileAppender"/>
       </Root>
</Loggers>
Hier geben wir die Root-Ebene an. Wir haben den Level „INFO“ eingestellt, was bedeutet, dass alle Nachrichten, deren Level höher als INFO ist (gemäß der Tabelle, die wir oben gesehen haben), nicht protokolliert werden. Unser Programm wird 3 Meldungen haben: eine INFO, eine WARN und eine ERROR. Mit der aktuellen Konfiguration werden alle 3 Meldungen protokolliert. Wenn Sie die Root-Ebene auf ERROR ändern, landet nur die letzte Nachricht des Methodenaufrufs LOGGER.error() im Protokoll. Zusätzlich wird hier auch auf den Appender verwiesen. Um eine solche Referenz zu erstellen, müssen Sie ein <ApprenderRef> -Tag innerhalb des <Root> -Tags erstellen und ihm das Attribut ref='Name Ihres Appenders' hinzufügen. Falls Sie es vergessen haben: Hier legen wir den Namen des Appenders fest: <. Und hier ist unser Code!

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

public class MyTestClass {

   public static final Logger LOGGER = LoggerFactory.getLogger(MyTestClass.class);

   public static void main(String[] args) {

       LOGGER.info("The program is starting!!!");

       try {
           LOGGER.warn("Attention! The program is trying to divide a number by another.
           System.out.println(12/0);
       } catch (ArithmeticException x) {

           LOGGER.error("Error! Division by zero!");
       }
   }
}
Natürlich ist es etwas verrückt (eine RuntimeException abzufangen ist eine fragwürdige Idee), aber für unsere Zwecke ist es perfekt :) Lassen Sie uns unsere main()- Methode viermal hintereinander ausführen und uns unsere testlog.txt-Datei ansehen. Sie müssen es nicht im Voraus erstellen: Die Bibliothek erledigt dies automatisch. Alles hat funktioniert! :) :) Jetzt haben Sie einen konfigurierten Logger. Sie können mit einigen Ihrer alten Programme herumspielen und jeder Methode Logger-Aufrufe hinzufügen. Schauen Sie sich dann das resultierende Protokoll an :) Es befasst sich eingehend mit dem Thema Protokollierung. Es wäre eine Herausforderung, alles in einem Rutsch zu lesen. Allerdings enthält es viele zusätzliche nützliche Informationen. Sie erfahren beispielsweise, wie Sie den Logger so konfigurieren, dass er eine neue Textdatei erstellt, wenn unsere testlog.txt-Datei eine bestimmte Größe erreicht :) Und damit ist unser Kurs abgeschlossen! Heute haben Sie sich mit einem sehr wichtigen Thema vertraut gemacht, und dieses Wissen wird Ihnen bei Ihrer zukünftigen Arbeit sicherlich hilfreich sein. Bis zum nächsten Mal! :) :)
Kommentare
TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION