Tracing versus Logging et comment log4net s’intègre-t-il?

Je me demande quelle est la différence entre la journalisation et le traçage.

La différence est-elle que le traçage est un journal plus détaillé donnant aux développeurs un outil pour déboguer les applications à l’exécution?

J’ai expérimenté avec log4net et fait de la journalisation. Maintenant, je me demande si je devrais aussi faire du traçage et si je pouvais / devrais utiliser log4net à cette fin. Dois-je effectuer un suivi avec log4net et existe-t-il un niveau de trace pour les enregistreurs log4net? Dois-je utiliser un niveau de journalisation différent à des fins de débogage et de traçage ou est-il correct d’utiliser le même? Pouvez-vous donner un exemple simple sur la façon dont je ferais la journalisation et la traçabilité pour une méthode simple?

Edit: Malgré quelques réponses utiles ci-dessous, je ne suis toujours pas sûr de savoir comment je devrais faire le suivi par rapport à la journalisation.

J’ai la méthode suivante dans ma couche Business et je souhaite y append la journalisation / le traçage. Je me demande comment le faire efficacement. La méthode suivante est-elle acceptable en termes de journalisation / traçage? Les messages de journal doivent-ils être de type Info au lieu de Debug? Les messages de débogage que je consulte sont-ils considérés comme trace? Comment le changeriez-vous?

IEnumerable GetCars() { try { logger.Debug("Getting cars"); IEnumerable cars = CarAccessor.GetCars().ConvertAll(DataAccessToBusinessConverter); logger.Debug("Got total of " + cars.Count + " cars"); } catch (Exception e) { logger.Error("Error when getting cars", e); throw new Exception("Unexpected error when getting cars"); } } 

La journalisation est le terme générique pour enregistrer des informations – le traçage est la forme spécifique de journalisation utilisée pour déboguer.

Dans .NET, les objects System.Diagnostics.Trace et System.Diagnostics.Debug permettent une connexion simple à un certain nombre de “programmes d’écoute d’événement” que vous pouvez configurer dans app.config. Vous pouvez également utiliser TraceSwitches pour configurer et filtrer (entre les erreurs et les niveaux d’informations, par exemple).

 private void TestMethod(ssortingng x) { if(x.Length> 10) { Trace.Write("Ssortingng was " + x.Length); throw new ArgumentException("Ssortingng too long"); } } 

Dans ASP.NET, il existe une version spéciale de Trace (System.Web.TraceContext) qui écrit au bas de la page ASP ou Trace.axd. Dans ASP.NET 2+, il existe également une structure de journalisation plus complète appelée surveillance de la santé.

Log4Net est un moyen de traçage ou de journalisation plus riche et plus flexible que Trace intégré ou même ASP Health Monitoring. Comme Diagnostics.Trace, vous configurez des écouteurs d’événement (“appenders”) dans config. Pour un traçage simple, l’utilisation est simple comme la trace intégrée. La décision d’utiliser Log4Net est de savoir si vous avez des exigences plus complexes.

 private void TestMethod(ssortingng x) { Log.Info("Ssortingng length is " + x.Length); if(x.Length> 10) { Log.Error("Ssortingng was " + x.Length); throw new ArgumentException("Ssortingng too long"); } } 

OMI …

La journalisation ne doit pas être conçue pour le débogage de développement (mais elle est inévitablement utilisée de cette façon)
La journalisation devrait être conçue pour la surveillance opérationnelle et le dépannage – c’est sa raison d’être.

Le traçage doit être conçu pour le débogage du développement et le réglage des performances. Si disponible sur le terrain, il peut être utilisé pour le dépannage opérationnel de bas niveau, mais ce n’est pas son objective principal

Compte tenu de cela, les approches les plus réussies que j’ai vues (et conçues / mises en œuvre) par le passé ne combinent pas les deux. Mieux vaut séparer les deux outils, chacun faisant un travail aussi bien que possible.

log4net est bien adapté pour les deux. Nous distinguons la journalisation utile pour les diagnostics après publication et le «suivi» à des fins de développement en utilisant le niveau de journalisation DEBUG. Plus précisément, les développeurs enregistrent leur sortie de traçage (ce qui n’intéresse que le développement) en utilisant Debug() . Notre configuration de développement définit le niveau sur DEBUG:

   ...  

Avant la sortie du produit, le niveau est changé en “INFO”:

  

Cela supprime toute sortie DEBUG de la journalisation de la version mais conserve INFO / WARN / ERROR.

Il existe d’autres outils log4net, tels que les filtres, la journalisation hiérarchique (par espace de noms), les cibles multiples, etc. Nous avons trouvé la méthode simple ci-dessus très efficace.

La journalisation n’est pas une trace . Ces deux bibliothèques devraient être différentes et présenter des caractéristiques de performance différentes. En fait, j’ai écrit une bibliothèque de suivi par moi-même avec la propriété unique de pouvoir tracer automatiquement l’exception lorsque la méthode avec le suivi activé est laissée avec une exception. En outre, il est possible de résoudre de manière élégante le problème pour déclencher des exceptions dans des endroits spécifiques de votre code.

Je dirais oui. La journalisation est le seul moyen de déterminer ce qui s’est passé: si un client appelle et dit que quelque chose ne s’est pas passé comme prévu, tout ce que vous pouvez faire sans journal est de hausser les épaules et d’essayer de reproduire l’erreur. Parfois, cela est impossible (en fonction de la complexité du logiciel et de la fiabilité des données clients).

Il y a aussi la question de la journalisation pour l’audit, un fichier journal peut être écrit contenant des informations sur ce que fait l’utilisateur – vous pouvez donc l’utiliser pour limiter les possibilités de déboguer un problème, ou même pour vérifier les revendications de l’utilisateur obtenir un rapport indiquant que le système est cassé, xyz ne s’est pas produit, vous pouvez regarder dans les journaux pour découvrir que l’opérateur n’a pas réussi à démarrer le processus ou n’a pas cliqué sur la bonne option pour le faire fonctionner

Ensuite, il y a la journalisation pour les rapports, ce que la plupart des gens pensent que la journalisation est pour.

Si vous pouvez personnaliser la sortie du journal, mettez tout dans les journaux et réduisez ou augmentez la quantité de données écrites. Si vous pouvez changer le niveau de sortie dynamicment, alors c’est parfait.

Vous pouvez utiliser n’importe quel moyen d’écrire des journaux, sous réserve de problèmes de performances. Je trouve que l’ajout d’un fichier texte est le meilleur, le plus portable, le plus facile à consulter et, ce qui est très important, le plus facile à récupérer lorsque vous en avez besoin.

journalisation! = débogage

Parfois, la conservation des fichiers journaux est nécessaire pour résoudre les problèmes avec le client, ils prouvent ce qui s’est passé du côté du serveur.

En outre, considérez quelles informations sont enregistrées ou tracées. Cela est particulièrement vrai pour les informations sensibles.

Par exemple, bien qu’il soit généralement acceptable de consigner une erreur indiquant

“L’utilisateur ‘X’ a tenté d’accéder mais a été rejeté à cause d’un mot de passe erroné”,

il n’est pas correct de consigner une erreur indiquant

“L’utilisateur ‘X’ a tenté d’accéder mais a été rejeté car le mot de passe ‘secret’ n’est pas correct.”

Il pourrait être acceptable d’écrire de telles informations sensibles dans un fichier de trace (et avertir le client / utilisateur à ce sujet par «certains moyens» avant de lui demander d’activer le suivi pour un dépannage étendu en production). Cependant, pour la journalisation, j’ai toujours comme politique que ces informations sensibles ne soient jamais écrites (c.-à-d. Que les niveaux INFO et supérieurs de log4net parlent).

Cela doit être appliqué et vérifié par des revues de code, bien sûr.