web-dev-qa-db-fra.com

Pourquoi le niveau TRACE existe-t-il et quand devrais-je l'utiliser plutôt que DEBUG?

Dans Log4J, Slf4J et quelques autres cadres de journalisation en Java, vous avez deux niveaux de "développeur" pour la journalisation:

  • DÉBOGUER
  • TRACE

Je comprends ce que fait DEBUG, car l'explication est claire:

Le niveau DEBUG désigne les événements d'information à granularité fine qui sont les plus utiles pour déboguer une application.

Mais le niveau TRACE n'est pas très spécifique sur son cas d'utilisation:

Le niveau TRACE désigne des événements d'information plus fins que le DEBUG

(Source: le log4J JavaDoc )

Cela ne me dit ni comment ni quand utiliser TRACE. Fait intéressant, ce n'est pas un niveau de gravité défini dans le standard syslog . Googler pour la différence entre TRACE et DEBUG semble renvoyer "utilisez DEBUG, oh, et il y a aussi TRACE". Je n'ai pas pu trouver de cas d'utilisation spécifique pour le niveau TRACE. Le mieux que j'ai pu trouver était cette ancienne page wiki débattre du mérite de l'existence du niveau.

En tant qu'architecte, cela soulève beaucoup de drapeaux et de questions dans ma tête. Si un jeune développeur me demandait d'ajouter TRACE à mon architecture, je le bombardais de questions:

  • Quels sont quelques exemples d'informations qui devraient être enregistrées avec TRACE et non avec DEBUG?
  • Quel problème spécifique puis-je résoudre en enregistrant ces informations?
  • Dans ces exemples, quelles sont les propriétés des informations enregistrées qui distinguent clairement la journalisation au niveau TRACE plutôt qu'au niveau DEBUG?
  • Pourquoi ces informations doivent-elles passer par l'infrastructure des journaux?
    • Quels sont les avantages de conserver ces informations dans un journal de bord plutôt que de simplement utiliser System.out.println?
    • Pourquoi est-il préférable d'utiliser le journal pour cela plutôt qu'un débogueur?
  • Quel serait un exemple canonique de journalisation au niveau TRACE?
    • Quels sont les gains spécifiques qui ont été réalisés en se connectant au niveau TRACE au lieu de DEBUG dans l'exemple?
    • Pourquoi ces gains sont-ils importants?
    • Inverse: Quels problèmes ai-je évités en le connectant à TRACE au lieu de DEBUG?
    • Sinon, comment pourrais-je résoudre ces problèmes? Pourquoi la journalisation au niveau TRACE est-elle meilleure que ces autres solutions?
  • L'instruction de journal de niveau TRACE doit-elle être laissée dans le code de production? Pourquoi?

Mais étant donné qu'il est présent dans la plupart des cadres principaux, je suppose qu'il est utile pour quelque chose? Alors ... à quoi sert TRACE et qu'est-ce qui le distingue de DEBUG?

javalogging
96
Laurent Bourgault-Roy

Quels sont les exemples d'informations qui devraient être enregistrées avec TRACE et non avec DEBUG?

Si j'ai un algorithme qui passe par un tas d'étapes, le niveau de trace imprimera des informations sur chacune de ces étapes au niveau le plus fin. Des choses comme les entrées et sorties littérales de chaque étape.

En général, la trace inclura tous les débogages (tout comme le débogage inclut tous les avertissements et erreurs).

Quel problème spécifique puis-je résoudre en enregistrant ces informations?

Vous devez déboguer quelque chose qui génère ( façon trop de données pour se connecter en dehors d'une build spécifique lorsque vous ciblez ce particulier chose et ne se soucient pas des erreurs ou autres informations de journalisation (car le volume des informations de trace les obscurcira). Dans certains enregistreurs, vous n'activez un certain module qu'au niveau de trace uniquement.

Dans ces exemples, quelles sont les propriétés des informations enregistrées qui distinguent clairement entre la journalisation au niveau TRACE plutôt que le niveau DEBUG?

En général, la journalisation au niveau de la trace ne peut pas être activée pendant des périodes prolongées car elle dégrade considérablement les performances de l'application et/ou crée une abondance de données de journal qui ne sont pas viables en raison des contraintes de disque/bande passante.

La journalisation au niveau du débogage peut généralement être activée pendant une période plus longue sans rendre l'application inutilisable.

Pourquoi ces informations doivent-elles passer par l'infrastructure des journaux?

Ce n'est pas nécessaire. Certains frameworks ont un tracelogger séparé.

Habituellement, il se retrouve dans les journaux car les enregistreurs de trace et les enregistreurs normaux ont des besoins similaires en ce qui concerne l'écriture sur le disque/réseau, la gestion des erreurs, la rotation des journaux, etc.

Pourquoi est-il préférable d'utiliser le journal pour cela plutôt qu'un débogueur?

Parce que le débogueur peut ne pas pouvoir se connecter à la machine à problème. Vous ne savez peut-être pas assez pour savoir où définir des points d'arrêt, ou pour parcourir le code. Vous ne pourrez peut-être pas reproduire l'erreur de manière fiable dans un débogueur, utilisez donc les journaux pour la détecter "si cela se produit".

Mais ce ne sont que des noms. Comme tout autre label, ce ne sont que des noms que les gens mettent sur les choses, et cela signifie généralement des choses différentes pour différentes personnes. Et l'étiquette elle-même est moins importante que les morceaux de viande auxquels l'étiquette fait référence.

65
Telastyn

Prenez note que slf4j recommande spécifiquement de ne pas utiliser trace ( http://slf4j.org/faq.html#trace ):

En bref, bien que nous déconseillons toujours l'utilisation du niveau TRACE parce qu'il existe des alternatives ou parce que dans de nombreux cas, les demandes de journal de niveau TRACE sont inutiles, étant donné que les gens ne cessaient de le demander, nous avons décidé de nous plier à la demande populaire.

Personnellement, je m'attendrais à ce que trace trace tout tout (par exemple, même des trucs comme "la fonction entrée MyFunc avec les arguments A, B, C au temps Y") ). L'inconvénient est que non seulement c'est incroyablement bruyant, mais aussi qu'il a tendance à causer des problèmes d'espace disque; Je m'attendrais à ce qu'une telle journalisation soit désactivée pendant les opérations normales. L'avantage est que cela vous donne un niveau d'informations similaire à ce que vous obtiendriez en parcourant votre programme dans les cas où attacher un débogueur peut être moins pratique.

En général, je trouve que la trace représente généralement plus d'efforts que les autres approches.

16
Brian

Les niveaux de débogage en général sont entièrement arbitraires et peuvent varier selon les langues, les bibliothèques et les entreprises.

Cela étant dit, voici comment je les ai vus utilisés:

TRACE: utilisé pour afficher le flux de programme au niveau logique. Vous avez entré une fonction? Une instruction "si" a-t-elle choisi la branche principale ou "sinon"? C'est un candidat pour la trace. En d'autres termes, l'enregistrement de trace est généralement utilisé pour spécifier "vous êtes ici". Cela est utile dans le contexte d'autres instructions de journalisation qui peuvent consigner une erreur ou d'autres informations. La journalisation du suivi peut aider à localiser l'emplacement, dans le code, de l'erreur ou d'un autre événement enregistré à un niveau différent.

DEBUG: utilisé pour vider l'état variable, des codes d'erreur spécifiques, etc. Par exemple: un service Web peut renvoyer le code d'erreur 809214, qui peut être enregistré pendant que l'application indique à l'utilisateur "la communication a échoué". Imaginez un développeur recevant un journal du système d'un utilisateur longtemps après que l'erreur s'est produite et se demandant "pourquoi la panne s'est-elle produite?" c'est une bonne chose de se connecter au niveau du débogage. Un autre exemple pourrait être si un bogue continue de se produire en production mais est difficile à reproduire, déboguer le journal de certaines variables ou événements dans le module gênant pour aider à indiquer aux développeurs l'état du programme lorsque l'erreur se produit pour faciliter le dépannage.

Normalement, on configurerait l'application pour se connecter à un niveau donné (ou supérieur). Par exemple, la trace est souvent le niveau le plus bas: la journalisation à ce niveau enregistre tout. Le niveau de débogage omettrait la trace mais inclurait des niveaux élevés (par exemple des avertissements et des erreurs).

L'avantage de la ségrégation des niveaux de journal est de contrôler la quantité enregistrée. Pour une application complexe, la journalisation de trace peut potentiellement enregistrer une énorme quantité de données, la plupart du temps inutiles. Il est préférable de consigner uniquement les informations critiques (peut-être des informations de démarrage, puis uniquement des erreurs) sauf on essaie de déterminer comment provoquer un bogue. En outre, cela n'est généralement utile que dans un environnement de production où les débogueurs et autres outils de développement ne sont pas présents.

Il n'y a pas vraiment de limites à cela, pas de règles disant que vous devez vous connecter d'une certaine manière. Seules les conventions générales que certaines bibliothèques ou applications peuvent suivre ou non.

14
user22815

Voici ma règle d'or

error   you need        to do something
warn    you might need  to do something
info    you need        to log this in production
debug   you might need  to log this in production
trace   everything that is happening (no performance concerns)

L'hypothèse derrière cela est que l'équipe ops

  • la production est toujours définie sur les informations au niveau du journal
  • la production peut avoir un débogage au niveau du journal
  • jamais la production n'est définie sur la trace au niveau du journal

Fort de cette hypothèse, voici comment vous, en tant que développeur, pouvez utiliser les niveaux de journal ...

Objectif n ° 1) ne pas trop ralentir les performances de production

debug résout # 1. C'est vous, en tant que développeur, qui faites de votre mieux pour équilibrer les informations dont vous pourriez avoir besoin en production sans avoir trop de bruit, vous ralentissez la machine. Vous dites que "c'est une bonne idée d'enregistrer constamment ceci en production (si vous voulez)."

Objectif n ° 2) avoir des informations détaillées tout en développant

trace résout le problème n ° 2. Vous ne vous souciez absolument pas de l'impact que cela aurait sur une machine de production, mais vous avez besoin de ces informations dès maintenant lors du développement du code. Vous dites: "Je ne promets pas que c'est une bonne idée de toujours enregistrer ces informations en production."

Certes (comme d'autres l'ont dit), ces choses sont arbitraires; assurez-vous simplement que votre équipe de développement (et votre équipe d'opérations/de surveillance - car ils sont également des utilisateurs de votre journalisation) sont d'accord sur quelque chose.

10
Alexander Bird

Je pense l'excellente réponse de Telastyn peut se résumer à ma courte règle d'or:

  • DEBUG la journalisation doit pouvoir être utilisée en production (mais a tendance à être éteinte normalement)
  • TRACE la journalisation peut être telle que son utilisation en production (autre que pour une session spécifique/courte) est impossible
9
Martin Ba

Quel serait un exemple canonique de journalisation au niveau TRACE?

ENTRY/EXIT enregistre à partir d'une méthode. Ces journaux vous aident trace le déroulement du programme et ont tendance à être très utiles lorsque:

  1. Le programme plante brutalement - vous savez exactement dans quelle fonction il s'est écrasé en regardant la dernière ligne du journal

  2. Certaines fonctions escrocs échouent silencieusement en absorbant une exception

Ils garantissent un niveau TRACE séparé plutôt que d'utiliser simplement DEBUG car l'activation des journaux ENTRY/EXIT pour chaque méthode de votre base de code va générer une énorme quantité de journaux supplémentaires qui ne sont pas raisonnables toujours activé, même dans un contexte DEBUG.

3
dotbugfix