Votre classe d'utilitaire de journalisation Java se présente-t-elle comme la source de vos journaux ? Apprenez à y remédier !

Dans l'environnement rapide du développement de logiciels modernes, une journalisation efficace est cruciale pour un débogage et une surveillance efficaces du système. Cependant, des numéros de ligne incohérents ou inexacts dans les sorties de journaux peuvent rendre le dépannage long. Récemment, j'ai identifié que notre utilitaire de journalisation interne se signalait comme la source des journaux. Il fallait résoudre ce problème pour améliorer la précision du journal.

Le problème

Lorsque vous utilisez une classe utilitaire personnalisée pour gérer les journaux, elle commencera à se signaler comme source du journal, car la classe utilitaire est celle qui appelle finalement le framework de journalisation réel (dans mon cas, c'était SLF4J , avec Log4J2 comme backend).

Donc, si la classe utilitaire s'appelle InternalLogger, le journal ressemblera à ceci :

2024-10-11T18:10:57,345 [finagle/netty4-6] (InternalLogger.java:34) INFO ...  

Ici, le fichier source et le numéro de ligne signalés pointent vers un emplacement dans l'utilitaire de journalisation lui-même, plutôt que vers l'endroit où l'appel du journal a été réellement effectué dans le code de l'application. Ce comportement atténue l'efficacité des journaux dans le débogage et l'identification rapide des problèmes.

La solution

J'ai d'abord pensé à parcourir manuellement la trace de la pile et à filtrer certains éléments avant de signaler le numéro de ligne. Cette approche serait très coûteuse et je ne voulais pas ralentir notre processus de journalisation.

Heureusement, j'ai trouvé dans cette réponse StackOverflow que SLF4J fournit une interface appelée LocationAwareLogger, prise en charge par Log4J2, nous pouvons donc filtrer la classe utilitaire en transmettant simplement le FQCN (nom de classe entièrement qualifié) de la classe utilitaire de journalisation.

Ma classe utilitaire d'origine ressemblait à ceci :

public class InternalLogger {

  private static final Logger LOG = LoggerFactory.getLogger(InternalLogger.class);

  public void log(EventLog eventLog) {
    //... get message and logLevel from eventLog
    switch (logLevel) {
      case DEBUG:
        LOG.debug(message);
        break;
      case WARN:
        LOG.warn(message);

Pour cette solution, j'ai déclaré la classe Logger FQCN et ajouté une fonction d'assistance privée pour se connecter avec un LocationAwareLogger :

private static final String LOGGER_UTIL_FQCN = InternalLogger.class.getName();

  private void locationAwareLog(int level, String message) {
    ((LocationAwareLogger) LOG).log(null, LOGGER_UTIL_FQCN, level, message, null, null);
  }

Et j'ai changé mon ancien code pour l'appeler s'il est pris en charge :

switch (logLevel) {
  case DEBUG:
    if (LOG instanceof LocationAwareLogger) {
      locationAwareLog(LocationAwareLogger.DEBUG_INT, message);
    } else {
      LOG.debug(message);
    }
    break;
  case WARN:
    if (LOG instanceof LocationAwareLogger) {
      locationAwareLog(LocationAwareLogger.WARN_INT, message);
    } else {
      LOG.warn(message);
    }
//...

Malheureusement, SLF4J ne fournit pas de moyen de fournir le niveau comme argument (c'est-à-dire LOG.log(level, message)). Si c'était le cas, le code serait un peu moins verbeux.

Après la mise en œuvre de ce changement, les journaux indiquent désormais avec précision le numéro de ligne de l'appelant, améliorant considérablement la traçabilité :

2024-10-11T18:45:26,692 [finagle/netty4-6] (ActualLogic.java:1059) INFO ...

Remarquez la différence : InternalLogger.java:34 versus ActualLogic.java:1059, qui indique un emplacement plus précis de l'origine du journal dans le code de l'application.

Conclusion

En intégrant LocationAwareLogger de SLF4J, j'ai transformé notre système de journalisation d'une source de confusion en un outil de diagnostic précis. Ce changement permet de signaler avec précision le numéro de ligne de l'appelant au lieu de celui de l'utilitaire de journalisation, améliorant ainsi considérablement notre capacité à diagnostiquer les problèmes rapidement et avec précision.

Cette amélioration rationalise non seulement le débogage, mais réduit également les temps de réponse lors de la résolution de problèmes logiciels.

Les développeurs confrontés à des défis similaires devraient envisager cette approche pour améliorer l'efficacité de leurs systèmes de journalisation. Grâce à des journaux plus clairs et plus précis, ils peuvent transformer des données autrefois ambiguës en informations exploitables, améliorant ainsi à la fois l’efficacité opérationnelle et la fiabilité des logiciels. Une journalisation optimisée est cruciale pour relever les défis du paysage de développement actuel et garantir des résultats logiciels de haute qualité.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!