Eine Anleitung zum Rolling File Appenders
1. Überblick
Während Protokolldateien häufig nützliche Informationen enthalten, werden sie mit der Zeit natürlich größer, und wenn sie auf unbestimmte Zeit vergrößert werden, kann ihre Größe zu einem Problem werden.
Protokollbibliotheken beheben dieses Problem mitrolling file appenders, which automatically “roll” or archive the current log file and resume logging in a new file, wenn bestimmte vordefinierte Bedingungen auftreten, und verhindern so unerwünschte Ausfallzeiten.
In diesem Artikel wird die Konfiguration von Appendern für fortlaufende Dateien in einigen der am häufigsten verwendeten Protokollierungsbibliotheken - Log4j, Log4j2 und Slf4j - erläutert.
Wir zeigen, wie Protokolldateien basierend auf Größe, Datum / Uhrzeit und einer Kombination aus Größe und Datum / Uhrzeit gerollt werden. Wir werden auch zeigen, wie jede Bibliothek so konfiguriert wird, dass die alten Protokolldateien automatisch komprimiert und später gelöscht werden. Auf diese Weise ersparen wir uns das Schreiben von langwierigem Verwaltungscode.
2. Unsere Beispielanwendung
Beginnen wir mit einer Beispielanwendung, die einige Nachrichten protokolliert. Dieser Code basiert auf Log4j, kann jedoch problemlos für die Arbeit mit Log4j2 oder Slf4j geändert werden:
import org.apache.log4j.Logger;
public class Log4jRollingExample {
private static Logger logger = Logger.getLogger(Log4jRollingExample.class);
public static void main(String[] args) throws InterruptedException {
for(int i = 0; i < 2000; i++) {
logger.info("This is the " + i + " time I say 'Hello World'.");
Thread.sleep(100);
}
}
}Die Anwendung ist ziemlich naiv - sie schreibt einige Nachrichten in einer Schleife mit einer kurzen Verzögerung zwischen den Iterationen. Bei 2.000 auszuführenden Schleifen und einer Pause von 100 ms in jeder Schleife sollte die Anwendung etwas mehr als drei Minuten dauern.
In diesem Beispiel werden verschiedene Funktionen verschiedener Arten von Rolling File Appendern demonstriert.
3. Rolling File Appenders in Log4j
3.1. Maven-Abhängigkeiten
Um Log4j in Ihrer Anwendung zu verwenden, fügen Sie diese Abhängigkeit zunächst derpom.xml-Datei Ihres Projekts hinzu:
log4j
log4j
1.2.17
Um die zusätzlichen Appender vonapache-log-extras zu verwenden, die in den nächsten Beispielen verwendet werden, fügen Sie die folgende Abhängigkeit hinzu. Verwenden Sie dabei dieselbe Version, die wir für Log4j deklariert haben, um die vollständige Kompatibilität sicherzustellen:
log4j
apache-log4j-extras
1.2.17
Sie finden die neueste Version vonLog4j undApache Log4j Extras auf Maven Central.
3.2. Rollen basierend auf der Dateigröße
In Log4j wird wie in den anderen Protokollierungsbibliotheken das Dateirollen an den Appender delegiert. Schauen wir uns die Konfiguration für einen fortlaufenden Datei-Appender in Log4j an, der basierend auf der Dateigröße rollt:
Hier haben wir Log4j so konfiguriert, dass die Protokolldatei mit dem ParameterMaxFileSizerollt, wenn ihre Größe 5 KB erreicht. Wir haben Log4j außerdem angewiesen, maximal zwei gerollte Protokolldateien mit dem ParameterMaxBackupIndexzu speichern.
Bei der Ausführung unserer Beispielanwendung haben wir die folgenden Dateien erhalten:
27/11/2016 10:28 138 app.log
27/11/2016 10:28 5.281 app.log.1
27/11/2016 10:28 5.281 app.log.2Was ist passiert? Log4j begann mit dem Schreiben in die Dateiapp.log. Wenn die Dateigröße das 5-KB-Limit überschritten hat, hat Log4japp.log nachapp.log.1 verschoben, brandneue, leereapp.log erstellt und weiterhin neue Protokollnachrichten nachapp.log geschrieben.
Nachdem die neuenapp.log die 5-KB-Grenze überschritten hatten, wurde dieser Walzvorgang wiederholt. Dieses Mal wurdeapp.log.1 nachapp.log.2, verschoben, um Platz für weitere neue, leereapp.log zu schaffen.
Der Rolling-Vorgang wurde während des Laufs mehrmals wiederholt. Da wir unseren Appender jedoch so konfiguriert haben, dass höchstens zwei Rolling-Dateien gespeichert werden, gibt es keine Datei mit dem Namenapp.log.3.
Damit haben wir eines der ursprünglichen Probleme gelöst, da wir nun in der Lage sind, die Größe der erstellten Protokolldateien zu begrenzen.
Als wir andererseits die erste Zeile vonapp.log.2 überprüften, enthielt sie die Nachricht, die sich auf die 700. Iteration bezog, was bedeutet, dass alle vorherigen Protokollnachrichten verloren gegangen waren:
2016-11-27 10:28:34 INFO This is the 700 time I say 'Hello World'.Mal sehen, ob wir ein Setup entwickeln können, das besser für eine Produktionsumgebung geeignet ist, in der der Verlust von Protokollnachrichten nicht als der beste Ansatz angesehen werden kann.
Zu diesem Zweck werden wir andere leistungsstärkere, flexiblere und konfigurierbarere Log4j-Appender verwenden, die in einem speziellen Paket namensapache-log4j-extras geliefert werden.
Die in diesem Artefakt enthaltenen Appender bieten viele Optionen zur Feinabstimmung des Protokollrollens und führen die unterschiedlichen Konzepte vontriggering policy undrolling policy ein. Dietriggering policy beschreiben, wann ein Walzen auftreten soll, während dierolling policy beschreiben, wie das Walzen ausgeführt werden soll. Diese beiden Konzepte sind der Schlüssel für das Rolling von Protokolldateien und werden mehr oder weniger explizit auch von anderen Bibliotheken verwendet, wie wir gleich sehen werden.
3.3. Rollen mit automatischer Komprimierung
Kehren wir zum Log4j-Beispiel zurück und verbessern Sie unser Setup, indem Sie die automatische Komprimierung der gerollten Dateien hinzufügen, um Platz zu sparen:
Mit dem Elementtriggering policy haben wir angegeben, dass der Roll auftreten soll, wenn das Protokoll die Größe von 5.120 Bytes überschreitet.
Innerhalb desrolling policy-Tags, gibt der ParameterActiveFileName den Pfad der Hauptprotokolldateien an, die die neuesten Nachrichten enthalten, und der ParameterFileNamePattern gibt eine Vorlage an, die beschreibt, welcher Pfad der Pfad sein soll die gerollten Dateien. Beachten Sie, dass dies tatsächlich ein Muster ist, da der spezielle Platzhalter%i durch den Index der gerollten Datei ersetzt wird.
Beachten Sie auch, dassFileNamePattern mit der Erweiterung ".gz”" endet. Immer wenn wir eine Erweiterung verwenden, die einem unterstützten komprimierten Format zugeordnet ist, werden die alten gerollten Dateien ohne zusätzlichen Aufwand von unserer Seite komprimiert.
Wenn wir jetzt die Anwendung ausführen, erhalten wir einen anderen Satz von Protokolldateien:
03/12/2016 19:24 88 app.1.log.gz
...
03/12/2016 19:26 88 app.2.log.gz
03/12/2016 19:26 88 app.3.log.gz
03/12/2016 19:27 70 app.current.logIn der Dateiapp.current.log sind die letzten Protokolle aufgetreten. Vorherige Protokolle wurden gerollt und komprimiert, wenn ihre Größe das festgelegte Limit erreicht hat.
3.4. Rollen basierend auf Datum und Uhrzeit
In anderen Szenarien möchten Sie Log4j möglicherweise so konfigurieren, dass die Dateien basierend auf dem Datum und der Uhrzeit der Protokollmeldungen anstelle der Dateigröße gerollt werden. Beispielsweise möchten Sie in einer Webanwendung möglicherweise alle Protokollnachrichten, die an einem Tag ausgegeben werden, in derselben Protokolldatei speichern.
Dazu können SieTimeBasedRollingPolicy verwenden. Bei dieser Richtlinie muss eine Vorlage für den Pfad der Protokolldatei angegeben werden, die einen zeitbezogenen Platzhalter enthält. Bei jeder Ausgabe einer Protokollnachricht überprüft der Appender den resultierenden Protokollpfad. Wenn dieser vom zuletzt verwendeten Pfad abweicht, wird ein Roll ausgeführt. Hier ist ein kurzes Beispiel, das einen solchen Appender konfiguriert:
3.5. Rollen basierend auf Größe und Zeit
Wenn SieSizeBasedTriggeringPolicy undTimeBasedRollingPolicy, kombinieren, erhalten Sie einen Appender, der basierend auf Datum / Uhrzeit würfelt. Wenn die Größe der Datei das festgelegte Limit erreicht, wird auch basierend auf der Größe gewürfelt:
Als wir unsere Anwendung mit diesem Setup ausführten, erhielten wir die folgenden Protokolldateien:
03/12/2016 19:25 234 app.19-25.1481393432120.log.gz
03/12/2016 19:25 234 app.19-25.1481393438939.log.gz
03/12/2016 19:26 244 app.19-26.1481393441940.log.gz
03/12/2016 19:26 240 app.19-26.1481393449152.log.gz
03/12/2016 19:26 3.528 app.19-26.1481393470902.logIn der Dateiapp.19-26.1481393470902.log findet die aktuelle Protokollierung statt. Wie Sie sehen können, werden alle Protokolle im Intervall zwischen 19:25 und 19:26 in mehreren komprimierten Protokolldateien gespeichert, deren Namen mit „app.19-25″. beginnen. Der Platzhalter von“%i”wird durch eine immer größere Zahl ersetzt .
4. Rolling File Appenders in Log4j2
4.1. Maven-Abhängigkeiten
Um Log4j2 als bevorzugte Protokollierungsbibliothek zu verwenden, müssen wir den POM unseres Projekts mit der folgenden Abhängigkeit aktualisieren:
org.apache.logging.log4j
log4j-core
2.7
Wie üblich finden Sie dielatest version in Maven Central.
4.2. Rollen basierend auf der Dateigröße
Ändern wir unsere Beispielanwendung, um die Log4j2-Protokollierungsbibliotheken zu verwenden, und untersuchen wir nun, wie wir das Rollen von Dateien basierend auf der Größe der Protokolldatei in der Konfigurationsdatei vonlog4j2.xmleinrichten können:
%d{yyyy-MM-dd HH:mm:ss} %p %m%n
Im TagPolicies haben wir alle Auslöserichtlinien angegeben, die wir anwenden möchten. OnStartupTriggeringPolicy löst bei jedem Start der Anwendung einen Roll aus, was für eigenständige Anwendungen nützlich sein kann. Wir haben dann einSizeBasedTriggeringPolicyangegeben, das angibt, dass ein Roll immer dann auftreten soll, wenn die Protokolldatei 5 KB erreicht.
4.3. Rollen basierend auf Datum und Uhrzeit
Richten Sie mithilfe der von Log4j2 angebotenen Richtlinien einen Appender ein, um die Protokolldatei basierend auf der Zeit zu rollen und zu komprimieren:
%d{yyyy-MM-dd HH:mm:ss} %p %m%n
Hier ist der Schlüssel die Verwendung vonTimeBasedTriggeringPolicy, mit der wir zeitbezogene Platzhalter in der Vorlage der gerollten Dateinamen verwenden können. Beachten Sie, dass wir, da wir nur eine einzige Auslöserichtlinie benötigten, das TagPoliciesnicht wie im vorherigen Beispiel verwenden müssen.
4.4. Rollen basierend auf Größe und Zeit
Wie bereits beschrieben, besteht ein zwingenderes Szenario darin, Protokolldateien basierend auf Zeit und Größe zu rollen und zu komprimieren. Hier ist ein Beispiel, wie wir Log4j2 für diese Aufgabe einrichten können:
%d{yyyy-MM-dd HH:mm:ss} %p %m%n
Bei dieser Konfiguration haben wir angegeben, dass ein Rollvorgang basierend auf Zeit und Größe ausgeführt werden soll. Der Appender kann anhand des für den Dateinamen "app.%d{MM-dd-yyyy-HH-mm}.%i.log.gz”" verwendeten Musters verstehen, auf welches Zeitintervall wir uns beziehen. Dies legt implizit fest, dass jede Minute ein Roll ausgeführt wird, und komprimiert die gerollte Datei.
Wir haben auch einDefaultRolloverStrategy hinzugefügt, um alte gerollte Dateien zu löschen, die bestimmten Kriterien entsprechen. Wir konfigurieren unsere, um Dateien zu löschen, die dem angegebenen Muster entsprechen, wenn sie älter als 20 Tage sind.
4.5. Maven-Abhängigkeiten
Um Log4j2 als bevorzugte Protokollierungsbibliothek zu verwenden, müssen wir den POM unseres Projekts mit der folgenden Abhängigkeit aktualisieren:
org.apache.logging.log4j
log4j-core
2.7
Wie üblich finden Sie dielatest version in Maven Central.
5. Rolling File Appenders in Slf4j
5.1. Maven-Abhängigkeiten
Wenn Sie Slf4j2 mit einem Logback-Backend als Protokollierungsbibliothek verwenden möchten, fügen Sie diese Abhängigkeit zu Ihrenpom.xml hinzu:
ch.qos.logback
logback-classic
1.1.7
Wie üblich finden Sie dielatest version in Maven Central.
5.2. Rollen basierend auf der Dateigröße
Lassen Sie uns nun sehen, wie Sie stattdessen Slf4j mit dem Standard-Back-EndLogback verwenden. Lassen Sie uns untersuchen, wie wir ein Datei-Rolling in der Konfigurationsdateilogback.xml einrichten können, die im Klassenpfad der Anwendung abgelegt ist:
target/slf4j/roll-by-size/app.log
target/slf4j/roll-by-size/app.%i.log.zip
1
3
1MB
5KB
%-4relative [%thread] %-5level %logger{35} - %msg%n
Wieder stoßen wir auf das Konzept der fortlaufenden Politik. Der grundlegende Mechanismus ist derselbe wie der von Log4j und Log4j2. MitFixedWindowRollingPolicy können wir einen Indexplatzhalter im Namensmuster der gerollten Datei verwenden.
Wenn die Größe der Protokolldatei den konfigurierten Grenzwert überschreitet, wird eine neue Datei zugewiesen und der alte Inhalt wird als erste Datei in der Liste gespeichert, wobei die vorhandenen Dateien um eine Position verschoben werden.
5.3. Rollen basierend auf der Zeit
In Slf4j können wir eine Protokolldatei basierend auf der Zeit mit den angegebenenTimeBasedRollingPolicy rollen. Mit dieser Richtlinie können wir den Vorlagennamen der fortlaufenden Datei mithilfe von zeit- und datumsbezogenen Platzhaltern angeben:
target/slf4j/roll-by-time/app.log
target/slf4j/roll-by-time/app.%d{yyyy-MM-dd-HH-mm}.log.zip
20
1MB
%d{yyyy-MM-dd HH:mm:ss} %p %m%n
5.4. Rollen basierend auf Größe und Zeit
Wenn Sie eine Datei basierend auf Zeit und Größe rollen müssen, können Sie die bereitgestelltenSizeAndTimeBasedRollingPolicy verwenden. Bei Verwendung dieser Richtlinie müssen Sie sowohl einen zeitbezogenen Platzhalter als auch einen Indexplatzhalter angeben.
Jedes Mal, wenn die Größe der Protokolldatei für ein bestimmtes Zeitintervall die konfigurierte Größenbeschränkung überschreitet, wird eine andere Protokolldatei mit demselben Wert für den zeitbezogenen Platzhalter, jedoch mit einem inkrementierten Index erstellt:
target/slf4j/roll-by-time-and-size/app.log
target/slf4j/roll-by-time-and-size/app.%d{yyyy-MM-dd-mm}.%i.log.zip
5KB
20
1MB
%d{yyyy-MM-dd HH:mm:ss} %p %m%n
6. Fazit
Wie wir gesehen haben, erspart Ihnen die Verwendung einer Protokollbibliothek zum Roll-out der Dateien die manuelle Verwaltung der Protokolldateien, sodass Sie sich auf die Entwicklung Ihrer Geschäftslogik konzentrieren können. Rolling File Appender sind ein wertvolles Werkzeug, das in der Toolbox jedes Entwicklers enthalten sein sollte.
Wie üblich finden Sie die Quellenon GitHub, in denen die in diesem Artikel vorgestellten Beispielanwendungen so konfiguriert sind, dass sie mit mehreren verschiedenen Rolling-Setups protokolliert werden, damit Sie eine gute Basiskonfiguration finden können, die weiter an Ihre Bedürfnisse angepasst werden kann Bedürfnisse.