1. Vue d’ensemble
Logback est l’un des environnements de journalisation les plus utilisés dans la communauté Java. Il s’agit d’un remplacement pour son prédécesseur, Log4j. Logback offre une mise en œuvre plus rapide que Log4j, offre davantage d’options de configuration et davantage de flexibilité pour l’archivage d’anciens fichiers journaux.
Cette introduction présentera l’architecture de Logback et vous montrera comment vous pouvez l’utiliser pour améliorer vos applications.
2. Architecture de journalisation
Trois classes constituent l’architecture Logback; Logger , Appender et Layout .
Un enregistreur est un contexte pour les messages de journal. Il s’agit de la classe avec laquelle les applications interagissent pour créer des messages de journal.
Les appendices placent des messages de journal dans leurs destinations finales. Un enregistreur peut avoir plus d’un appeleur. Nous pensons généralement que les appendices sont attachés à des fichiers texte, mais Logback est beaucoup plus puissant que cela.
La mise en page prépare les messages pour la sortie. Logback prend en charge la création de classes personnalisées pour le formatage des messages, ainsi que des options de configuration robustes pour les messages existants.
3. Installer
3.1. Dépendance Maven
Logback utilise la SLF4J (Simple Logging Facade for Java) comme interface native. Avant de pouvoir commencer à enregistrer des messages, nous devons ajouter Logback et Slf4j à notre pom.xml :
<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 dispose de la latestest version de Logback Core et les https://search.maven.org/classic/#search%7Cgav%7C1%7Cg%3A%22org.slf4j%22%20AND%20a%3A%22slf4j-api%22 de la dernière version de slf4j-api ].
3.2. Classpath
Logback nécessite également logback-classic.jar sur le chemin d’accès aux classes pour l’exécution.
Nous allons ajouter ceci à pom.xml en tant que dépendance de test:
<dependency>
<groupId>ch.qos.logback</groupId>
<artifactId>logback-classic</artifactId>
<version>1.2.3</version>
</dependency>4. Exemple de base et configuration
Commençons par un exemple rapide d’utilisation de Logback dans une application.
Premièrement, nous avons besoin d’un fichier de configuration. Nous allons créer un fichier texte nommé logback.xml et le placer quelque part dans notre chemin de classe:
<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>Ensuite, nous avons besoin d’une classe simple avec une méthode main :
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());
}
}Cette classe crée un Logger et appelle info () pour générer un message de journal.
Lorsque nous exécutons Example , nous voyons notre message enregistré sur la console:
20:34:22.136[main]INFO Example - Example log from ExampleIl est facile de comprendre pourquoi Logback est si populaire; nous sommes en marche en quelques minutes.
Cette configuration et ce code nous donnent quelques indications sur la manière dont cela fonctionne.
-
Nous avons un _appender named STDOUT_ qui référence un nom de classe
ConsoleAppender. . Il existe un modèle qui décrit le format de notre message de journal.
-
Notre code crée un Logger et nous lui avons transmis notre message via
une méthode info () _. _
Maintenant que nous avons compris les bases, examinons-les de plus près.
5. Contextes Logger
5.1. Créer un contexte
Pour consigner un message dans Logback, nous avons initialisé un Logger à partir de SLF4J ou Logback:
private static final Logger logger
= LoggerFactory.getLogger(Example.class);Et puis utilisé:
logger.info("Example log from {}", Example.class.getSimpleName());Ceci est notre contexte de journalisation. Quand nous l’avons créé, nous avons passé LoggerFactory notre classe. Ceci donne un nom au Logger (il y a aussi une surcharge qui accepte un String) .
Les contextes de journalisation existent dans une hiérarchie proche de la hiérarchie des objets Java:
-
** Un enregistreur est un ancêtre lorsque son nom, suivi d’un point, préfixe un
nom du logger descendant . Un enregistreur est un parent quand il n’ya aucun ancêtre entre lui et un
enfant**
Par exemple, la classe Example ci-dessous se trouve dans le package com.baeldung.logback . Il existe une autre classe nommée ExampleAppender dans le package com.baeldung.logback.appenders .
ExampleAppender’s Logger est un enfant de Example’s Logger.
-
Tous les enregistreurs sont les descendants de l’enregistreur racine prédéfini. **
Un Logger a un Level, qui peut être défini via la configuration ou avec Logger.setLevel () . La définition du niveau dans le code annule les fichiers de configuration.
Les niveaux possibles sont, par ordre de priorité: TRACE, DEBUG, INFO, WARN et _ERROR . _ Chaque niveau a une méthode correspondante que nous utilisons pour enregistrer un message à ce niveau.
-
Si aucun niveau n’est explicitement attribué à un enregistreur, il hérite du niveau de son ancêtre le plus proche. ** L’enregistreur racine a par défaut la valeur DEBUG. Nous verrons comment le remplacer ci-dessous.
5.2. Utiliser un contexte
Créons un exemple de programme illustrant l’utilisation d’un contexte dans les hiérarchies de journalisation:
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");Lorsque nous courons cela, nous voyons ces messages:
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 == INFONous commençons par récupérer un Logger nommé com.baeldung.logback et le convertissons en un ch.qos.logback.classic.Logger.
Un contexte Logback est nécessaire pour définir le niveau dans l’instruction suivante. notez que le journal abstrait du SLF4J n’implémente pas setLevel () .
Nous définissons le niveau de notre contexte sur INFO ; _ nous créons ensuite un autre enregistreur nommé com.baeldung.logback.tests._
Nous enregistrons deux messages avec chaque contexte pour illustrer la hiérarchie.
Logback enregistre les messages WARN, et INFO et filtre les messages _DEBUG _ .
Maintenant, utilisons l’enregistreur racine:
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.");Nous voyons ces messages lorsque nous exécutons cet extrait:
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.Pour conclure, nous avons commencé avec un contexte Logger et avons imprimé un message DEBUG .
Nous avons ensuite récupéré le logger racine en utilisant son nom défini de manière statique et avons défini son niveau sur ERROR.
Enfin, nous avons démontré que Logback filtre en réalité toute instruction inférieure à une erreur.
5.3. Messages paramétrés
Contrairement aux exemples de fragments ci-dessus, les messages de journalisation les plus utiles nécessitaient l’ajout de Strings. . Cela implique l’allocation de mémoire, la sérialisation des objets, la concaténation de Strings, et éventuellement le nettoyage ultérieur.
Considérez le message suivant:
log.debug("Current count is " + count);Que le message soit consigné ou non, nous assumons le coût de création du message.
Logback offre une alternative avec ses messages paramétrés:
log.debug("Current count is {}", count);-
Les accolades \ {} accepteront n’importe quel Objet et utiliseront leur méthode toString () pour générer un message uniquement après avoir vérifié que le message de journal est requis. **
Essayons quelques paramètres différents:
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);
}Cet extrait donne:
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)
...Nous voyons comment un String, un int, et un Integer peuvent être transmis en tant que paramètres.
De plus, quand une Exception est passée comme dernier argument d’une méthode de journalisation, Logback imprimera la trace de la pile pour nous.
6. Configuration détaillée
Dans les exemples précédents, nous utilisions le fichier de configuration de 11 lignes que nous avions créé dans link: #example[section 4]pour imprimer les messages du journal sur la console. C’est le comportement par défaut de Logback; s’il ne trouve pas de fichier de configuration, il crée un _ConsoleAppender _ et l’associe au journal racine.
6.1. Localisation des informations de configuration
Un fichier de configuration peut être placé dans le chemin de classe et nommé logback.xml ou logback-test.xml.
Voici comment Logback tentera de trouver les données de configuration:
-
Recherchez les fichiers nommés _logback-test.xml, logback.groovy, _ ou
logback.xml dans le classpath, dans cet ordre.
-
Si la bibliothèque ne trouve pas ces fichiers, elle tentera d’utiliser
Java ServiceLoader localiser un implémenteur du com.qos.logback.classic.spi.Configurator. . Se configurer pour enregistrer les sorties directement sur la console
Remarque: la version actuelle de Logback ne prend pas en charge la configuration de Groovy car il n’existe pas de version de Groovy compatible avec Java 9.
6.2. Configuration de base
Jetons un coup d’œil à notre lien: #example[exemple de configuration.]
Le fichier entier est dans les balises _ <configuration> _ .
-
Nous voyons une balise qui déclare un Appender de type ConsoleAppender et le nomme STDOUT . Un encodeur est imbriqué dans cette balise. Il a un motif avec ce qui ressemble à des codes d’échappement sprintf-style : **
<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>Enfin, nous voyons une balise root . Cette balise définit le consignateur racine en mode DEBUG et associe sa sortie au fichier Appender nommé STDOUT :
<root level="debug">
<appender-ref ref="STDOUT"/>
</root>6.3. Dépannage de la configuration
Les fichiers de configuration Logback peuvent devenir compliqués, il existe donc plusieurs mécanismes intégrés de dépannage.
Pour voir les informations de débogage pendant que Logback traite la configuration, vous pouvez activer la journalisation du débogage:
<configuration debug="true">
...
</configuration>Logback affichera les informations d’état sur la console pendant le traitement de la configuration:
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 pointSi des avertissements ou des erreurs se produisent lors de l’analyse du fichier de configuration, Logback écrit les messages d’état sur la console.
Il existe un deuxième mécanisme pour imprimer les informations d’état:
<configuration>
<statusListener class="ch.qos.logback.core.status.OnConsoleStatusListener"/>
...
</configuration>Le StatusListener intercepte les messages d’état et les imprime pendant la configuration et pendant l’exécution du programme ** .
La sortie de tous les fichiers de configuration est imprimée, ce qui est utile pour localiser les fichiers de configuration «non fiables» sur le chemin d’accès aux classes.
6.4. Rechargement de la configuration automatiquement
Le rechargement de la configuration de la journalisation pendant l’exécution d’une application est un puissant outil de dépannage. Logback rend cela possible avec le paramètre scan :
<configuration scan="true">
...
</configuration>Le comportement par défaut consiste à analyser le fichier de configuration pour les modifications toutes les 60 secondes. Modifiez cet intervalle en ajoutant scanPeriod :
<configuration scan="true" scanPeriod="15 seconds">
...
</configuration>Nous pouvons spécifier des valeurs en millisecondes, secondes, minutes ou heures.
6.5. Modification de Loggers
Dans l’exemple de fichier ci-dessus, nous définissons le niveau du consignateur racine et l’associons à la console _Appender _ .
Nous pouvons définir le niveau pour tout enregistreur:
<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>Ajoutons ceci à notre classpath et exécutons ce code:
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");Nous voyons cette sortie:
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 testsEn ne définissant pas le niveau de nos enregistreurs par programme, la configuration les définit; com.baeldung.foobar hérite de _ DEBUG _ de l’enregistreur racine.
Les enregistreurs héritent également de appender-ref de l’enregistreur racine. Comme nous le verrons ci-dessous, nous pouvons le remplacer.
6.6. Substitution Variable
Les fichiers de configuration Logback prennent en charge les variables. Nous définissons des variables à l’intérieur du script de configuration ou en externe. Une variable peut être spécifiée n’importe où dans un script de configuration à la place d’une valeur.
Par exemple, voici la configuration pour un 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>En haut de la configuration, nous avons déclaré une propriété _ nommée LOG DIR . _ . Nous l’avons ensuite utilisée dans le chemin d’accès au fichier contenu dans la définition de appender__.
Les propriétés sont déclarées dans une balise <propriété> dans les scripts de configuration.
Mais ils sont également disponibles à partir de sources extérieures, telles que les propriétés du système. Nous pourrions omettre la déclaration property dans cet exemple et définir la valeur de LOG DIR__ sur la ligne de commande:
$ java -DLOG__DIR=/var/log/application com.baeldung.logback.LogbackTestsNous spécifions la valeur de la propriété avec $ \ {propertyname} . Logback implémente des variables comme remplacement de texte. La substitution de variable peut se produire à tout moment dans un fichier de configuration où une valeur peut être spécifiée.
7. Appenders
Loggers passe LoggingEvents à Appenders. Appenders effectue le travail de journalisation proprement dit. Nous pensons généralement que la journalisation est quelque chose qui va dans un fichier ou la console, mais Logback est capable de beaucoup plus. Logback-core fournit plusieurs ajouts utiles.
7.1. ConsoleAppender
Nous avons déjà vu _ConsoleAppender en action. Malgré son nom, ConsoleAppender ajoute des messages à System.out ou System.err._
Il utilise un OutputStreamWriter pour mettre en mémoire tampon l’entrée/sortie. Le fait de le diriger vers System.err n’entraîne donc pas d’écriture sans tampon.
7.2. FileAppender
_FileAppender _ ajoute des messages à un fichier. Il supporte une large gamme de paramètres de configuration. Ajoutons un fichier appender à notre configuration de base:
<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>FileAppender est configuré avec un nom de fichier via <fichier> . . La balise _ <append> indique à Appender _ de s’ajouter à un fichier existant plutôt que de le tronquer. Si nous exécutons le test plusieurs fois, nous voyons que la sortie de journalisation est ajoutée au même fichier.
Si nous réexécutons notre test à partir de ci-dessus, les messages de com.baeldung.logback.tests sont envoyés à la fois à la console et à un fichier nommé tests.log. L’enregistreur descendant hérite de l’association de l’enregistreur racine avec ConsoleAppender et de son association avec FileAppender. . Les appendices sont cumulatifs.
Nous pouvons remplacer ce comportement:
<logger name="com.baeldung.logback.tests" level="WARN" additivity="false" >
<appender-ref ref="FILE"/>
</logger>
<root level="debug">
<appender-ref ref="STDOUT"/>
</root>Définir additivity sur _false désactive le comportement par défaut. Tests_ ne se connectera pas à la console, pas plus que ses descendants.
7.3. RollingFileAppender
Souvent, l’ajout de messages de journal au même fichier n’est pas le comportement dont nous avons besoin. Nous souhaitons que les fichiers «défilent» en fonction de l’heure, de la taille du fichier journal ou d’une combinaison des deux.
Pour cela, nous avons 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>Un _RollingFileAppender a un RollingPolicy . Dans cet exemple de configuration, nous voyons un TimeBasedRollingPolicy . _
Semblable à FileAppender, nous avons configuré cet appender avec un nom de fichier. Nous avons déclaré une propriété et l’avons utilisée pour cela car nous allons réutiliser le nom de fichier ci-dessous.
Nous définissons un fileNamePattern à l’intérieur de _RollingPolicy . Ce modèle définit non seulement le nom des fichiers, mais également leur fréquence de défilement. TimeBasedRollingPolicy _ examine le modèle et roule à la période la plus finement définie.
Par exemple:
<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>Le fichier journal actif est _/var/logs/application/LogFile . Ce fichier est transféré au début de chaque mois dans /Année en cours/Mois en cours/LogFile.gz et RollingFileAppender_ crée un nouveau fichier actif.
Lorsque la taille totale des fichiers archivés atteint 3 Go, _RollingFileAppender _ supprime les archives en fonction du premier entré premier sorti.
Il existe des codes pour une semaine, une heure, une minute, une seconde et même une milliseconde.
Logback a une référence here .
_RollingFileAppender a également un support intégré pour la compression de fichiers. Il compresse nos fichiers roulés car ils portent le nom LogFile.gz._
_TimeBasedPolicy n’est pas notre seule option pour faire défiler des fichiers. Logback propose également SizeAndTimeBasedRollingPolicy, , qui sera calculé en fonction de la taille actuelle du fichier journal et de la durée. Il propose également un FixedWindowRollingPolicy _ qui lance les noms de fichier journal chaque fois que le consignateur est démarré.
Nous pouvons également écrire nos propres RollingPolicy .
7.4. Appendices personnalisés
Nous pouvons créer des appenders personnalisés en étendant l’une des classes d’appendeurs de base de Logback. Nous avons un tutoriel pour créer un lien personnalisé:/custom-logback-appender[ici].
8. Layouts
Messages de journal de format Layouts . Comme le reste de Logback, _Layouts _ sont extensibles et nous pouvons create our own. puis certains.
Nous avons utilisé PatternLayout dans tous nos exemples jusqu’à présent:
<encoder>
<pattern>%d{HH:mm:ss.SSS}[%thread]%-5level %logger{36} - %msg%n</pattern>
</encoder>Ce script de configuration contient la configuration pour _PatternLayoutEncoder . Nous passons un Encoder à notre Appender, et cet encodeur utilise le PatternLayout_ pour formater les messages.
Le texte de la balise <motif> définit le formatage des messages de journal. ** PatternLayout implémente une grande variété de mots de conversion et de modificateurs de format pour la création de modèles.
Brisons celui-ci. PatternLayout reconnaît les mots de conversion avec un%, de sorte que les conversions dans notre modèle génèrent:
-
% d \ {HH: mm: ss.SSS} - un horodatage avec heures, minutes, secondes et
millisecondes ** [% thread] - le nom du thread générant le message du journal, entouré
entre crochets ** % - 5level - le niveau de l’événement de journalisation, complété avec 5 caractères
-
% logger \ {36} - nom de l’enregistreur, tronqué à 35 caractères
-
% msg% n - les messages du journal suivis de la ligne dépendante de la plate-forme
caractère séparateur
Nous voyons donc des messages similaires à ceux-ci:
21:32:10.311[main]DEBUG com.baeldung.logback.LogbackTests - Logging message: This is a StringVous trouverez une liste exhaustive de mots de conversion et de modificateurs de format à l’adresse here .
9. Conclusion
Dans ce guide détaillé, nous avons abordé les principes fondamentaux de l’utilisation de Logback dans une application.
Nous avons examiné les trois composants principaux de l’architecture de Logback:
enregistreurs, appenders et mise en page. Logback’s possède de puissants scripts de configuration, que nous avons utilisés pour manipuler des composants pour filtrer et formater des messages. Nous avons également examiné les deux appendeurs de fichiers les plus couramment utilisés pour créer, déplacer, organiser et compresser les fichiers journaux.
Comme d’habitude, des extraits de code peuvent être trouvés over sur GitHub .