Log4j - Log4j

Apache Log4j
Apache Log4j Logo.png
Développeur (s) Fondation Apache Software
Première version 8 janvier 2001 ; il y a 20 ans  ( 08/01/2001 )
Version stable
2.14.1 / 6 mars 2021 ; Il y a 9 jours  ( 06/03/2021 )
Dépôt Référentiel Log4j
Écrit en Java
Système opérateur Multiplateforme
Taper Enregistrement
Licence Licence Apache 2.0
Site Internet journalisation .apache .org / log4j / 2 .x /

Apache Log4j est un utilitaire de journalisation basé sur Java . Il a été initialement écrit par Ceki Gülcü et fait partie du projet Apache Logging Services de l' Apache Software Foundation . Log4j est l'un des nombreux frameworks de journalisation Java .

Depuis, Gülcü a lancé les projets SLF4J et Logback, avec l'intention d'offrir un successeur à Log4j.

L'équipe Apache Log4j a créé un successeur de Log4j 1 avec le numéro de version 2. Log4j 2 a été développé en se concentrant sur les problèmes de Log4j 1.2, 1.3, java.util.logging et Logback, et résout les problèmes apparus dans ces frameworks. De plus, Log4j 2 propose une architecture de plugin qui le rend plus extensible que son prédécesseur. Log4j 2 n'est pas rétrocompatible avec les versions 1.x, bien qu'un "adaptateur" soit disponible.

Le 5 août 2015, le comité de gestion de projet Apache Logging Services a annoncé que Log4j 1 était arrivé en fin de vie et qu'il était recommandé aux utilisateurs de Log4j 1 de passer à Apache Log4j 2.

Apache Log4j 2

Apache Log4j 2 est le successeur de Log4j 1 qui a été publié en version GA en juillet 2014. Le framework a été réécrit à partir de zéro et a été inspiré par les solutions de journalisation existantes, y compris Log4j 1 et java.util.logging. Les principales différences par rapport à Log4j 1 sont:

  • Amélioration de la fiabilité. Les messages ne sont pas perdus lors de la reconfiguration du framework comme dans Log4j 1 ou Logback
  • Extensibilité: Log4j 2 prend en charge un système de plugins pour permettre aux utilisateurs de définir et de configurer des composants personnalisés
  • Syntaxe de configuration simplifiée
  • Prise en charge des configurations xml, json, yaml et des propriétés
  • Filtres améliorés
  • Prise en charge de la recherche de propriétés pour les valeurs définies dans le fichier de configuration, les propriétés système, les variables d'environnement, la mappe ThreadContext et les données présentes dans l'événement
  • Prise en charge de plusieurs API: Log4j 2 peut être utilisé avec des applications utilisant les API Log4j 2, Log4j 1.2, SLF4J, Commons Logging et java.util.logging (JUL).
  • Niveaux de journal personnalisés
  • Prise en charge de lambda de style Java 8 pour la "journalisation différée"
  • Marqueurs
  • Prise en charge des objets Message définis par l'utilisateur
  • "Déchets sans déchets ou à faible niveau de déchets" dans les configurations courantes
  • Vitesse améliorée

L'une des fonctionnalités les plus reconnues de Log4j 2 est la performance des «enregistreurs asynchrones». Log4j 2 utilise le disrupteur LMAX . La bibliothèque réduit le besoin de verrouillage du noyau et augmente les performances de journalisation d'un facteur 12. Par exemple, dans le même environnement, Log4j 2 peut écrire plus de 18 000 000 messages par seconde, alors que d'autres frameworks comme Logback et Log4j 1 n'écrivent que <2 000 000 messages par seconde.

Niveaux de journalisation Log4j

Le tableau suivant définit les niveaux de journal et les messages intégrés dans Log4j, par ordre décroissant de gravité. La colonne de gauche répertorie la désignation du niveau de journal dans Log4j et la colonne de droite fournit une brève description de chaque niveau de journal.

Niveau Description
DÉSACTIVÉ Le rang le plus élevé possible et est destiné à désactiver la journalisation.
FATAL Erreurs graves entraînant un arrêt prématuré. Attendez-vous à ce qu'ils soient immédiatement visibles sur une console d'état.
ERREUR Autres erreurs d'exécution ou conditions inattendues. Attendez-vous à ce qu'ils soient immédiatement visibles sur une console d'état.
PRÉVENIR Utilisation d'API obsolètes, mauvaise utilisation de l'API, erreurs «presque», autres situations d'exécution indésirables ou inattendues, mais pas nécessairement «erronées». Attendez-vous à ce qu'ils soient immédiatement visibles sur une console d'état.
INFO Événements d'exécution intéressants (démarrage / arrêt). Attendez-vous à ce que ceux-ci soient immédiatement visibles sur une console, alors soyez prudent et maintenez-les au minimum.
DÉBOGUER Informations détaillées sur le flux à travers le système. Attendez-vous à ce que ceux-ci soient écrits uniquement dans les journaux. De manière générale, la plupart des lignes enregistrées par votre application doivent être écrites en tant que DEBUG.
TRACE Informations les plus détaillées. Attendez-vous à ce que ceux-ci soient écrits uniquement dans les journaux. Depuis la version 1.2.12.

Niveaux de journal personnalisés

Log4j 2 permet aux utilisateurs de définir leurs propres niveaux de journalisation. Un outil générateur de code source est fourni pour créer des enregistreurs qui prennent en charge les niveaux de journal personnalisés de la même manière que les niveaux de journal intégrés. Les niveaux de journalisation personnalisés peuvent compléter ou remplacer les niveaux de journalisation intégrés.

Configuration de Log4j

Log4j peut être configuré via un fichier de configuration ou via du code Java. Les fichiers de configuration peuvent être écrits au format de fichier XML , JSON , YAML ou de propriétés . Dans une configuration, vous pouvez définir trois composants principaux: Loggers, Appenders et Layouts. La configuration de la journalisation via un fichier présente l'avantage que la journalisation peut être activée ou désactivée sans modifier l'application qui utilise Log4j. L'application peut être autorisée à s'exécuter avec la déconnexion jusqu'à ce qu'il y ait un problème, par exemple, puis la journalisation peut être réactivée simplement en modifiant le fichier de configuration.

Loggers sont nommées destinations de message du journal. Ce sont les noms connus de l'application Java. Chaque enregistreur est indépendamment configurable quant au niveau de journalisation (FATAL, ERROR, etc.) il enregistre actuellement. Dans les premières versions de Log4j, elles étaient appelées catégorie et priorité, mais maintenant elles sont appelées respectivement logger et level. Un enregistreur peut envoyer des messages de journal à plusieurs appenders.

Les sorties réelles sont effectuées par les Appenders . Il existe de nombreux Appenders disponibles, avec des noms descriptifs, tels que FileAppender, RollingFileAppender, ConsoleAppender, SocketAppender, SyslogAppender et SMTPAppender. Log4j 2 a ajouté des Appenders qui écrivent dans Apache Flume , l' API de persistance Java , Apache Kafka , les bases de données NoSQL , les fichiers mappés en mémoire , les fichiers à accès aléatoire et les points de terminaison ZeroMQ . Plusieurs appendeurs peuvent être attachés à n'importe quel enregistreur, il est donc possible de consigner les mêmes informations sur plusieurs sorties; par exemple à un fichier localement et à un écouteur de socket sur un autre ordinateur.

Les appenders utilisent des mises en page pour formater les entrées de journal. Une façon populaire au format d' une ligne à-un-temps des fichiers journaux est PatternLayout, qui utilise une chaîne de modèle, un peu comme le C / de C fonction de printf . Il existe également des formateurs HTMLLayout et XMLLayout à utiliser lorsque les formats HTML ou XML sont respectivement plus pratiques. Log4j 2 a ajouté des mises en page pour CSV , Graylog Extended Log Format (GELF), JSON , YAML et RFC-5424.

Dans Log4j 2, les filtres peuvent être définis sur les éléments de configuration pour donner un contrôle plus fin sur les entrées de journal devant être traitées par quels enregistreurs et appendeurs. En plus du filtrage par niveau de journal et de correspondance d'expression régulière sur la chaîne de message, Log4j 2 a ajouté des filtres de rafale, des filtres de temps, un filtrage par d'autres attributs d'événements de journal tels que les marqueurs ou la carte de contexte de thread et les filtres de script JSR 223 .

Pour déboguer une configuration qui se comporte mal:

  • Dans les configurations Log4j 2, définissez l' status attribut sur TRACE pour envoyer la sortie de journalisation d'état interne vers la sortie standard . Pour activer la journalisation de l'état avant que la configuration ne soit trouvée, utilisez la propriété Java VM -Dorg.apache.logging.log4j.simplelog.StatusLogger.level=trace .
  • Dans Log4j 1, utilisez la propriété Java VM -Dlog4j.debug .

Pour savoir où un fichier de configuration log4j2.xml a été chargé à partir d'inspect getClass().getResource("/log4j2.xml") .

Il existe également une configuration implicite "non configurée" ou "par défaut" de Log4j, celle d'une application Java instrumentée par Log4j qui ne dispose d'aucune configuration Log4j. Cela imprime sur stdout un avertissement indiquant que le programme n'est pas configuré et l'URL du site Web Log4j où des détails sur l'avertissement et la configuration peuvent être trouvés. En plus d'imprimer cet avertissement, une application Log4j non configurée n'imprimera que les entrées de journal ERROR ou FATAL sur la sortie standard.

Exemple pour Log4j 2

<?xml version="1.0" encoding="UTF-8"?>
<Configuration status="trace" monitorInterval="60">
  <Properties>
    <Property name="filename">target/test.log</Property>
  </Properties>
 
  <Appenders>
    <Console name="STDOUT">
      <PatternLayout pattern="%d %p %c{1.} [%t] %m%n"/>
    </Console>

    <File name="file" fileName="${filename}">
      <PatternLayout>
        <pattern>%d %p %c{1.} [%t] %m%n</pattern>
      </PatternLayout>
    </File>
  </Appenders>
 
  <Loggers> 
    <!-- 
         loggers whose name starts with 'org.springframework' will only log messages of level "info" or higher;
         if you retrieve Loggers by using the class name (e.g. Logger.getLogger(AClass.class))
         and if AClass is part of the org.springframework package, it will belong to this category
    -->
    <Logger name="org.springframework" level="info" additivity="false" />

    <!--
        Filter example: for loggers whose name starts with 'com.mycompany.myproduct',
        log entries of level "debug" or higher whose ThreadContextMap data contains
        the key-value pair "test=123", also send these log entries to the "STDOUT" appender.
    -->
    <Logger name="com.mycompany.myproduct" level="debug" additivity="true">
      <ThreadContextMapFilter>
        <KeyValuePair key="test" value="123"/>
      </ThreadContextMapFilter>
      <AppenderRef ref="STDOUT"/>
    </Logger>
 
    <!--
        By default, all log messages of level "trace" or higher will be logged.
        Log messages are sent to the "file" appender and 
        log messages of level "error" and higher will be sent to the "STDOUT" appender.
    -->
    <Root level="trace">
      <AppenderRef ref="file"/>
      <AppenderRef ref="STDOUT" level="error"/>
    </Root>
  </Loggers>
 
</Configuration>

Exemple pour Log4j 1.2

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE log4j:configuration PUBLIC "-//LOGGER" "http://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/xml/doc-files/log4j.dtd">
<log4j:configuration>
    <!-- 
         an appender is an output destination, such as the console or a file;
         names of appenders are arbitrarily chosen.
    -->
    <appender name="stdout" class="org.apache.log4j.ConsoleAppender">
        <layout class="org.apache.log4j.PatternLayout">
            <param name="ConversionPattern"
                value="%d{ABSOLUTE} %5p %c{1}:%L - %m%n" />
        </layout>
    </appender>
 
    <!-- 
         loggers of category 'org.springframework' will only log messages of level "info" or higher;
         if you retrieve Loggers by using the class name (e.g. Logger.getLogger(AClass.class))
         and if AClass is part of the org.springframework package, it will belong to this category
    -->
    <logger name="org.springframework">
        <level value="info"/>
    </logger>

    <!-- 
         everything of spring was set to "info" but for class 
         PropertyEditorRegistrySupport we want "debug" logging 
    -->
    <logger name="org.springframework.beans.PropertyEditorRegistrySupport">
        <level value="debug"/>
    </logger>
 
    <logger name="org.acegisecurity">
        <level value="info"/>
    </logger>
    
    
    <root>
        <!-- 
            all log messages of level "debug" or higher will be logged, unless defined otherwise 
            all log messages will be logged to the appender "stdout", unless defined otherwise 
        -->
        <level value="debug" />
        <appender-ref ref="stdout" />
    </root>
</log4j:configuration>

TTCC

TTCC est un format de message utilisé par log4j. TTCC est un acronyme pour Time Thread Category Component . Il utilise le modèle suivant:

 %r [%t] %-5p %c %x - %m%n

Mnémonique Description
% r Utilisé pour afficher le nombre de millisecondes écoulées entre la construction de la mise en page et la création de l'événement de journalisation.
% t Utilisé pour afficher le nom du thread qui a généré l'événement de journalisation.
% p Utilisé pour afficher la priorité de l'événement de journalisation.
% c Utilisé pour afficher la catégorie de l'événement de journalisation.
%X Utilisé pour générer le NDC (contexte de diagnostic imbriqué) associé au thread qui a généré l'événement de journalisation.
% X {clé} Utilisé pour générer le MDC (contexte de diagnostic mappé) associé au thread qui a généré l'événement de journalisation pour la clé spécifiée.
% m Utilisé pour sortir le message fourni par l'application associé à l'événement de journalisation.
% n Utilisé pour afficher le ou les caractères de nouvelle ligne spécifiques à la plate-forme .

Exemple de sortie
467 [main] INFO org.apache.log4j.examples.Sort - Sortie de la méthode main.

Les ports

  • log4c - Un port pour C. Log4C est une bibliothèque de journalisation basée sur C , publiée sur SourceForge sous la licence LGPL . Pour divers systèmes d' exploitation Unix, les fichiers autoconf et automake sont fournis. Sous Windows, un Makefile est fourni pour une utilisation avec MSVC . Les développeurs peuvent également choisir d'utiliser leur propre système de fabrication pour compiler la source, en fonction de leurs besoins d'ingénierie de construction. Une instance de la bibliothèque log4c peut être configurée via trois méthodes: à l'aide de variables d'environnement , par programme ou via un fichier de configuration XML . log4c a des appenders pour les fichiers, les flux et les fichiers mappés en mémoire. (Pas d'adaptateur de socket.) La dernière version est la 1.2.4, sortie en 2013, et le projet n'est plus activement développé.
  • log4js - Un port pour JavaScript . Log4js est disponible sous la licence d' Apache Software Foundation . Une particularité de Log4js est la possibilité d'enregistrer les événements du navigateur à distance sur le serveur. En utilisant Ajax, il est possible d'envoyer les événements de journalisation dans plusieurs formats ( XML , JSON , ASCII brut , etc.) au serveur pour y être évalués. Les ajouts suivants sont implémentés pour log4js : AjaxAppender, ConsoleAppender, FileAppender, JSConsoleAppender, MetatagAppender et WindowsEventsAppender. Les classes Layout suivantes sont fournies: BasicLayout, HtmlLayout, JSONLayout et XMLLayout. La dernière version est la 1.1, sortie en 2008.
  • log4javascript - Un autre port pour JavaScript. log4javascript est un framework de journalisation JavaScript basé sur log4j . La dernière version est la 1.4.9, publiée en mai 2014.
  • JSNLog - Un port pour JavaScript . Place automatiquement les messages des enregistreurs JavaScript dans les journaux côté serveur à l'aide d'un composant côté serveur .NET qui s'interface avec Log4Net, NLog, Elmah ou Common.Logging. Ceci pour fournir un journal intégré pour les événements côté client et serveur. Les identifiants de demande mettent en corrélation les événements liés à un utilisateur spécifique. La configuration se fait via un fichier web.config côté serveur. Prend en charge la journalisation des exceptions, y compris les traces de pile. En juillet 2014, la dernière version était la 2.7.1 et des mises à jour étaient effectuées régulièrement.
  • Apache Log4net - Un port vers Microsoft .NET Framework . Le travail initial a été réalisé par Neoworks et a été donné à Apache Software Foundation en février 2004. Le framework est similaire à l'original log4j tout en tirant parti des nouvelles fonctionnalités du runtime .NET. Fournit un contexte de diagnostic imbriqué (NDC) et un contexte de diagnostic mappé (MDC). La dernière version est la 2.0.8 qui a été publiée en 2017.
  • log4perl - Un port Perl du package de journalisation très populaire log4j. La dernière version est la 1.49, publiée en février 2017.
  • Apache log4php - "Un framework de journalisation polyvalent pour PHP . A l'origine un portage d'Apache log4j vers PHP, il s'est développé pour inclure diverses fonctionnalités spécifiques à PHP."
  • PL-SQL-Logging-Utility est une adaptation de log4j en PL / SQL.
  • Log4db2 est un utilitaire de journalisation pour DB2 pour LUW qui utilise des instructions SQL avec du code SQL PL.
  • Apache Log4cxx - Un cadre de journalisation pour C ++ calqué sur Apache log4j, qui utilise Apache Portable Runtime pour la plupart du code spécifique à la plate-forme et devrait être utilisable sur n'importe quelle plate-forme prise en charge par APR. Il est actuellement en incubation, la dernière version est la 0.10.0, sortie en 2008.
  • Log4r - Une bibliothèque de journalisation complète et flexible écrite en Ruby pour une utilisation dans les programmes Ruby. Il a été inspiré et fournit la plupart des fonctionnalités du projet Apache Log4j.

Voir également

Les références

Lectures complémentaires

Liens externes