Règles et conseils pour la journalisation?

Dans mon organisation, nous avons mis en place des règles / lignes directrices sur la journalisation que j'aimerais savoir si vous pouvez ajouter ou commenter.

Nous utilisons Java mais vous pouvez commenter en général la connexion - règles et conseils

1. Utilisez le niveau de journalisation correct

   • ERREUR: quelque chose s'est très mal passé et doit être réparé immédiatement
   • AVERTISSEMENT: le processus peut se poursuivre sans correction. L'application doit tolérer ce niveau mais l'avertissement doit toujours faire l'objet d'une enquête.
   • INFO: information qu'un processus important est terminé
   • DÉBOGUER. Est uniquement utilisé pendant le développement

2. Assurez-vous de savoir ce que vous enregistrez.

3. Évitez que la journalisation influence le comportement de l'application

La fonction de la journalisation doit être d'écrire des messages dans le journal.

1. Les messages de journal doivent être descriptifs, clairs, courts et concis.

Il n'y a pas beaucoup d'utilisation d'un message absurde lors du dépannage.

1. Mettez les bonnes propriétés dans log4j

Ajoutez que la bonne méthode et la bonne classe sont écrites automatiquement.

Exemple:

Fichier daté -web

log4j.rootLogger=ERROR, DATEDFILE
log4j.logger.org.springframework=INFO
log4j.logger.waffle=ERROR
log4j.logger.se.prv=INFO
log4j.logger.se.prv.common.mvc=INFO
log4j.logger.se.prv.omklassning=DEBUG

log4j.appender.DATEDFILE=biz.minaret.log4j.DatedFileAppender
log4j.appender.DATEDFILE.layout=org.apache.log4j.PatternLayout
log4j.appender.DATEDFILE.layout.ConversionPattern=%d{HH:mm:ss,SSS} %-5p [%C{1}.%M] - %m%n

log4j.appender.DATEDFILE.Prefix=omklassning.
log4j.appender.DATEDFILE.Suffix=.log
log4j.appender.DATEDFILE.Directory=//localhost/WebSphereLog/omklassning/

1. Valeur du journal.

Veuillez enregistrer les valeurs de l'application.

1. Préfixe du journal.

Indiquez de quelle partie de la demande la journalisation est écrite, de préférence avec quelque chose pour le préfixe convenu du projet, par exemple PANDORA_DB

1. La quantité de texte.

Soyez prudent afin qu'il n'y ait pas trop de texte de journalisation. Cela peut influencer les performances de l'application.

1. Format d'enregistrement:

-Il existe plusieurs variantes et méthodes à utiliser avec log4j mais nous aimerions une utilisation uniforme du format suivant, lorsque nous nous connectons à des exceptions:

logger.error("PANDORA_DB2: Fel vid hämtning av frist i TP210_RAPPORTFRIST", e);

Dans l'exemple ci-dessus, nous supposons que nous avons défini les propriétés log4j afin qu'il écrive automatiquement la classe et la méthode.

Utilisez toujours l'enregistreur et non les suivants:

System.out.println(), System.err.println(), e.printStackTrace()

Si l'application Web utilise notre framework, vous pouvez obtenir des informations d'erreur très détaillées auprès d'EJB, si vous utilisez try-catch dans le gestionnaire et la journalisation selon le modèle ci-dessus:

Dans notre projet, nous utilisons ce modèle de conversion avec lequel les noms de méthode et de classe sont écrits automatiquement. Ici, nous utilisons deux brevets différents pour la console et pour le datfileappender:

log4j.appender.CONSOLE.layout.ConversionPattern=%d{ABSOLUTE} %5p %c{1}:%L - %m%n

log4j.appender.DATEDFILE.layout.ConversionPattern=%d [%t] %-5p %c - %m%n

Dans les deux exemples ci-dessus, la méthode et la classe seront écrites. Dans le numéro de ligne de la console sera également écrit notre.

1. toString()

Veuillez en avoir un toString()pour chaque objet. EX:

@Override
public String toString() {
  StringBuilder sb = new StringBuilder();
  sb.append(" DwfInformation [ ");
  sb.append("cc: ").append(cc);
  sb.append("pn: ").append(pn);
  sb.append("kc: ").append(kc);
  sb.append("numberOfPages: ").append(numberOfPages);
  sb.append("publicationDate: ").append(publicationDate);
  sb.append("version: ").append(version);
  sb.append(" ]");
  return sb.toString();
}

au lieu d'une méthode spéciale qui rend ces sorties

public void printAll()
{
    logger.info("inbet: " + getInbetInput());
    logger.info("betdat: " + betdat);
    logger.info("betid: " + betid);
    logger.info("send: " + send);
    logger.info("appr: " + appr);
    logger.info("rereg: " + rereg);   
    logger.info("NY: " + ny);   
    logger.info("CNT: " + cnt);   
}

Y a-t-il quelque chose que vous pouvez ajouter, commenter ou trouver discutable avec ces façons d'utiliser la journalisation? N'hésitez pas à répondre ou à commenter même s'il n'est pas lié à Java, Java et log4j n'est qu'une implémentation de la façon dont cela est raisonné.

En tant qu'extension de votre règle de journalisation d'où provient l'instruction de journal dans l'application, vous souhaiterez peut-être ajouter des indicateurs de journalisation au niveau du module. Au lieu de tout enregistrer, tout le temps, cela vous permet de cibler de manière sélective des sections de votre application. Il y a des frais généraux dans cela, et vous devez créer une installation qui vous permet d'activer / désactiver cette journalisation. Idéalement, vous seriez en mesure d'activer / désactiver à la volée pendant l'exécution de l'application.

J'ai l'habitude de voir un calque sous le débogage que j'appelle "trace", mais ce n'est pas nécessairement un terme universel. Les traces de journalisation de niveau "trace" autant que vous le pouvez, y compris l'entrée / sortie du module, les horodatages avec entrée / sortie et les points bonus pour capturer les valeurs passées. Évidemment, cela génère BEAUCOUP de données et ce n'est pas quelque chose que vous allumez bon gré mal gré. Mais il présente des avantages en termes de débogage lorsque vous ne pouvez pas vous attacher au processus ou que vous ne disposez pas d'un vidage de mémoire de l'application errante.

J'aime voir les références de fichiers / modules et les horodatages avec mes informations de journal. Il peut être utile lorsque vous essayez de traquer les conditions de concurrence entre les threads ainsi que de coordonner les activités de plusieurs zones de l'application. Pour être juste, je connais des gens qui pensent que ces détails encombrent le fichier journal. L'ajout de l'horodatage est quelque chose à discuter avec l'équipe. (Toutes mes excuses si log4j le fait déjà.)

Si la journalisation n'est pas prise en charge par son propre thread / processus, c'est quelque chose à considérer également. Au lieu de faire attendre le thread d'application pour que la journalisation soit traitée, le message du journal est transmis au gestionnaire de journaux et le thread d'application continue son chemin joyeux. Alternativement, la création d'une sorte de mécanisme de tampon pour gérer les messages du journal est une autre façon d'accélérer la réactivité de l'application.

Avoir des contrôles sur la taille et l'historique des fichiers journaux est une autre fonctionnalité à considérer. Vous ne voulez pas que l'application fasse exploser tout l'espace disque du système hôte, ni ne souhaitez nécessairement conserver tous les fichiers journaux pour l'éternité.

Une chose à garder à l'esprit est de vérifier le niveau de journalisation avant d'effectuer toute sorte d'opérations de chaîne pour la journalisation. C'est-à-dire, n'allez pas à tout le travail de configuration d'un formateur de date ou de concaténation d'un tas de chaînes pour créer le message de journal si vous n'allez pas réellement le journaliser. C'est juste un travail gaspillé qui ralentit votre application.

Pour info, le projet Apache Commons a une ToStringBuilder classe qui simplifie la création de vos toString()méthodes.

Je ne trouve rien de contestable dans ce que vous avez ajouté ici Nick. C'est ainsi que je le fais depuis un certain temps. Le message que vous avez fourni est très détaillé et peut probablement être utilisé comme une sorte de tutoriel pour la journalisation. Cependant, je veux ajouter une chose ici, qui est: Dans de nombreux endroits, j'ai vu des chaps utilisant la journalisation conditionnelle, par exemple:

     if(env_local)
     {
     write_to_local();
     }    
     else if(env_IT)
     {
     write_to_IT();
     } 
     else if(env_PROD)
     {
     write_to_prod();
     } 
     else
     dosomething();

Je pense que ce type de traçage ou de débogage conditionnel n'est pas la meilleure solution.

En plus de consigner la classe / méthode qui a provoqué l'erreur, il serait utile de consigner également les paramètres passés dans cette méthode. Savoir où une erreur a été déclenchée n'est pas très utile si elle ne se produit qu'une fois sur 1000; vous devez également savoir quelles données ont provoqué l'erreur.

J'ai également trouvé utile d'avoir une variable qui définit le niveau de journalisation par défaut pour une application. De cette façon, vous pouvez avoir du code DEBUG et INFO avec le code WARNING et ERROR. Lors de l'exécution en mode production, vous ne par défaut pas afficher les informations DEBUG, mais quand un bogue apparaît, vous pouvez mettre à jour un indicateur et commencer à écrire des messages DEBUG dans le journal.

L'exploitation forestière est la plupart du temps une préoccupation transversale. Java seul n'est pas suffisamment expressif pour vous permettre de séparer la journalisation de vos logiques d'entreprise réelles. Cela signifie que vous ne pouvez pas, par exemple, simplement prendre une méthode et la mettre dans un autre projet, mais vous devez supprimer et ajuster tous vos journaux avant de le faire. Et c'est seulement la partie émergée de l'iceberg.

Pour éviter cela et d'autres problèmes lors du mélange de la journalisation et des logiques professionnelles "réelles", vous devez envisager d'utiliser une programmation orientée aspect. Pour Java, le framework le plus utilisé serait AspectJ. Il y a cette vidéo YouTube de Google Tech pourparlers qui explique assez bien AspectJ et ses utilisations au-delà de la journalisation. Vous trouverez bien sûr de nombreux exemples pour vous connecter ici sur stackexchange .

Une chose que je suggérerais serait que vous ayez un moyen d'avoir plusieurs contextes de journalisation associés à un fichier journal particulier et de faire en sorte que tout ce qui est écrit dans n'importe quel contexte de journalisation soit journalisé à moins que le code ne demande explicitement au contexte de journalisation de supprimer son contenu. Une telle conception permettra de capturer des journaux assez détaillés au cours d'une opération et de les supprimer si l'opération réussit, mais de les avoir à disposition en cas d'échec. En l'absence d'une telle fonctionnalité de journalisation, la disponibilité de bons journaux en cas d'échec peut nécessiter qu'une application gaspille beaucoup de temps à enregistrer des données inutiles dans les 99,99% des fois où tout fonctionne.