1. Überblick
Logback ist eines der am häufigsten verwendeten Frameworks für die Protokollierung in der Java-Community. Es ist ein https://logback.qos.ch/reasonsToSwitch.html Ersatz für seinen Vorgänger Log4j.]Logback bietet eine schnellere Implementierung als Log4j, bietet mehr Konfigurationsoptionen und mehr Flexibilität bei der Archivierung alter Protokolldateien.
Diese Einführung stellt die Architektur von Logback vor und zeigt Ihnen, wie Sie sie verwenden können, um Ihre Anwendungen besser
2. Logback-Architektur
Drei Klassen umfassen die Logback-Architektur. Logger , Appender und Layout .
Ein Logger ist ein Kontext für Protokollnachrichten. Mit dieser Klasse interagieren Anwendungen, um Protokollnachrichten zu erstellen.
Appender platzieren Protokollnachrichten an ihren endgültigen Zielen. Ein Logger kann mehr als einen Appender haben. Wir betrachten Appenders im Allgemeinen als an Textdateien angehängt, aber Logback ist viel mächtiger als das.
Layout bereitet Nachrichten für die Ausgabe vor. Logback unterstützt die Erstellung von benutzerdefinierten Klassen zum Formatieren von Nachrichten sowie robuste Konfigurationsoptionen für die vorhandenen.
3. Konfiguration
3.1. Maven-Abhängigkeit
Logback verwendet die Simple Logging Facade für Java (SLF4J) als native Schnittstelle. Bevor wir mit der Protokollierung von Nachrichten beginnen können, müssen wir unserer pom.xml Logback und Slf4j hinzufügen:
<dependency>
<groupId>ch.qos.logback</groupId>
<artifactId>logback-core</artifactId>
<version>1.2.3</version>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
<version>1.8.0-beta2</version>
<scope>test</scope>
</dependency>Maven Central hat die https://search.maven.org/classic/#search%7Cgav%7C1%7Cg%3A%22ch.qos.logback%22%20AND%20a%3A%22logback-core%22 der neuesten Version von Logback-Core]und die letzte Version von https://search.maven.org/classic/#search%7Cgav%7C1%7Cg%3A%22org.slf4j%22%20AND%20a%3A%22slf4j-api%22 von slf4j-api ].
3.2. Klassenpfad
Logback erfordert außerdem logback-classic.jar für den Klassenpfad zur Laufzeit.
Wir fügen dies als Testabhängigkeit zu pom.xml hinzu:
<dependency>
<groupId>ch.qos.logback</groupId>
<artifactId>logback-classic</artifactId>
<version>1.2.3</version>
</dependency>4. Grundlegendes Beispiel und Konfiguration
Beginnen wir mit einem schnellen Beispiel für die Verwendung von Logback in einer Anwendung.
Zunächst benötigen wir eine Konfigurationsdatei. Wir erstellen eine Textdatei mit dem Namen logback.xml und legen sie irgendwo in unseren Klassenpfad:
<configuration>
<appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
<encoder>
<pattern>%d{HH:mm:ss.SSS}[%thread]%-5level %logger{36} - %msg%n</pattern>
</encoder>
</appender>
<root level="debug">
<appender-ref ref="STDOUT"/>
</root>
</configuration>Als Nächstes benötigen wir eine einfache Klasse mit einer main -Methode:
public class Example {
private static final Logger logger
= LoggerFactory.getLogger(Example.class);
public static void main(String[]args) {
logger.info("Example log from {}", Example.class.getSimpleName());
}
}Diese Klasse erstellt einen Logger und ruft info () auf, um eine Protokollnachricht zu generieren.
Wenn wir Example ausführen, wird unsere Nachricht in der Konsole protokolliert:
20:34:22.136[main]INFO Example - Example log from ExampleEs ist leicht zu erkennen, warum Logback so beliebt ist. Wir sind in wenigen Minuten in Betrieb.
Diese Konfiguration und dieser Code geben uns einige Hinweise, wie dies funktioniert.
-
Wir haben einen _appender named STDOUT_ , der auf einen Klassennamen verweist
ConsoleAppender. . Es gibt ein Muster, das das Format unserer Protokollnachricht beschreibt.
-
Unser Code erstellt einen Logger , und wir haben unsere Nachricht über übermittelt
eine info () Methode _. _
Nachdem wir nun die Grundlagen verstanden haben, schauen wir uns das genauer an.
5. Logger -Kontexte
5.1. Erstellen eines Kontexts
Um eine Nachricht in Logback zu protokollieren, haben wir einen Logger von SLF4J oder Logback initialisiert:
private static final Logger logger
= LoggerFactory.getLogger(Example.class);Und dann benutzt es:
logger.info("Example log from {}", Example.class.getSimpleName());Dies ist unser Protokollierungskontext. Als wir es erstellt haben, haben wir LoggerFactory unsere Klasse übergeben. Dies gibt dem Logger einen Namen (es gibt auch eine Überladung, die einen String akzeptiert) .
Protokollierungskontexte existieren in einer Hierarchie, die der Java-Objekthierarchie sehr ähnlich ist:
-
** Ein Logger ist ein Vorfahre, wenn sein Name, gefolgt von einem Punkt, dem Präfix a vorangestellt ist
Name des Nachkommen-Loggers . Ein Logger ist ein Elternteil, wenn sich zwischen ihm und a keine Vorfahren befinden
Kind**
Die folgende Klasse Example befindet sich beispielsweise im Paket com.baeldung.logback . Es gibt eine weitere Klasse mit dem Namen ExampleAppender im Paket com.baeldung.logback.appenders .
ExampleAppender’s Logger ist ein untergeordnetes Element von Example’s Logger.
-
Alle Logger sind Nachkommen des vordefinierten Root-Loggers. **
Ein Logger hat ein Level, , das entweder über die Konfiguration oder mit __Logger.setLevel () festgelegt werden kann. Das Festlegen der Ebene in Code überschreibt Konfigurationsdateien.
Die möglichen Ebenen sind in der Reihenfolge ihrer Priorität: TRACE, DEBUG, INFO, WARN und _ERROR . _ Jede Ebene hat eine entsprechende Methode, mit der wir eine Nachricht auf dieser Ebene protokollieren.
Wenn einem Logger nicht explizit eine Ebene zugewiesen wird, erbt er die Ebene des nächsten Vorfahren.
5.2. Verwendung eines Kontexts
Lassen Sie uns ein Beispielprogramm erstellen, das die Verwendung eines Kontexts in Protokollhierarchien demonstriert:
ch.qos.logback.classic.Logger parentLogger =
(ch.qos.logback.classic.Logger) LoggerFactory.getLogger("com.baeldung.logback");
parentLogger.setLevel(Level.INFO);
Logger childlogger =
(ch.qos.logback.classic.Logger)LoggerFactory.getLogger("com.baeldung.logback.tests");
parentLogger.warn("This message is logged because WARN > INFO.");
parentLogger.debug("This message is not logged because DEBUG < INFO.");
childlogger.info("INFO == INFO");
childlogger.debug("DEBUG < INFO");Wenn wir das ausführen, sehen wir diese Meldungen:
20:31:29.586[main]WARN com.baeldung.logback - This message is logged because WARN > INFO.
20:31:29.594[main]INFO com.baeldung.logback.tests - INFO == INFOWir beginnen mit dem Abrufen eines Logger mit dem Namen com.baeldung.logback und wandeln ihn in eine ch.qos.logback.classic.Logger. um.
Ein Logback-Kontext ist erforderlich, um die Ebene in der nächsten Anweisung festzulegen. Beachten Sie, dass der abstrakte Logger des SLF4J __setLevel () nicht implementiert.
Wir setzen die Ebene unseres Kontexts auf INFO ;
Wir protokollieren zwei Nachrichten mit jedem Kontext, um die Hierarchie zu veranschaulichen.
Logback protokolliert die Meldungen WARN, und INFO und filtert die Meldungen _DEBUG _ .
Nun verwenden wir den Root-Logger:
ch.qos.logback.classic.Logger logger =
(ch.qos.logback.classic.Logger)LoggerFactory.getLogger("com.baeldung.logback");
logger.debug("Hi there!");
Logger rootLogger =
(ch.qos.logback.classic.Logger)LoggerFactory.getLogger(org.slf4j.Logger.ROOT__LOGGER__NAME);
logger.debug("This message is logged because DEBUG == DEBUG.");
rootLogger.setLevel(Level.ERROR);
logger.warn("This message is not logged because WARN < ERROR.");
logger.error("This is logged.");Wir sehen diese Nachrichten, wenn wir dieses Snippet ausführen:
20:44:44.241[main]DEBUG com.baeldung.logback - Hi there!
20:44:44.243[main]DEBUG com.baeldung.logback - This message is logged because DEBUG == DEBUG.
20:44:44.243[main]ERROR com.baeldung.logback - This is logged.Zum Abschluss haben wir mit einem Logger -Kontext begonnen und eine DEBUG -Nachricht gedruckt.
Anschließend haben wir den Root-Logger unter Verwendung seines statisch definierten Namens abgerufen und seine Stufe auf ERROR. gesetzt.
Und schließlich haben wir gezeigt, dass Logback jede Anweisung weniger als einen Fehler filtert.
5.3. Parametrisierte Meldungen
Im Gegensatz zu den Nachrichten in den obigen Beispielschnipseln mussten die meisten Protokollnachrichten Strings anhängen. Dies erfordert das Zuweisen von Speicher, das Serialisieren von Objekten, das Verketten von Strings, __ und möglicherweise das Beseitigen des Papierkorbs.
Betrachten Sie die folgende Nachricht:
log.debug("Current count is " + count);Wir verursachen die Kosten für die Erstellung der Nachricht, unabhängig davon, ob der Logger die Nachricht protokolliert oder nicht.
Logback bietet mit seinen parametrisierten Meldungen eine Alternative:
log.debug("Current count is {}", count);-
Die geschweiften Klammern \ {} akzeptieren alle Object -Werte und verwenden ihre toString () -Methode, um eine Nachricht erst zu erstellen, nachdem überprüft wurde, ob die Protokollnachricht erforderlich ist.
Versuchen wir einige andere Parameter:
String message = "This is a String";
Integer zero = 0;
try {
logger.debug("Logging message: {}", message);
logger.debug("Going to divide {} by {}", 42, zero);
int result = 42/zero;
} catch (Exception e) {
logger.error("Error dividing {} by {} ", 42, zero, e);
}Dieser Ausschnitt ergibt:
21:32:10.311[main]DEBUG com.baeldung.logback.LogbackTests - Logging message: This is a String
21:32:10.316[main]DEBUG com.baeldung.logback.LogbackTests - Going to divide 42 by 0
21:32:10.316[main]ERROR com.baeldung.logback.LogbackTests - Error dividing 42 by 0
java.lang.ArithmeticException:/by zero
at com.baeldung.logback.LogbackTests.givenParameters__ValuesLogged(LogbackTests.java:64)
...Wir sehen, wie ein String, ein int, und ein Integer als Parameter übergeben werden können.
Wenn eine Exception als letztes Argument an eine Protokollierungsmethode übergeben wird, druckt Logback den Stack-Trace für uns.
6. Detaillierte Konfiguration
In den vorherigen Beispielen haben wir die 11-Zeilen-Konfigurationsdatei verwendet, um in link erstellt: #example[Abschnitt 4], um Protokollnachrichten an die Konsole zu drucken. Dies ist das Standardverhalten von Logback. Wenn keine Konfigurationsdatei gefunden wird, erstellt sie einen _ConsoleAppender _ und ordnet sie dem Root-Logger zu.
6.1. Auffinden von Konfigurationsinformationen
Eine Konfigurationsdatei kann im Klassenpfad abgelegt werden und entweder logback.xml oder logback-test.xml. heißen.
So versucht Logback nach Konfigurationsdaten zu suchen:
-
Suchen Sie nach Dateien mit dem Namen _logback-test.xml, logback.groovy, _ oder
logback.xml im Klassenpfad in dieser Reihenfolge.
-
Wenn die Bibliothek diese Dateien nicht findet, wird sie versuchen, sie zu verwenden
Java´s ServiceLoader einen Implementierer der suchen com.qos.logback.classic.spi.Configurator. . Konfigurieren Sie sich selbst, um die Ausgabe direkt in der Konsole zu protokollieren
Hinweis: Die aktuelle Version von Logback unterstützt keine Groovy-Konfiguration, da es keine mit Java 9 kompatible Version von Groovy gibt.
6.2. Grundlegende Einstellung
Schauen wir uns unseren Link genauer an: #example[Beispielkonfiguration.]
Die gesamte Datei befindet sich in _ <Konfiguration> _ Tags.
-
Wir sehen ein Tag, das einen Appender vom Typ ConsoleAppender deklariert und STDOUT benennt. In diesem Tag ist ein Encoder verschachtelt. Es hat ein Muster mit einem sprintf-style -Escape-Code: **
<appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
<encoder>
<pattern>%d{HH:mm:ss.SSS}[%thread]%-5level %logger{36} - %msg%n</pattern>
</encoder>
</appender>Zuletzt sehen wir ein root -Tag. Dieses Tag setzt den Root-Logger auf den DEBUG -Modus und verknüpft seine Ausgabe mit dem Appender mit dem Namen STDOUT :
<root level="debug">
<appender-ref ref="STDOUT"/>
</root>6.3. Fehlerbehebung bei der Konfiguration
Logback-Konfigurationsdateien können kompliziert werden, daher gibt es mehrere integrierte Mechanismen zur Fehlerbehebung.
Um Debug-Informationen anzuzeigen, während Logback die Konfiguration verarbeitet, können Sie die Debug-Protokollierung aktivieren:
<configuration debug="true">
...
</configuration>Logback druckt Statusinformationen an die Konsole, während die Konfiguration verarbeitet wird:
23:54:23,040 |-INFO in ch.qos.logback.classic.LoggerContext[default]- Found resource[logback-test.xml]
at[file:/Users/egoebelbecker/ideaProjects/logback-guide/out/test/resources/logback-test.xml]23:54:23,230 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - About to instantiate appender
of type[ch.qos.logback.core.ConsoleAppender]23:54:23,236 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - Naming appender as[STDOUT]23:54:23,247 |-INFO in ch.qos.logback.core.joran.action.NestedComplexPropertyIA - Assuming default type
[ch.qos.logback.classic.encoder.PatternLayoutEncoder]for[encoder]property
23:54:23,308 |-INFO in ch.qos.logback.classic.joran.action.RootLoggerAction - Setting level of ROOT logger to DEBUG
23:54:23,309 |-INFO in ch.qos.logback.core.joran.action.AppenderRefAction - Attaching appender named[STDOUT]to Logger[ROOT]23:54:23,310 |-INFO in ch.qos.logback.classic.joran.action.ConfigurationAction - End of configuration.
23:54:23,313 |-INFO in[email protected]- Registering current configuration
as safe fallback pointWenn beim Analysieren der Konfigurationsdatei Warnungen oder Fehler auftreten, schreibt Logback Statusmeldungen in die Konsole.
Es gibt einen zweiten Mechanismus zum Drucken von Statusinformationen:
<configuration>
<statusListener class="ch.qos.logback.core.status.OnConsoleStatusListener"/>
...
</configuration>-
Der StatusListener fängt Statusmeldungen ab und druckt sie während der Konfiguration und während das Programm läuft ** .
Die Ausgabe aller Konfigurationsdateien wird gedruckt. Dies macht es hilfreich, um "unpassende" Konfigurationsdateien im Klassenpfad zu finden.
6.4. Konfiguration automatisch neu laden
Das erneute Laden der Protokollierungskonfiguration, während eine Anwendung ausgeführt wird, ist ein leistungsfähiges Werkzeug zur Problembehandlung. Logback ermöglicht dies mit dem scan -Parameter:
<configuration scan="true">
...
</configuration>Das Standardverhalten besteht darin, die Konfigurationsdatei alle 60 Sekunden auf Änderungen zu überprüfen. Ändern Sie dieses Intervall durch Hinzufügen von scanPeriod :
<configuration scan="true" scanPeriod="15 seconds">
...
</configuration>Wir können Werte in Millisekunden, Sekunden, Minuten oder Stunden angeben.
6.5. Loggers ändern
In unserer obigen Beispieldatei legen wir den Level des Root-Loggers fest und ordnen ihn der Konsole _Appender _ zu.
Wir können den Pegel für jeden Logger einstellen:
<configuration>
<appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
<encoder>
<pattern>%d{HH:mm:ss.SSS}[%thread]%-5level %logger{36} - %msg%n</pattern>
</encoder>
</appender>
<logger name="com.baeldung.logback" level="INFO"/>
<logger name="com.baeldung.logback.tests" level="WARN"/>
<root level="debug">
<appender-ref ref="STDOUT"/>
</root>
</configuration>Fügen wir dies unserem Klassenpfad hinzu und führen Sie diesen Code aus:
Logger foobar =
(ch.qos.logback.classic.Logger) LoggerFactory.getLogger("com.baeldung.foobar");
Logger logger =
(ch.qos.logback.classic.Logger) LoggerFactory.getLogger("com.baeldung.logback");
Logger testslogger =
(ch.qos.logback.classic.Logger) LoggerFactory.getLogger("com.baeldung.logback.tests");
foobar.debug("This is logged from foobar");
logger.debug("This is not logged from logger");
logger.info("This is logged from logger");
testslogger.info("This is not logged from tests");
testslogger.warn("This is logged from tests");Wir sehen diese Ausgabe:
00:29:51.787[main]DEBUG com.baeldung.foobar - This is logged from foobar
00:29:51.789[main]INFO com.baeldung.logback - This is logged from logger
00:29:51.789[main]WARN com.baeldung.logback.tests - This is logged from testsWenn Sie die Stufe unserer Logger nicht programmgesteuert festlegen, werden sie durch die Konfiguration festgelegt. com.baeldung.foobar erbt _ DEBUG _ vom Root-Logger.
Die Logger erben auch den appender-ref vom Root-Logger. Wie wir weiter unten sehen werden, können wir dies außer Kraft setzen.
6.6. Variable Substitution
Logback-Konfigurationsdateien unterstützen Variablen. Wir definieren Variablen innerhalb des Konfigurationsskripts oder extern. Eine Variable kann anstelle eines Werts an einer beliebigen Stelle in einem Konfigurationsskript angegeben werden.
Hier ist zum Beispiel die Konfiguration für einen FileAppender :
<property name="LOG__DIR" value="/var/log/application"/>
<appender name="FILE" class="ch.qos.logback.core.FileAppender">
<file>${LOG__DIR}/tests.log</file>
<append>true</append>
<encoder>
<pattern>%-4relative[%thread]%-5level %logger{35} - %msg%n</pattern>
</encoder>
</appender>Oben in der Konfiguration haben wir eine _-Eigenschaft mit dem Namen LOG DIR . _ deklariert. Dann haben wir sie als Teil des Pfads der Datei in der appender__-Definition verwendet.
Eigenschaften werden in Konfigurationsskripten in einem <property> -Tag deklariert.
Sie sind aber auch von externen Quellen verfügbar, z. B. Systemeigenschaften. Wir könnten die property -Deklaration in diesem Beispiel weglassen und den Wert von LOG DIR__ in der Befehlszeile festlegen:
$ java -DLOG__DIR=/var/log/application com.baeldung.logback.LogbackTestsWir geben den Wert der Eigenschaft mit $ \ {propertyyname} an . Logback implementiert Variablen als Textersetzung. Die Ersetzung von Variablen kann an jeder Stelle in einer Konfigurationsdatei erfolgen, an der ein Wert angegeben werden kann.
7. Appenders
Loggers übergeben LoggingEvents an Appenders. Appenders erledigen die eigentliche Protokollierungsarbeit. Logging wird normalerweise als etwas betrachtet, das zu einer Datei oder zur Konsole gehört, aber Logback kann noch viel mehr. Logback-core bietet mehrere nützliche Appender.
7.1. ConsoleAppender
Wir haben _ConsoleAppender bereits in Aktion gesehen. Trotz seines Namens hängt ConsoleAppender Nachrichten an System.out oder System.err._
Es verwendet einen OutputStreamWriter zum Puffern der E/A, sodass die Weiterleitung an System.err nicht zu ungepuffertem Schreiben führt.
7.2. FileAppender
_FileAppender _ hängt Nachrichten an eine Datei an. Es unterstützt eine Vielzahl von Konfigurationsparametern. Fügen wir unserer Grundkonfiguration einen Datei-Appender hinzu:
<configuration debug="true">
<appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
<!-- encoders are assigned the type
ch.qos.logback.classic.encoder.PatternLayoutEncoder by default -->
<encoder>
<pattern>%d{HH:mm:ss.SSS}[%thread]%-5level %logger{36} - %msg%n</pattern>
</encoder>
</appender>
<appender name="FILE" class="ch.qos.logback.core.FileAppender">
<file>tests.log</file>
<append>true</append>
<encoder>
<pattern>%-4relative[%thread]%-5level %logger{35} - %msg%n</pattern>
</encoder>
</appender>
<logger name="com.baeldung.logback" level="INFO"/>
<logger name="com.baeldung.logback.tests" level="WARN">
<appender-ref ref="FILE"/>
</logger>
<root level="debug">
<appender-ref ref="STDOUT"/>
</root>
</configuration>Der FileAppender wird über <Datei> mit einem Dateinamen konfiguriert. Der Tag <Anhängen> weist den Appender __ an, an eine vorhandene Datei anzuhängen, anstatt sie abzuschneiden. Wenn wir den Test mehrmals ausführen, wird die Protokollierungsausgabe an dieselbe Datei angehängt.
Wenn wir unseren Test erneut von oben ausführen, werden die Meldungen von com.baeldung.logback.tests sowohl an die Konsole als auch an eine Datei mit dem Namen tests.log gesendet. Der Nachkommen-Logger erbt die Zuordnung des Root-Loggers zum ConsoleAppender mit seiner Verknüpfung mit FileAppender. Appenders sind kumulativ.
Wir können dieses Verhalten überschreiben:
<logger name="com.baeldung.logback.tests" level="WARN" additivity="false" >
<appender-ref ref="FILE"/>
</logger>
<root level="debug">
<appender-ref ref="STDOUT"/>
</root>Wenn Sie additivity auf _false setzen, wird das Standardverhalten deaktiviert. Tests_ wird sich nicht bei der Konsole anmelden und auch keine seiner Nachkommen.
7.3. RollingFileAppender
Das Anhängen von Protokollnachrichten an dieselbe Datei ist häufig nicht das Verhalten, das wir benötigen. Wir möchten, dass Dateien basierend auf Zeit, Protokolldateigröße oder einer Kombination aus beidem "rollen".
Dafür haben wir RollingFileAppender:
<property name="LOG__FILE" value="LogFile"/>
<appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender">
<file>${LOG__FILE}.log</file>
<rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
<!-- daily rollover -->
<fileNamePattern>${LOG__FILE}.%d{yyyy-MM-dd}.gz</fileNamePattern>
<!-- keep 30 days' worth of history capped at 3GB total size -->
<maxHistory>30</maxHistory>
<totalSizeCap>3GB</totalSizeCap>
</rollingPolicy>
<encoder>
<pattern>%-4relative[%thread]%-5level %logger{35} - %msg%n</pattern>
</encoder>
</appender>Ein _RollingFileAppender hat eine RollingPolicy . In dieser Beispielkonfiguration sehen wir eine TimeBasedRollingPolicy . _ .
Ähnlich wie beim FileAppender haben wir diesen Appender mit einem Dateinamen konfiguriert. Wir haben eine Eigenschaft deklariert und dafür verwendet, weil wir den Dateinamen weiter verwenden.
Wir definieren ein fileNamePattern innerhalb der _RollingPolicy . Dieses Muster definiert nicht nur den Namen der Dateien, sondern auch, wie oft sie gerollt werden. TimeBasedRollingPolicy _ untersucht das Muster und würfelt im feinsten definierten Zeitraum.
Zum Beispiel:
<property name="LOG__FILE" value="LogFile"/>
<property name="LOG__DIR" value="/var/logs/application"/>
<appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender">
<file>${LOG__DIR}/${LOG__FILE}.log</file>
<rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
<fileNamePattern>${LOG__DIR}/%d{yyyy/MM}/${LOG__FILE}.gz</fileNamePattern>
<totalSizeCap>3GB</totalSizeCap>
</rollingPolicy>Die aktive Protokolldatei lautet __/var/logs/application/LogFile . Diese Datei wird zu Beginn jedes Monats in /Aktuelles Jahr/Aktueller Monat/LogFile.gz übernommen und erstellt ** eine neue aktive Datei.
Wenn die Gesamtgröße der archivierten Dateien 3 GB erreicht, löscht _RollingFileAppender _ Archive auf einer First-In-First-Out-Basis.
Es gibt Codes für eine Woche, Stunde, Minute, Sekunde und sogar Millisekunde.
Logback hat eine Referenz hier .
_RollingFileAppender bietet auch eine integrierte Unterstützung für das Komprimieren von Dateien. Es komprimiert unsere gerollten Dateien, weil sie als LogFile.gz._ bezeichnet wurden.
_TimeBasedPolicy ist nicht die einzige Option zum Rollen von Dateien. Logback bietet außerdem SizeAndTimeBasedRollingPolicy, , das basierend auf der aktuellen Protokolldateigröße sowie der Zeitdauer rollt. Es bietet auch eine FixedWindowRollingPolicy _ an, die bei jedem Start des Loggers Protokolldateinamen rollt.
Wir können auch unsere eigenen __https://logback.qos.ch/manual/appenders.html#onRollingPolicies[RollingPolicy]schreiben.
7.4. Kundenspezifische Appender
Wir können benutzerdefinierte Appender erstellen, indem Sie eine der grundlegenden Appender-Klassen von Logback erweitern. Wir haben ein Tutorial zum Erstellen von benutzerdefinierten Appendern:/custom-logback-appender[hier].
8. Layouts
Protokollnachrichten im Format Layouts . Wie der Rest von Logback sind auch _Layouts _ erweiterbar, und wir können https://logback.qos.ch/manual/layouts.html#writingYourOwnLayout [create unsere eigenen erstellen dann einige.
Bisher haben wir PatternLayout in allen unseren Beispielen verwendet:
<encoder>
<pattern>%d{HH:mm:ss.SSS}[%thread]%-5level %logger{36} - %msg%n</pattern>
</encoder>Dieses Konfigurationsskript enthält die Konfiguration für _PatternLayoutEncoder . Wir übergeben einen Encoder an unseren Appender, . Dieser Encoder verwendet den PatternLayout_ zum Formatieren der Nachrichten.
Der Text im Tag <<Muster> definiert, wie Protokollnachrichten formatiert werden. PatternLayout__ implementiert eine Vielzahl von Konvertierungswörtern und Formatierungsmodifizierern zum Erstellen von Mustern.
Lasst uns das hier brechen PatternLayout erkennt Konvertierungswörter mit einem%, sodass die Konvertierungen in unserem Muster Folgendes erzeugen:
-
% d \ {HH: mm: ss.SSS} - ein Zeitstempel mit Stunden, Minuten, Sekunden und
Millisekunden ** [% thread] - Der Threadname, der die Protokollnachricht generiert, umgeben
durch eckige Klammern ** % - 5level - Die Stufe des Protokollierungsereignisses, auf 5 Zeichen aufgefüllt
-
% logger \ {36} - Der Name des Loggers, verkürzt auf 35 Zeichen
-
% msg% n - Die Protokollnachrichten, gefolgt von der plattformabhängigen Zeile
Trennzeichen
Wir sehen also ähnliche Nachrichten:
21:32:10.311[main]DEBUG com.baeldung.logback.LogbackTests - Logging message: This is a StringEine vollständige Liste der Konvertierungswörter und Formatmodifizierer finden Sie unter here .
9. Schlussfolgerung
In diesem ausführlichen Leitfaden haben wir die Grundlagen der Verwendung von Logback in einer Anwendung behandelt.
Wir haben uns die drei Hauptkomponenten der Logback-Architektur angesehen:
Logger, Appender und Layout. Logback verfügt über leistungsfähige Konfigurationsskripte, mit denen Komponenten zum Filtern und Formatieren von Nachrichten bearbeitet werden. Außerdem haben wir uns die zwei am häufigsten verwendeten Dateianwender angesehen, um Protokolldateien zu erstellen, zu verschieben, zu organisieren und zu komprimieren.
Wie üblich sind Codeausschnitte https://github.com/eugenp/tutorials/tree/master/logging-modules/logback [over auf GitHub zu finden.