Se connecter en Java et en général: Meilleures pratiques?

Dans la réponse de@cletus , il a écrit sur le problème de

if (log.isDebugEnabled()) {
  log.debug("val is " + value);
}

Qui pourrait être surmonté en utilisant SL4J. Il fournit une aide au formatage

log.debug("val is {}", value);

Où le message n'est construit que si le niveau est debug.

De nos jours, l'utilisation de SL4J et de son enregistreur compagnon, Logback, est donc conseillée pour des raisons de performances et de stabilité.

En ce qui concerne l'instanciation des enregistreurs, j'ai eu un certain succès en utilisant un modèle Java Eclipse pour configurer mes enregistreurs:

private static Logger log = Logger.getLogger(${enclosing_type}.class);

Cela évite le problème d'une JVM qui s'occupe de votre trace de pile et réduit (trivialement, peut-être) la surcharge de la création de la trace de pile en premier lieu.

La grande chose à propos de l'utilisation d'un modèle comme celui-ci est que vous pouvez le partager avec votre équipe si vous souhaitez définir une norme cohérente pour les enregistreurs.

Il on dirait qu'IntelliJ prend en charge le même concept pour une variable de modèle représentant le nom du type englobant. Je ne vois pas de moyen de le faire facilement dans NetBeans.

L'option préférée pour le type de configuration log4j que vous décrivez est d'utiliser le fichier de configuration log4j. Cela permet aux utilisateurs de votre implémentation de faire exactement ce que vous demandez, car ils peuvent remplacer votre configuration plus tard avec quelque chose de plus adapté à leur propre implémentation. Voir ici pour un travail très complet d'apprêt.

J'ai probablement volé ça quelque part, mais c'est sympa.

Il réduit le risque de mélanger les enregistreurs lors de la copie et du refactoring pasti^h^h^h, et il est moins à taper.

Dans votre code:

private final static Logger logger = LoggerFactory.make();

...et dans LoggerFactory:

public static Logger make() {
    Throwable t = new Throwable();
    StackTraceElement directCaller = t.getStackTrace()[1];
    return Logger.getLogger(directCaller.getClassName());
}

(Notez que le stackdump est effectué lors de l'initialisation. La stacktrace ne sera probablement pas optimisée par la JVM mais il n'y a en fait aucune garantie)

Je passe en revue les niveaux de journal d'une application et je détecte actuellement un modèle:

private static final Logger logger = Logger.getLogger(Things.class)

public void bla() {
  logger.debug("Starting " + ...)
  // Do stuff
  ...
  logger.debug("Situational")

  // Algorithms
  for(Thing t : things) {
    logger.trace(...)
  }

  // Breaking happy things
  if(things.isEmpty){
    logger.warn("Things shouldn't be empty!")
  }

  // Catching things
  try {
    ...
  } catch(Exception e) {
    logger.error("Something bad happened")
  }

  logger.info("Completed "+...)
}

Un log4j2-fichier définit une prise appender, avec un basculement de fichier appender. Et un appender de console. Parfois, j'utilise des marqueurs log4j2 lorsque la situation l'exige.

Pensait qu'une perspective supplémentaire pourrait aider.

Voici les lignes directrices que je suis dans tous mes projets pour assurer une bonne performance. Je suis venu pour former cet ensemble de lignes directrices basées sur les entrées de diverses sources dans l'Internet.

Comme aujourd'hui, je crois que Log4j 2 est de loin la meilleure option pour se connecter en Java.

Les points de référence sont disponibles ici. La pratique que je suis pour obtenir les meilleures performances est la suivante:

1. J'évite d'utiliser SLF4J pour le moment pour ce qui suit raisons:
   • Il a des problèmes de concurrence avec les marqueurs que je veux utiliser pour gérer la journalisation des instructions SQL (Marqueurs pas aussi puissants que slf4j - Reportez-vous au premier commentaire de Ralph Goers)
   • Il ne prend pas en charge le Lambda Java 8 que, encore une fois, je veux utiliser pour de meilleures performances (Supporte l'expression lambda dans l'enregistreur )
2. Faites toute la journalisation régulière en utilisant un enregistreur asynchrone pour de meilleures performances
3. Erreur de journal messages dans un fichier séparé en utilisant synchrone logger parce que nous voulons voir les messages d'erreur dès qu'il se produit
4. N'utilisez pas les informations de localisation, telles que le nom de fichier, le nom de classe, le nom de méthode, le numéro de ligne dans la journalisation régulière car pour dériver ces informations, le framework prend un instantané de la pile et la parcourt. Ceci a des répercussions sur la performance. Par conséquent, utilisez les informations de localisation uniquement dans le journal des erreurs et non dans le journal normal
5. Puisque nous enregistrons les erreurs dans un fichier séparé, il est très important que nous enregistrons les informations de contexte également dans le journal des erreurs. Par exemple, si l'application a rencontré une erreur lors du traitement d'un fichier, imprimez le nom de fichier et l'enregistrement de fichier en cours de traitement dans le fichier journal des erreurs avec la stacktrace
6. Le fichier journal doit être grep-able et facile à comprendre. Par exemple, si une application traite les enregistrements client dans plusieurs fichiers, chaque message de journal doit être comme ci-dessous:

12:01:00,127 INFO FILE_NAME=file1.txt - Processing starts
12:01:00,127 DEBUG FILE_NAME=file1.txt, CUSTOMER_ID=756
12:01:00,129 INFO FILE_NAME=file1.txt - Processing ends

1. Enregistrez toutes les instructions SQL à l'aide d'un marqueur SQL comme indiqué ci-dessous et utilisez un filtre pour l'activer ou le désactiver:

private static final Marker sqlMarker = 
  MarkerManager.getMarker("SQL");

private void method1() {
    logger.debug(sqlMarker, "SELECT * FROM EMPLOYEE");
}

1. Consigner tous les paramètres à l'aide de Java 8 Lambdas. Cela sauvera l'application du message de formatage lorsque le niveau de journal donné est désactivé:

int i=5, j=10;
logger.info("Sample output {}, {}", ()->i, ()->j);

1. N'utilisez pas la concaténation de chaînes. Utilisez le message paramétré comme indiqué ci-dessus

2. Utiliser dynamique rechargement de la configuration de journalisation afin que l'application recharge automatiquement les modifications de la configuration de journalisation sans avoir besoin de redémarrer l'application

3. Ne pas utiliser printStackTrace() ou System.out.println()

4. La demande doit arrêter l'enregistreur avant de sortir:

LogManager.shutdown();

1. Enfin, pour la référence de tout le monde, j'utilise la configuration suivante:

<?xml version="1.0" encoding="UTF-8"?>
<Configuration monitorinterval="300" status="info" strict="true">
    <Properties>
        <Property name="filePath">${env:LOG_ROOT}/SAMPLE</Property>
        <Property name="filename">${env:LOG_ROOT}/SAMPLE/sample
        </Property>
        <property name="logSize">10 MB</property>
    </Properties>
    <Appenders>
        <RollingFile name="RollingFileRegular" fileName="${filename}.log"
            filePattern="${filePath}/sample-%d{yyyy-dd-MM}-%i.log">
            <Filters>
                <MarkerFilter marker="SQL" onMatch="DENY"
                    onMismatch="NEUTRAL" />
            </Filters>
            <PatternLayout>
                <Pattern>%d{HH:mm:ss,SSS} %m%n
                </Pattern>
            </PatternLayout>
            <Policies>
                <TimeBasedTriggeringPolicy
                    interval="1" modulate="true" />
                <SizeBasedTriggeringPolicy
                    size="${logSize}" />

            </Policies>
        </RollingFile>
        <RollingFile name="RollingFileError" 
            fileName="${filename}_error.log"
            filePattern="${filePath}/sample_error-%d{yyyy-dd-MM}-%i.log"
            immediateFlush="true">
            <PatternLayout>
                <Pattern>%d{HH:mm:ss,SSS} %p %c{1.}[%L] [%t] %m%n
                </Pattern>
            </PatternLayout>
            <Policies>
                <TimeBasedTriggeringPolicy
                    interval="1" modulate="true" />
                <SizeBasedTriggeringPolicy
                    size="${logSize}" />
            </Policies>
        </RollingFile>
    </Appenders>
    <Loggers>
        <AsyncLogger name="com"
            level="trace">
            <AppenderRef ref="RollingFileRegular"/>
        </AsyncLogger>
        <Root includeLocation="true" level="trace">
            <AppenderRef ref="RollingFileError" level="error" />
        </Root>
    </Loggers>
</Configuration>

1. Les dépendances Maven requises sont ici:

<dependency>
    <groupId>org.apache.logging.log4j</groupId>
    <artifactId>log4j-api</artifactId>
    <version>2.8.1</version>
</dependency>
<dependency>
    <groupId>org.apache.logging.log4j</groupId>
    <artifactId>log4j-core</artifactId>
    <version>2.8.1</version>
</dependency>
<dependency>
    <groupId>com.lmax</groupId>
    <artifactId>disruptor</artifactId>
    <version>3.3.6</version>
</dependency>
<!-- (Optional)To be used when working 
with the applications using Log4j 1.x -->
<dependency>
    <groupId>org.apache.logging.log4j</groupId>
    <artifactId>log4j-1.2-api</artifactId>
    <version>2.8.1</version>
</dependency>

En plus, je pense qu'il est important de signifier une façade de journalisation simple pour Java (SLF4J) (http://www.slf4j.org / ). En raison de certains problèmes d'utilisation de différents frameworks de journalisation dans des parties diversifiées d'un grand projet, SLF4J est la norme de facto pour résoudre un problème pour gérer ces parties avec succès, n'est-ce pas?

La deuxième notion: il semble que certaines tâches de la vieille école puissent être substituées par Aspect-Oriented-Programming, Spring frmwrk a sa propre implémentation , AOP-approche pour la journalisation considéréeici à StackOverflow etici sur Spring blog.