TOC

Guide sur les appendices de fichiers roulants

Un guide pour faire défiler les appendices de fichiers

1. Vue d'ensemble

Bien que les fichiers journaux transmettent souvent des informations utiles, ils grossissent naturellement avec le temps et, s'ils sont autorisés à se développer indéfiniment, leur taille risque de poser problème.

Les bibliothèques de journalisation résolvent ce problème à l'aide derolling file appenders, which automatically “roll” or archive the current log file and resume logging in a new file lorsque certaines conditions prédéfinies se produisent, évitant ainsi les temps d'arrêt indésirables.

Dans cet article, nous verrons comment configurer des ajouts de fichiers en continu dans certaines des bibliothèques de journalisation les plus utilisées - Log4j, Log4j2 et Slf4j.

Nous allons montrer comment rouler les fichiers journaux en fonction de la taille, de la date / heure et d'une combinaison de taille et de date / heure. Nous montrerons également comment configurer chaque bibliothèque pour compresser puis supprimer automatiquement les anciens fichiers journaux, nous évitant ainsi d'écrire du code d'entretien fastidieux.

2. Notre exemple d'application

Commençons par un exemple d'application qui enregistre certains messages. Ce code est basé sur Log4j mais il peut être facilement modifié pour fonctionner avec Log4j2 ou Slf4j: 

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);
        }
    }
}

L'application est assez naïve - elle écrit certains messages dans une boucle, avec un court délai entre les itérations. Avec 2 000 boucles à exécuter et une pause de 100 ms dans chaque boucle, l’application devrait durer un peu plus de trois minutes.

Nous utiliserons cet exemple pour illustrer plusieurs fonctionnalités de différents types d'ajouteurs de fichiers en continu.

3. Appenders de fichiers roulants dans Log4j

3.1. Dépendances Maven

Tout d'abord, pour utiliser Log4j dans votre application, ajoutez cette dépendance au fichierpom.xml de votre projet: 


    log4j
    log4j
    1.2.17

Pour utiliser les ajouts supplémentaires fournis parapache-log-extras que nous utiliserons dans les exemples suivants, ajoutez la dépendance suivante, en veillant à utiliser la même version que nous avons déclarée pour Log4j afin d'assurer une compatibilité totale: 


    log4j
    apache-log4j-extras
    1.2.17

Vous pouvez trouver la dernière version deLog4j etApache Log4j Extras sur Maven Central.

3.2. Déplacement en fonction de la taille du fichier

Dans Log4j, comme dans les autres bibliothèques de journalisation, le roulement de fichier est délégué à l'appender. Examinons la configuration d'un appender de fichier tournant dans Log4j qui roule en fonction de la taille du fichier:

Ici, nous avons configuré Log4j pour rouler le fichier journal lorsque sa taille atteint 5 Ko, en utilisant le paramètreMaxFileSize. Nous avons également demandé à Log4j de conserver au maximum deux fichiers journaux enroulés en utilisant le paramètreMaxBackupIndex.

Lorsque nous avons exécuté notre exemple d'application, nous avons obtenu les fichiers suivants: 

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.2

Qu'est-il arrivé? Log4j a commencé à écrire dans le fichierapp.log. Lorsque la taille du fichier a dépassé la limite de 5 Ko, Log4j a déplacéapp.log versapp.log.1, a créé un tout nouveauapp.log vide et a continué à écrire de nouveaux messages de journal dansapp.log.

Ensuite, après que le nouveauapp.log a dépassé la limite de 5 Ko, ce processus de laminage a été répété. Cette fois,app.log.1 a été déplacé versapp.log.2,, laissant de la place pour un autre nouveauapp.log vide.

Le processus de roulement a été répété plusieurs fois pendant l'exécution, mais comme nous avons configuré notre appender pour conserver au plus deux fichiers laminés, il n'y a aucun fichier appeléapp.log.3.

Nous avons donc résolu l'un des problèmes initiaux, car nous sommes maintenant en mesure de définir une limite pour la taille des fichiers journaux générés.

D'autre part, lorsque nous avons vérifié la première ligne deapp.log.2, elle contenait le message lié à la 700e itération, ce qui signifie que tous les messages de journal précédents avaient été perdus: 

2016-11-27 10:28:34 INFO  This is the 700 time I say 'Hello World'.

Voyons si nous pouvons proposer une configuration mieux adaptée à un environnement de production, où la perte de messages de journal ne peut pas être considérée comme la meilleure approche.

Pour ce faire, nous allons utiliser d'autres appenders Log4j plus puissants, flexibles et configurables, livrés dans un package dédié appeléapache-log4j-extras.

Les ajouts contenus dans cet artefact offrent de nombreuses options pour affiner le roulement du journal, et ils introduisent les concepts distincts detriggering policy etrolling policy. Letriggering policy décrit le moment où un roulement doit se produire, tandis que lerolling policy décrit comment le roulement doit être effectué. Ces deux concepts sont essentiels au roulement des fichiers journaux et sont utilisés de manière plus ou moins explicite par d'autres bibliothèques, comme nous le verrons bientôt.

3.3. Roulage avec compression automatique

Revenons à l'exemple Log4j et améliorons notre configuration en ajoutant la compression automatique des fichiers roulés pour gagner de la place:

Avec l'élémenttriggering policy, nous avons déclaré que le roulement devrait se produire lorsque le journal dépasse la taille de 5 120 octets.

Dans la baliserolling policy,, le paramètreActiveFileName indique le chemin des principaux fichiers journaux contenant les derniers messages et le paramètreFileNamePattern spécifie un modèle décrivant quel doit être le chemin de les fichiers roulés. Notons qu’il s’agit bien d’un modèle car l’espace réservé spécial%i sera remplacé par l’index du fichier roulé.

Notons également queFileNamePattern se termine par une extension «.gz”. Chaque fois que nous utilisons une extension associée à un format compressé pris en charge, les anciens fichiers roulés sont compressés sans effort supplémentaire de notre part.

Maintenant, lorsque nous exécutons l'application, nous obtenons un ensemble de fichiers journaux différent: 

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.log

Le fichierapp.current.log est l'endroit où les derniers journaux se sont produits. Les journaux précédents ont été roulés et compressés lorsque leur taille a atteint la limite définie.

3.4. Roulement basé sur la date et l'heure

Dans d'autres scénarios, vous souhaiterez peut-être configurer Log4j pour rouler les fichiers en fonction de la date et de l'heure des messages du journal au lieu de la taille du fichier. Dans une application Web, par exemple, vous pouvez souhaiter que tous les messages de journal soient émis le même jour dans le même fichier journal.

Pour ce faire, vous pouvez utiliser lesTimeBasedRollingPolicy. Avec cette stratégie, il est obligatoire de spécifier un modèle pour le chemin du fichier journal contenant un espace réservé lié à l'heure. Chaque fois qu'un message de journal est émis, l'appender vérifie le chemin d'accès au journal résultant. S'il diffère du dernier chemin utilisé, un roll se produira. Voici un exemple rapide qui configure un tel appender:

3.5. Roulage en fonction de la taille et du temps

En combinant lesSizeBasedTriggeringPolicy et lesTimeBasedRollingPolicy,, vous pouvez obtenir un appender qui roule en fonction de la date / heure, et lorsque la taille du fichier atteint la limite définie, il roule également en fonction de la taille:

Lorsque nous avons exécuté notre application avec cette configuration, nous avons obtenu les fichiers journaux suivants: 

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.log

Le fichierapp.19-26.1481393470902.log est l'endroit où la journalisation actuelle a lieu. Comme vous pouvez le voir, tous les journaux dans l'intervalle entre 19:25 et 19:26 sont stockés dans plusieurs fichiers journaux compressés avec des noms commençant par «app.19-25″. L'espace réservé“%i” est remplacé par un nombre toujours croissant .

4. Appenders de fichiers en continu dans Log4j2

4.1. Dépendances Maven

Pour utiliser Log4j2 comme bibliothèque de journalisation préférée, nous devons mettre à jour le POM de notre projet avec la dépendance suivante: 


    org.apache.logging.log4j
    log4j-core
    2.7

Comme d'habitude, vous pouvez trouver leslatest version sur Maven Central.

4.2. Déplacement en fonction de la taille du fichier

Modifions notre exemple d'application pour utiliser les bibliothèques de journalisation Log4j2 et explorons maintenant comment nous pouvons configurer le transfert de fichiers en fonction de la taille du fichier journal dans le fichier de configuration delog4j2.xml: 


    
        %d{yyyy-MM-dd HH:mm:ss} %p %m%n

Dans la balisePolicies, nous avons spécifié toutes les politiques de déclenchement que nous voulons appliquer. OnStartupTriggeringPolicy déclenche un jet à chaque démarrage de l'application, ce qui peut être utile pour les applications autonomes. Nous avons ensuite spécifié unSizeBasedTriggeringPolicy indiquant qu'un roulement devrait se produire chaque fois que le fichier journal atteint 5 Ko.

4.3. Roulement basé sur la date et l'heure

À l'aide des politiques proposées par Log4j2, configurons un appender pour rouler et compresser le fichier journal en fonction du temps: 


    
        %d{yyyy-MM-dd HH:mm:ss} %p %m%n

Ici, la clé est l'utilisation deTimeBasedTriggeringPolicy qui nous permet d'utiliser des espaces réservés liés au temps dans le modèle des noms de fichiers roulés. Notez que puisque nous n'avions besoin que d'une seule politique de déclenchement, nous n'avons pas à utiliser la balisePolicies comme nous l'avons fait dans l'exemple précédent.

4.4. Roulage en fonction de la taille et du temps

Comme décrit précédemment, un scénario plus convaincant consiste à rouler et à compresser les fichiers journaux en fonction du temps et de la taille. Voici un exemple de la manière dont nous pouvons configurer Log4j2 pour cette tâche: 


    
        %d{yyyy-MM-dd HH:mm:ss} %p %m%n

Avec cette configuration, nous avons indiqué qu'un roulement devrait avoir lieu en fonction du temps et de la taille. L'appender est capable de comprendre l'intervalle de temps auquel nous faisons référence en raison du modèle utilisé pour le nom de fichier, "app.%d{MM-dd-yyyy-HH-mm}.%i.log.gz”, qui définit implicitement un roulement toutes les minutes et compresse le fichier roulé.

Nous avons également ajouté unDefaultRolloverStrategy pour supprimer les anciens fichiers roulés correspondant à certains critères. Nous configurons la nôtre pour supprimer les fichiers correspondant au modèle donné lorsqu'ils ont plus de 20 jours.

4.5. Dépendances Maven

Pour utiliser Log4j2 comme bibliothèque de journalisation préférée, nous devons mettre à jour le POM de notre projet avec la dépendance suivante: 


    org.apache.logging.log4j
    log4j-core
    2.7

Comme d'habitude, vous pouvez trouver leslatest version sur Maven Central.

5. Appenders de fichier roulant dans Slf4j

5.1. Dépendances Maven

Lorsque vous souhaitez utiliser Slf4j2 avec un backend Logback comme bibliothèques de journalisation, ajoutez cette dépendance à vospom.xml: 


    ch.qos.logback
    logback-classic
    1.1.7

Comme d'habitude, vous pouvez trouver leslatest version sur Maven Central.

5.2. Déplacement en fonction de la taille du fichier

Voyons maintenant comment utiliser Slf4j à la place, avec son back-end par défautLogback. Voyons comment nous pouvons configurer le fichier roulant dans le fichier de configurationlogback.xml, qui est placé dans le chemin de classe de l'application: 


    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

De nouveau, nous rencontrons le concept de politique évolutive. Le mécanisme de base est le même que celui utilisé par Log4j et Log4j2. LeFixedWindowRollingPolicy nous permet d'utiliser un espace réservé d'index dans le modèle de nom du fichier roulé.

Lorsque la taille du fichier journal dépasse la limite configurée, un nouveau fichier est alloué et l'ancien contenu est stocké en tant que premier fichier de la liste, ce qui déplace les fichiers existants d'un emplacement supplémentaire.

5.3. Roulement basé sur le temps

Dans Slf4j, nous pouvons générer un fichier journal en fonction du temps en utilisant lesTimeBasedRollingPolicy fournis. Cette stratégie nous permet de spécifier le nom de modèle du fichier en continu à l'aide d'espaces réservés liés à l'heure et à la date: 


    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. Roulage en fonction de la taille et du temps

Si vous avez besoin de rouler un fichier à la fois en fonction de l'heure et de la taille, vous pouvez utiliser lesSizeAndTimeBasedRollingPolicy fournis. Lorsque vous utilisez cette stratégie, vous devez spécifier un espace réservé lié au temps et un espace réservé pour l'index.

Chaque fois que la taille du fichier journal pour un certain intervalle de temps dépasse la limite de taille configurée, un autre fichier journal avec la même valeur pour l'espace réservé lié au temps mais avec un index incrémenté est créé: 


    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. Conclusion

Comme nous l'avons vu, l'utilisation d'une bibliothèque de journalisation pour rouler les fichiers vous évite de gérer les fichiers de journalisation manuellement, vous permettant ainsi de vous concentrer sur le développement de votre logique métier. Les ajouts de fichiers roulants sont un outil précieux qui devrait figurer dans la boîte à outils de chaque développeur.

Comme d'habitude, vous trouverez les sourceson GitHub, où les exemples d'applications présentés dans cet article sont configurés pour se connecter en utilisant plusieurs configurations de roulement différentes afin de vous permettre de trouver une bonne configuration de base à peaufiner davantage en fonction de votre Besoins.

Related