Comment utiliser correctement la journalisation Java

Concernant les logs, tout le monde pense que c'est relativement simple. Il suffit d'introduire les packages de dépendances pertinents, et le reste consiste à "profiter" de l'impression des informations dont nous avons besoin dans le projet. Mais souvent, plus les choses sont simples, plus il nous est facile de les ignorer, ce qui conduit à l'apparition de bogues qui ne devraient pas exister. En tant que programmeur rigoureux, comment pouvons-nous laisser cela se produire ? Découvrons donc les bonnes postures d’utilisation des logs.

Texte

Spécifications du journal

Nom

Le premier est le nom du fichier journal Essayez de vous familiariser avec le nom, et l'équipe également Une convention de dénomination unifiée doit être utilisée, sinon les fichiers journaux « sales et désordonnés » affecteront l'efficacité de chacun dans le dépannage des problèmes. Il est recommandé de le nommer « projectName_logName_logType.log », afin que grâce au nom, vous puissiez savoir clairement à quel projet appartient le fichier journal, de quel type il s'agit et quelle fonction il a. Par exemple, dans notre projet MessageServer, le nom du fichier journal lié à la surveillance des consommateurs Rabbitmq peut être défini comme « messageserver_rabbitmqconsumer_monitor.log ».

Durée de stockage

Concernant la durée de stockage des journaux, il est recommandé de conserver les fichiers journaux ordinaires pendant 15 jours. Si cela est plus important, elle peut être prolongée en fonction de la situation réelle. , veuillez vous référer à l'espace disque du serveur respectif et à la taille du fichier journal. Faites le meilleur choix.

Niveau de journalisation

Les niveaux de journalisation courants sont les suivants :

Niveau DEBUG : enregistre les informations relatives au débogueur. Niveau INFO : enregistre des informations significatives sur le fonctionnement normal du programme. Niveau WARN : enregistre les informations susceptibles de provoquer des erreurs. Niveau ERREUR : enregistrez des informations sur l'erreur du programme actuel, qui nécessite une attention et un traitement. Niveau fatal : indique qu'une erreur grave s'est produite et que le programme va interrompre son exécution.

Il est recommandé d'utiliser ces quatre niveaux dans le projet, ERROR, WARN, INFO et DEBUG.

Posture correcte

1. Jugez à l'avance le niveau du journal

//条件判断if(logger.isDebugEnabled){
    logger.debug("server info , id : " + id + ", user : " + user);
}//使用占位符logger.debug("server info , id : {}, user : {}",id,user);

Les journaux de niveau DEBUG et INFO existent relativement fréquemment dans notre programme. Lorsque notre projet devient plus grand et que le nombre de journaux augmente, afin d'exécuter le programme plus efficacement, nous devons juger en fonction des conditions ou de l'espace réservé pour imprimer le journal. Pourquoi? Si le niveau de journalisation configuré dans notre projet est WARN, alors pour notre instruction de sortie de journal suivante 'logger.debug("server info, id: " + id + ", user: " + user);', bien que le journal ne le soit pas imprimé, mais l'opération de concaténation de chaînes sera effectuée. Ici, notre utilisateur est un objet instance, donc la méthode toString sera également exécutée, ce qui gaspille beaucoup de ressources système.

2. Évitez la sortie de journaux redondante

Dans notre environnement de production, la sortie de journaux DEBUG est généralement interdite. La fréquence d'impression est très élevée, ce qui peut facilement causer de graves dommages aux programmes en cours d'exécution normaux. . Impact, nous avons rencontré des situations similaires dans nos récents projets.

Ensuite, il est temps d'apprendre à utiliser l'attribut d'additivité

<logger name="xx" additivity="true">

S'il est configuré sur true ici, c'est la situation par défaut. À ce moment, le Logger actuel héritera de l'Appender du Logger parent. . Pour le dire franchement, c'est le courant En plus d'être affiché dans le fichier journal actuel, la sortie du journal sera également affichée dans le fichier parent. Donc, généralement, afin d'éviter des impressions répétées, nous définirons ce paramètre sur false pour réduire les sorties inutiles.

3. Assurez-vous que les informations de l'enregistrement du journal sont complètes.

Dans notre code, le contenu de l'enregistrement du journal doit inclure la pile d'exceptions. Veuillez ne pas générer de journaux simples tels que « Erreur XX » à volonté. . Ceci est important car le débogage des erreurs n’est pas utile. Par conséquent, nous devons apporter des informations sur la pile lors de l'enregistrement d'exceptions, telles que

logger.error("rabbitmq consumer error,cause : "+e.getMessage(),e);

. N'oubliez pas que lors de la sortie d'une instance d'objet, vous devez vous assurer que l'objet remplace la méthode toString, sinon seule sa valeur hashCode sera affichée.

4. Définissez la variable logger comme statique

private static final Logger logger = LoggerFactory.getLogger(XX.class);

Assurez-vous qu'un objet n'utilise qu'un seul objet Logger pour éviter de le recréer à chaque fois, sinon cela pourrait provoquer un MOO.

5. Utilisez correctement le niveau de journalisation

try{    //..}catch(xx){
    logger.info(..);
}

De cette façon, toutes les informations qui étaient à l'origine ERREUR seront imprimées dans le fichier journal INFO, et les collègues non informés regarderont toujours le journal des erreurs. , et le problème est introuvable, cela affectera l'efficacité du travail, n'est-ce pas ?

6 Il est recommandé d'utiliser la combinaison slf4j+logback

La bibliothèque de connexion elle-même a déjà implémenté slf4j. interface, il n'est donc pas nécessaire de l'introduire. Il n'y a pas d'adaptateurs redondants et la connexion présente également plus d'avantages. Il est recommandé que les nouveaux projets puissent utiliser cette combinaison. Une autre chose à noter est qu'après avoir introduit slf4j, nous devons faire attention à savoir si la bibliothèque de journaux réellement utilisée est introduite par nous, ou si elle peut utiliser la bibliothèque de journaux apportée par notre package de dépendance tiers, ce qui peut rendre notre journal invalide. .

7. Analyse de l'agrégation des journaux

L'agrégation des journaux peut unifier les journaux entre différents serveurs pour l'analyse et le traitement. Aujourd'hui, la pile technologique ELK est également EFG (fluentd+elasticsearch+grafana). solutions open source relativement matures.

En prenant ELK comme exemple, vous pouvez lire directement le fichier journal imprimé par l'application via logstash sur notre serveur, ou vous pouvez également configurer les informations de socket pertinentes dans le fichier de configuration du journal de notre projet et l'imprimer. À ce stade, les informations du journal sont directement sorties dans logstash. Ensuite, il est remis à elasticsearch pour le stockage et l'affichage Kibana.

Tutoriels associés : Tutoriel vidéo Java

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!