[springboot] Architecture du framework de journalisation Slf4j

Annuaire d'articles

Les étudiants qui viennent d'entrer en contact avec le java log log peuvent être effrayés par divers frameworks de log, notamment les jars entre les différents frameworks de log toujours en conflit, et bien d'autres petits partenaires ont mal à la tête. Ensuite, le contenu de cet article est de présenter le processus de développement de divers frameworks de journalisation Java, la relation entre eux et comment les sélectionner.

1. Divers kits d'outils de journalisation

1.1. Cadre de journalisation

Package JDK java.util.logging : java.util.logging est un package de journal Java publié par jdk1.4, qui peut être considéré comme une boîte à outils de journal avec une application à long terme.
log4j : un projet open source d'Apache, qui fournit une prise en charge solide des journaux Java et fournit même des interfaces vers d'autres langages, notamment C, C++, .Net et PL/SQL, afin de réaliser la coexistence multilingue d'un journal d'environnement distribué. impression. Les mises à jour ont été interrompues, elles ne sont donc pas recommandées.
Logback : Un autre composant de journal open source conçu par le fondateur de log4j, en tant que framework de journal par défaut de Spring Boot, il est largement utilisé.
log4j2 : Apache Log4j2 est une mise à niveau vers Log4j qui fournit des améliorations significatives par rapport à son prédécesseur, Log4j1.x, et fournit de nombreuses améliorations disponibles dans Logback tout en corrigeant certains problèmes dans l'architecture Logback. Il est basé sur le développement de Disruptor (un framework de concurrence open source sans verrouillage) basé sur LMAX Company, qui améliore les défauts de Log4j et Logback en termes de conception architecturale, a un débit ultra élevé et une faible latence, et a de meilleures performances que Log4j1.x et Logback.

1.2 Façade en rondins

commons-logging : membre de la bibliothèque de classes Apache commons, en tant que façade de journal, il peut automatiquement choisir d'utiliser la journalisation log4j ou JDK, mais cela ne dépend pas de l'API de Log4j et de JDK Logging. Si le classpath du projet contient la bibliothèque de classes log4j, log4j sera utilisé, sinon JDK Logging sera utilisé.
SLF4J : On peut dire que c'est la façade de journal la plus utilisée. Elle fournit une couche d'abstraction de journal qui vous permet d'utiliser n'importe quelle bibliothèque de journaux en arrière-plan. Tels que : log4j, log4j2, logback

1.3 L'importance de l'existence de la façade en rondins

insérez la description de l'image ici

Pourquoi ne pas simplement utiliser le framework de journalisation, mais proposer une façade de journalisation ?
La façade de journal (SLF4J) est principalement destinée à fournir un cadre d'API standard et standardisé pour l'accès aux journaux Java. Son rôle principal est de fournir une interface. L'implémentation spécifique peut être implémentée par d'autres cadres de journal, tels que log4j et logback. Pour les projets Java généraux, le framework de journalisation choisira slf4j-api comme façade, couplé à un framework d'implémentation spécifique (log4j, log4j2, logback, etc.), et utilisera un pont au milieu pour compléter le pontage.

Pour les différents frameworks de journalisation présentés ci-dessus, chaque framework de journalisation a sa propre API distincte. Pour utiliser le framework correspondant, l'API correspondante doit être utilisée, ce qui augmente considérablement les exigences de couplage du code d'application pour le framework de journalisation. Avec la façade SLF4J, les programmeurs programmeront toujours pour SLF4J, qui peut facilement et rapidement remplacer le cadre de journalisation sous-jacent sans entraîner de modifications correspondantes du code métier.

Lors de la journalisation avec SLF4J, il est généralement nécessaire de définir une variable Logger dans chaque classe qui doit se connecter, comme suit :

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

@RestController
public class LogTestController {
    
    
    private static final Logger logger = LoggerFactory.getLogger(LogTestController.class);

    @GetMapping("/test")
    public void test(){
    
    
        logger.trace("Trace 日志...");
        logger.debug("Debug 日志...");
        logger.info("Info 日志...");
        logger.warn("Warn 日志...");
        logger.error("Error 日志...");
    }
}

Il s'agit évidemment d'un travail répétitif et réduit l'efficacité du développement. Si vous introduisez Lombok dans votre projet, vous pouvez utiliser l'annotation @Slf4j qu'il fournit pour générer automatiquement la variable ci-dessus. Le nom de la variable par défaut est log, si nous voulons utiliser le LOGGER idiomatique est utilisé comme nom de variable, vous pouvez ajouter le fichier lombok.config dans le répertoire racine du projet et ajouter lombok.log.fieldName=LOGGERles éléments de configuration dans le fichier.

2. Sélection du cadre logique

Le framework de journalisation par défaut de Spring Boot utilise Logback
Parmi eux, Log4j peut être considéré comme une bibliothèque de fonctions obsolète, qui a cessé de se mettre à jour et dont l'utilisation n'est pas recommandée.En revanche, ses performances et ses fonctions sont également les pires.
Bien que la déconnexion soit la valeur par défaut de Spring Boot, ses performances sont toujours inférieures à Log4j2. Par conséquent, à ce stade, Log4j2 est le premier choix pour la journalisation (la série log4j a connu des problèmes de sécurité, veuillez utiliser la nouvelle version après la correction du bogue ).

SLF4J + Log4j2 est notre option de journalisation recommandée.

Résultats des tests de performances
insérez la description de l'image ici

Référence : site officiel de log4j2

3. Niveau de journalisation

Avant de détailler la configuration d'intégration de chaque framework de journalisation, commençons par avoir une compréhension générale des niveaux de journalisation les plus courants : ERROR, WARN, INFO, DEBUG et TRACE. Comme d'autres, tels que ALL, OFF et FATAL ne devraient fondamentalement pas être impliqués dans le processus de développement. Par conséquent, les niveaux de log communs suivants sont introduits de bas en haut.

TRACE : Suivi. Généralement, il est utile de déboguer les performances du système principal ou de suivre les problèmes. Ce niveau est très bas. Généralement, il n'est pas activé. Une fois activé, le journal remplira le disque très rapidement.
DÉBOGAGE : débogage. Tout le monde devrait être familiarisé avec cela. Le processus de développement consiste principalement à imprimer et à enregistrer des informations en cours d'exécution, etc.
INFOS : Informations. C'est le plus courant, et la plupart d'entre eux utilisent par défaut ce niveau de journaux. Généralement, certaines informations d'interaction, certains paramètres de demande, etc. sont enregistrés. Il est pratique de localiser le problème ou de l'utiliser lors de la restauration de l'environnement sur site. Ce journal est relativement important.
AVERTISSEMENT : Avertissement. Cela enregistre généralement des informations potentiellement sujettes aux erreurs. Par exemple, au démarrage, un certain fichier de configuration n'existe pas ou un certain paramètre n'est pas défini.
ERREUR : erreur. Ceci est également relativement courant. Généralement, il est affiché lorsqu'une exception est interceptée. Bien qu'une erreur se produise, elle n'affecte pas le fonctionnement normal du système. Mais cela peut entraîner des erreurs système ou des temps d'arrêt.

Le niveau de journalisation de petit à grand est trace<debug<info<warn<error<fatal. Étant donné que le niveau de journalisation par défaut de la structure de journalisation est généralement défini sur INFO, les journaux de suivi et de débogage dans les exemples de niveaux de suivi et de débogage de la section 1.3 . ne peut pas être vu.

2020-08-17 13:59:16.566  INFO c.z.b.l.controller.LogTestController     : Info 日志...
2020-08-17 13:59:16.566  WARN  c.z.b.l.controller.LogTestController     : Warn 日志...
rn 日志...
2020-08-17 13:59:16.566 ERROR  c.z.b.l.controller.LogTestController     : Error 日志...

Quatre, analyse de concept de terminologie commune

appender : contrôle principalement l'emplacement de sortie du journal, tel que : fichier, base de données, impression de la console, etc.
logger : utilisé pour définir le niveau d'impression du journal d'un package ou d'une classe spécifique, et spécifier l'appender
root : est aussi un logger, un logger parent spécial. Tous les enregistreurs enfants finiront par diffuser la sortie vers la racine, sauf si additivity="false" est configuré dans l'enregistreur enfant.
rollingPolicy : il n'est pas bon de stocker tous les journaux dans un seul fichier, vous pouvez donc spécifier une politique de roulement pour stocker les fichiers journaux en fonction d'une certaine période ou d'une certaine taille de fichier.
RolloverStrategy : stratégie de nettoyage des journaux. Fait généralement référence à la durée de conservation du journal.
Journal asynchrone : ouvrez un thread séparé pour écrire le journal afin de ne pas bloquer le thread principal.

insérez la description de l'image ici

Pour synchroniser le journal, le thread principal ne peut pas continuer à s'exécuter tant que le journal n'est pas écrit sur le disque.
Journal asynchrone, le thread principal écrit le journal, place simplement le message du journal dans une file d'attente, puis continue son exécution vers le bas. Ce processus est terminé au niveau de la mémoire. Ensuite, un thread dédié obtient les données du journal de la file d'attente et les écrit sur le disque, de sorte que le thread principal ne soit pas bloqué. Le thread principal (core business code) s'exécute efficacement.