Meilleures pratiques de journalisation

J’aimerais avoir des articles sur la manière dont les gens traitent et enregistrent les applications réelles. Voici quelques questions qui pourraient vous aider à expliquer votre réponse.

Cadres

Quels frameworks utilisez-vous?

  • log4net
  • System.Diagnostics.Trace
  • System.Diagnostics.TraceSource
  • Bloc d’application de journalisation
  • Autre?

Si vous utilisez le traçage, utilisez-vous Trace.Correlation.StartLogicalOperation?

Ecrivez-vous ce code manuellement ou utilisez-vous une forme de programmation orientée aspect pour le faire? Souhaitez-vous partager un extrait de code?

Fournissez-vous une forme quelconque de granularité sur les sources de trace? Par exemple, WPF TraceSources vous permet de les configurer à différents niveaux:

  • System.Windows – parameters pour tous les fichiers WPF
  • System.Windows.Animation – remplace spécifiquement l’Animation.

Les auditeurs

Quelles sorties de journal utilisez-vous?

  • Fichiers texte
  • Fichiers XML
  • Journal des événements
  • Autre?

Si vous utilisez des fichiers, utilisez-vous des journaux de roulement ou un seul fichier? Comment rendre les journaux disponibles pour les personnes à consumr?

Regarder

Quels outils utiliser pour afficher les journaux?

  • Bloc-notes
  • Queue
  • Observateur d’événements
  • Systems Center Operations Manager / Gestionnaire des opérations Microsoft
  • Visionneuse de service WCF
  • Autre?

Si vous créez une solution ASP.NET, utilisez-vous également ASP.NET Health Monitoring? Incluez-vous la sortie de trace dans les événements du moniteur de santé? Qu’en est-il de Trace.axd?

Qu’en est-il des compteurs de performance personnalisés?


Mise à jour: Pour les extensions de System.Diagnostics, fournissant certains des écouteurs manquants que vous pourriez souhaiter, voir Essential.Diagnostics sur CodePlex ( http://essentialdiagnostics.codeplex.com/ )


Cadres

Q: Quels frameworks utilisez-vous?

A: System.Diagnostics.TraceSource, intégré à .NET 2.0.

Il fournit une journalisation puissante, flexible et à hautes performances pour les applications. Cependant, de nombreux développeurs ne sont pas conscients de ses capacités et ne les utilisent pas pleinement.

Il y a des domaines où des fonctionnalités supplémentaires sont utiles, ou parfois les fonctionnalités existent mais ne sont pas bien documentées, mais cela ne signifie pas que toute la structure de journalisation (qui est conçue pour être extensible) devrait être complètement remplacée. (NLog, log4net, Common.Logging et même EntLib Logging).

Plutôt que de modifier la façon dont vous ajoutez des instructions de journalisation à votre application et de réinventer la roue, il vous suffit d’extensionner la structure System.Diagnostics dans les endroits où vous en avez besoin.

Il me semble que les autres frameworks, même EntLib, souffrent simplement de Syndrome non inventé ici, et je pense qu’ils ont perdu du temps à réinventer les bases qui fonctionnent déjà parfaitement bien dans System.Diagnostics (comme l’écriture des instructions de journal), plutôt que de combler les quelques lacunes qui existent. En bref, ne les utilisez pas – ils ne sont pas nécessaires.

Caractéristiques que vous ne connaissiez peut-être pas:

  • L’utilisation des surcharges TraceEvent qui utilisent une chaîne de format et args peut aider les performances car les parameters sont conservés en tant que références distinctes jusqu’à ce que Filter.ShouldTrace () ait réussi. Cela signifie pas d’appels coûteux à ToSsortingng () sur les valeurs de paramètre avant que le message confirmé par le système ne soit réellement enregistré.
  • Le Trace.CorrelationManager vous permet de corréler les instructions du journal avec la même opération logique (voir ci-dessous).
  • VisualBasic.Logging.FileLogTraceListener est bon pour écrire dans les fichiers journaux et prend en charge la rotation des fichiers. Bien que dans l’espace de noms VisualBasic, il peut être aussi facilement utilisé dans un projet C # (ou un autre langage) simplement en incluant la DLL.
  • Lorsque vous utilisez EventLogTraceListener si vous appelez TraceEvent avec plusieurs arguments et avec une chaîne de format vide ou null, les arguments sont transmis directement à EventLog.WriteEntry () si vous utilisez des ressources de message localisées.
  • L’outil Visionneuse de trace de service (à partir de WCF) est utile pour afficher des graphiques de fichiers journaux corrélés aux activités (même si vous n’utilisez pas WCF). Cela peut vraiment aider à déboguer des problèmes complexes impliquant plusieurs threads / activités.
  • Évitez la surcharge en effaçant tous les écouteurs (ou en supprimant Default); sinon, Default transmettra tout au système de trace (et subira toutes les surcharges ToSsortingng ()).

Domaines que vous voudrez peut-être envisager d’étendre (si nécessaire):

  • Écouteur de trace de firebase database
  • Écouteur de trace de console coloré
  • MSMQ / Email / WMI trace écouteurs (si nécessaire)
  • Implémenter un FileSystemWatcher pour appeler Trace.Refresh pour les modifications de configuration dynamics

Autres recommandations:

Utilisez les identifiants d’événement structuré et conservez une liste de références (par exemple, documentez-les dans un enum).

Avoir des identifiants uniques pour chaque événement (significatif) de votre système est très utile pour la corrélation et la recherche de problèmes spécifiques. Il est facile de remonter au code spécifique qui consigne / utilise les identifiants d’événement, et facilite la fourniture de conseils pour les erreurs courantes. Par exemple, l’erreur 5178 signifie que votre chaîne de connexion à la firebase database est incorrecte, etc.

Les identifiants d’événement doivent suivre une sorte de structure (similaire à la théorie des codes de réponse utilisée dans le courrier électronique et HTTP), ce qui vous permet de les traiter par catégorie sans connaître les codes spécifiques.

Par exemple, le premier chiffre peut détailler la classe générale: 1xxx peut être utilisé pour les opérations de démarrage, 2xxx pour le comportement normal, 3xxx pour le traçage des activités, 4xxx pour les avertissements, 5xxx pour les opérations d’arrêt, 9xxx pour les erreurs, etc.

Le deuxième chiffre peut détailler la zone, par exemple 21xx pour les informations de firebase database (41xx pour les avertissements de firebase database, 51xx pour les erreurs de firebase database), 22xx pour le mode de calcul (42xx pour les avertissements de calcul, etc.), 23xx pour un autre module.

Les identifiants d’événements assignés et structurés vous permettent également de les utiliser dans des filtres.

Q: Si vous utilisez le traçage, utilisez-vous Trace.Correlation.StartLogicalOperation?

A: Trace.CorrelationManager est très utile pour corréler les instructions de journal dans n’importe quel environnement multi-thread (ce qui est pratiquement le cas aujourd’hui).

Vous devez au moins définir le ActivityId une fois pour chaque opération logique afin de corréler.

Start / Stop et LogicalOperationStack peuvent ensuite être utilisés pour un contexte basé sur une stack simple. Pour les contextes plus complexes (par exemple, les opérations asynchrones), l’utilisation de TraceTransfer dans le nouvel ActivityId (avant de le modifier) ​​permet la corrélation.

L’outil Visionneuse de trace de service peut être utile pour afficher des graphiques d’activité (même si vous n’utilisez pas WCF).

Q: Ecrivez-vous ce code manuellement ou utilisez-vous une forme de programmation orientée aspect pour le faire? Souhaitez-vous partager un extrait de code?

R: Vous souhaiterez peut-être créer une classe d’étendue, par exemple LogicalOperationScope, qui (a) configure le contexte lors de sa création et (b) réinitialise le contexte lors de sa suppression.

Cela vous permet d’écrire du code tel que le suivant pour envelopper automatiquement les opérations:

using( LogicalOperationScope operation = new LogicalOperationScope("Operation") ) { // .. do work here } 

Lors de la création, l’étendue peut d’abord définir ActivityId si nécessaire, appeler StartLogicalOperation, puis consigner un message TraceEventType.Start. Sur Dispose, il pourrait enregistrer un message Stop, puis appeler StopLogicalOperation.

Q: Fournissez-vous une forme de granularité aux sources de trace? Par exemple, WPF TraceSources vous permet de les configurer à différents niveaux.

R: Oui, plusieurs sources de trace sont utiles / importantes à mesure que les systèmes deviennent plus gros.

Bien que vous souhaitiez probablement consigner systématiquement tous les avertissements & ci-dessus, ou toutes les informations et messages ci-dessus, pour un système de taille raisonnable, le volume de suivi d’activité (démarrage, arrêt, etc.)

Plutôt que d’avoir un seul commutateur qui allume ou éteint tout cela, il est utile de pouvoir activer ces informations pour une section de votre système à la fois.

De cette façon, vous pouvez localiser les problèmes importants liés à la journalisation habituelle (tous les avertissements, erreurs, etc.), puis effectuer un zoom avant sur les sections souhaitées et les définir sur Suivi de l’activité ou même sur Débogage.

Le nombre de sources de trace dont vous avez besoin dépend de votre application. Par exemple, vous pouvez choisir une source de trace par assemblage ou par section principale de votre application.

Si vous avez besoin d’un contrôle encore plus précis, ajoutez des commutateurs booléens individuels pour activer / désactiver le traçage spécifique à haut volume, par exemple les vidages de messages bruts. (Ou une source de trace distincte pourrait être utilisée, similaire à WCF / WPF).

Vous pouvez également envisager des sources de trace distinctes pour le suivi d’activité par rapport à la consignation générale (autre), car cela peut faciliter la configuration des filtres exactement comme vous le souhaitez.

Notez que les messages peuvent toujours être corrélés via ActivityId, même si des sources différentes sont utilisées, utilisez-en autant que nécessaire.


Les auditeurs

Q: Quelles sorties de journal utilisez-vous?

Cela peut dépendre du type d’application que vous écrivez et de ce qui est consigné. En général, des choses différentes se produisent à des endroits différents (c.-à-d. Des sorties multiples).

Je classe généralement les résultats en trois groupes:

(1) Événements – Journal des événements Windows (et fichiers de trace)

Par exemple, si vous écrivez un serveur / service, la meilleure pratique sous Windows consiste à utiliser le journal des événements Windows (vous n’avez pas d’interface utilisateur à signaler).

Dans ce cas, tous les événements Fatal, Error, Warning et (niveau de service) doivent être enregistrés dans le journal des événements Windows. Le niveau d’information doit être réservé à ces types d’événements de haut niveau, ceux que vous souhaitez consulter dans le journal des événements, par exemple “Service démarré”, “Service arrêté”, “Connecté à Xyz” et peut-être même “Programmé” , “Utilisateur connecté”, etc.

Dans certains cas, vous souhaiterez peut-être que l’écriture dans le journal des événements fasse partie intégrante de votre application et non via le système de trace (c’est-à-dire que vous écrivez directement les entrées du journal des événements). Cela signifie qu’il ne peut pas être désactivé accidentellement. (Notez que vous souhaitez également noter le même événement dans votre système de trace pour pouvoir établir une corrélation).

En revanche, une application graphique Windows les signale généralement à l’utilisateur (bien qu’ils puissent également se connecter au journal des événements Windows).

Les événements peuvent également comporter des compteurs de performance (par exemple, nombre d’erreurs / s) et il peut être important de coordonner toute écriture directe dans le journal des événements, les compteurs de performance, l’écriture dans le système de suivi et la notification à l’utilisateur. le même temps.

Si un utilisateur voit un message d’erreur à un moment donné, vous devriez pouvoir trouver le même message d’erreur dans le journal des événements Windows, puis le même événement avec le même horodatage dans le journal de suivi (avec d’autres détails de trace).

(2) Activités – Fichiers journaux d’application ou table de firebase database (et fichiers de trace)

Il s’agit de l’activité régulière d’un système, par exemple la page Web servie, le commerce boursier déposé, l’ordre pris, le calcul effectué, etc.

Le suivi d’activité (démarrage, arrêt, etc.) est utile ici (à la granularité appropriée).

En outre, il est très courant d’utiliser un journal d’application spécifique (parfois appelé journal d’audit). Il s’agit généralement d’une table de firebase database ou d’un fichier journal d’application et contient des données structurées (un ensemble de champs).

Les choses peuvent devenir un peu floues en fonction de votre application. Un bon exemple pourrait être un serveur Web qui écrit chaque demande dans un journal Web; Des exemples similaires pourraient être un système de messagerie ou un système de calcul dans lequel chaque opération est consignée avec des détails spécifiques à l’application.

Un exemple moins bon est celui des opérations boursières ou du système de commande de vente. Dans ces systèmes, vous êtes probablement déjà en train de consigner l’activité, car ils ont une valeur commerciale importante, mais le principe de les corréler à d’autres actions rest important.

Outre les journaux d’applications personnalisés, les activités comportent souvent des compteurs de performance, par exemple le nombre de transactions par seconde.

En général, vous devez coordonner la journalisation des activités sur différents systèmes, c.-à-d. Écrire dans votre journal des applications en même temps que vous augmentez votre compteur de performances et vous connectez à votre système de trace. Si vous faites tout en même temps (ou l’un après l’autre dans le code), les problèmes de débogage sont plus faciles (que s’ils se produisent tous à des moments / lieux différents dans le code).

(3) Trace de débogage – Fichier texte, ou peut-être XML ou firebase database.

Ce sont des informations au niveau Verbose et inférieur (par exemple, commutateurs booléens personnalisés pour activer / désactiver les vidages de données brutes). Cela fournit le courage ou les détails de ce que fait un système au niveau de la sous-activité.

C’est le niveau que vous souhaitez pouvoir activer / désactiver pour des sections individuelles de votre application (d’où les sources multiples). Vous ne voulez pas que ces choses encombrent le journal des événements Windows. Parfois, une firebase database est utilisée, mais il est plus probable que les fichiers journaux soient purgés après un certain temps.

Une grande différence entre ces informations et un fichier journal d’application est qu’elles ne sont pas structurées. Alors qu’un journal d’application peut avoir des champs pour To, From, Amount, etc., les traces de débogage verbales peuvent être celles d’un programmeur, par exemple “vérification des valeurs X = {valeur}, Y = faux” Faites-le, réessayez “.

Une pratique importante consiste à vérifier que les éléments que vous avez insérés dans les fichiers journaux des applications ou dans le journal des événements Windows sont également consignés dans le système de trace avec les mêmes détails (par exemple, horodatage). Cela vous permet ensuite de corréler les différents journaux lors des investigations.

Si vous prévoyez d’utiliser une visionneuse de journal particulière parce que vous avez une corrélation complexe, par exemple le visualiseur de trace de service, vous devez utiliser un format approprié, par exemple XML. Sinon, un simple fichier texte est généralement assez bon – aux niveaux inférieurs, les informations ne sont pas structurées, vous pouvez donc trouver des décharges de tableaux, des vidages de stack, etc. va bien.

Q: Si vous utilisez des fichiers, utilisez-vous des journaux de roulement ou un seul fichier? Comment rendre les journaux disponibles pour les personnes à consumr?

R: Pour les fichiers, vous voulez généralement des fichiers journaux évolutifs d’un sharepoint vue de la gestion (avec System.Diagnostics, utilisez simplement VisualBasic.Logging.FileLogTraceListener).

La disponibilité dépend à nouveau du système. Si vous ne parlez que de fichiers, pour un serveur / service, vous pouvez accéder aux fichiers en continu si nécessaire. (Le journal des événements Windows ou les journaux d’application de la firebase database auraient leurs propres mécanismes d’access).

Si vous n’avez pas facilement access au système de fichiers, le traçage de débogage dans une firebase database peut être plus facile. [ie implémenter une firebase database TraceListener].

Une solution intéressante que j’ai vue pour une application Windows GUI était qu’elle enregistrait des informations de traçage très détaillées sur un «enregistreur de vol» en cours d’exécution, puis qu’elle les supprimait si elle n’avait aucun problème.

Si, cependant, il a planté ou rencontré un problème, le fichier n’a pas été supprimé. Soit il détecte l’erreur, soit la prochaine fois qu’il sera exécuté, il remarquera le fichier, puis il pourra agir, par exemple le compresser (par exemple, 7zip) et l’envoyer par e-mail ou le rendre disponible.

De nos jours, de nombreux systèmes intègrent le signalement automatique des défaillances sur un serveur central (après vérification auprès des utilisateurs, par exemple pour des raisons de confidentialité).


Regarder

Q: Quels outils utiliser pour afficher les journaux?

R: Si vous avez plusieurs journaux pour différentes raisons, vous utiliserez plusieurs lecteurs.

Bloc-notes / vi / Notepad ++ ou tout autre éditeur de texte est la base des journaux en texte brut.

Si vous avez des opérations complexes, par exemple des activités avec des transferts, vous utiliserez évidemment un outil spécialisé comme le visualiseur de trace de service. (Mais si vous n’en avez pas besoin, alors un éditeur de texte est plus facile).

Comme je connecte généralement des informations de haut niveau au journal des événements Windows, il fournit un moyen rapide d’obtenir une vue d’ensemble, de manière structurée (recherchez les icons d’erreur / avertissement). Vous ne devez commencer à chercher dans les fichiers texte que si le journal ne contient pas suffisamment de fichiers, même si au moins le journal vous donne un sharepoint départ. (À ce stade, il est utile de vous assurer que les entrées de vos journaux sont bien coordonnées).

En général, le journal des événements Windows met également ces événements significatifs à la disposition des outils de surveillance tels que MOM ou OpenView.

Autres —

Si vous vous connectez à une firebase database, il peut être facile de filtrer et de sortinger les informations (par exemple, zoomer sur un identifiant d’activité particulier (avec les fichiers texte, vous pouvez utiliser Grep / PowerShell ou similaire).

MS Excel (ou un autre tableur). Cela peut être utile pour parsingr des informations structurées ou semi-structurées si vous pouvez l’importer avec les bons délimiteurs de sorte que différentes valeurs soient stockées dans des colonnes différentes.

Lors de l’exécution d’un service de débogage / test, je l’héberge généralement dans une application console pour plus de simplicité. Je trouve un enregistreur de console coloré utile (par exemple, rouge pour les erreurs, jaune pour les avertissements, etc.). Vous devez implémenter un écouteur de trace personnalisé.

Notez que le framework n’inclut pas un consignateur de console coloré ou un enregistreur de firebase database, donc, pour le moment, vous devrez les écrire si vous en avez besoin (ce n’est pas trop difficile).

Cela m’ennuie vraiment que plusieurs frameworks (log4net, EntLib, etc.) aient perdu du temps à réinventer la roue et à réimplémenter la journalisation, le filtrage et la connexion de base aux fichiers texte, au journal des événements Windows et aux fichiers XML. manière différente (les instructions de journal sont différentes dans chacun); chacun a ensuite implémenté sa propre version, par exemple, d’un enregistreur de firebase database, alors que la plupart existaient déjà et qu’il suffisait de quelques écouteurs de trace pour System.Diagnostics. Parlez d’un gros gaspillage d’effort en double.

Q: Si vous créez une solution ASP.NET, utilisez-vous également ASP.NET Health Monitoring? Incluez-vous la sortie de trace dans les événements du moniteur de santé? Qu’en est-il de Trace.axd?

Ces choses peuvent être activées / désactivées si nécessaire. Je trouve Trace.axd très utile pour déboguer la façon dont un serveur répond à certaines choses, mais il n’est généralement pas utile dans un environnement très sollicité ou pour un suivi à long terme.

Q: Qu’en est-il des compteurs de performance personnalisés?

Pour une application professionnelle, en particulier un serveur / service, je m’attends à le voir entièrement instrumenté avec les compteurs de l’Analyseur de performances et la connexion au journal des événements Windows. Ce sont les outils standard de Windows et doivent être utilisés.

Vous devez vous assurer d’inclure les programmes d’installation pour les compteurs de performances et les journaux d’événements que vous utilisez; ceux-ci doivent être créés au moment de l’installation (lors de l’installation en tant qu’administrateur). Lorsque votre application s’exécute normalement, elle ne devrait pas avoir besoin de privilèges d’administration (et ne pourra donc pas créer de journaux manquants).

C’est une bonne raison pour vous entraîner à développer en tant que non-administrateur (ayez un compte administrateur séparé pour quand vous devez installer des services, etc.). Si vous écrivez dans le journal des événements, .NET crée automatiquement un journal manquant la première fois que vous y écrivez; Si vous développez en tant que non-administrateur, vous attraperez ceci tôt et éviterez une mauvaise surprise lorsqu’un client installe votre système et ne peut pas l’utiliser parce qu’il n’est pas exécuté en tant qu’administrateur.

Je dois rejoindre le choeur en recommandant log4net, dans mon cas, du sharepoint vue de la flexibilité de la plate-forme (bureau .Net / Compact Framework, 32/64 bits).

Cependant, l’enrouler dans une API de marque privée est un anti-modèle majeur . log4net.ILogger est la contrepartie .Net de l’ API wrapper Commons Logging , donc le couplage est déjà réduit pour vous, et comme il s’agit également d’une bibliothèque Apache, ce n’est généralement pas un problème car vous n’abandonnez aucun contrôle: fork si vous devez.

La plupart des librairies de wrappers que j’ai vues commettent également une ou plusieurs litanies de fautes:

  1. Utilisation d’un enregistreur singleton global (ou équivalent d’un point d’entrée statique) qui perd la résolution fine du modèle logger par classe recommandé pour aucun autre gain de sélectivité.
  2. Ne pas exposer l’argument optionnel Exception , ce qui entraîne plusieurs problèmes:
    • Cela rend la politique de journalisation des exceptions encore plus difficile à gérer, donc rien ne se fait de manière cohérente avec les exceptions.
    • Même avec une stratégie cohérente, la mise en forme de l’exception dans une chaîne entraîne une perte prématurée des données. J’ai écrit un décorateur ILayout personnalisé qui effectue une ILayout détaillée d’une exception pour déterminer la chaîne d’événements.
  3. Vous ne parvenez pas à exposer les propriétés Is Level Enabled , qui élimine la possibilité d’ignorer le code de formatage lorsque des zones ou des niveaux de journalisation sont désactivés.

Je ne développe pas souvent sur asp.net, mais en ce qui concerne les enregistreurs, je pense que beaucoup de meilleures pratiques sont universelles. Voici quelques-unes de mes reflections sur la journalisation que j’ai apsockets au fil des ans:

Cadres

  • Utilisez un framework d’abstraction de logger – comme slf4j (ou lancez votre propre), afin de découpler l’implémentation de l’enregistreur de votre API. J’ai vu un certain nombre de frameworks de logger aller et venir et vous feriez mieux d’en adopter un nouveau sans trop de tracas.
  • Essayez de trouver un framework prenant en charge une variété de formats de sortie.
  • Essayez de trouver un framework qui supporte les plugins / filtres personnalisés.
  • Utilisez une structure pouvant être configurée par des fichiers externes, afin que vos clients / consommateurs puissent facilement modifier la sortie du journal afin de pouvoir la lire facilement par les applications de gestion de journaux commerciales.
  • Veillez à ne pas aller trop loin dans les niveaux de consignation personnalisés, sinon vous risquez de ne pas pouvoir passer à différentes structures de consignation.

Logger Output

  • Essayez d’éviter les journaux de style XML / RSS pour la journalisation qui pourrait rencontrer des pannes catastrophiques. Ceci est important car si l’interrupteur d’alimentation est éteint sans que votre enregistreur n’écrive la fermeture, votre journal est cassé.
  • Journal des discussions. Sinon, il peut être très difficile de suivre le déroulement de votre programme.
  • Si vous devez internationaliser vos journaux, vous pouvez souhaiter qu’un développeur se connecte uniquement en anglais (ou la langue de votre choix).
  • Parfois, avoir la possibilité d’insérer des instructions de consignation dans des requêtes SQL peut être une bouée de sauvetage dans les situations de débogage. Tel que:
  - Classe invoquante: com.foocorp.foopackage.FooClass: 9021
     SELECT * FROM foo; 
  • Vous voulez une journalisation au niveau de la classe. Vous ne voulez normalement pas non plus les instances statiques des enregistreurs – cela ne vaut pas la micro-optimisation.
  • Le marquage et la catégorisation des exceptions consignées sont parfois utiles car toutes les exceptions ne sont pas égales. Il est donc utile de connaître un sous-ensemble d’exceptions importantes, si vous avez un moniteur de journal qui doit envoyer des notifications sur les états critiques.
  • Les filtres de duplication sauveront votre vue et votre disque dur. Voulez-vous vraiment voir la même déclaration de journalisation répétée 10 ^ 10000000 fois? Ne serait-il pas préférable d’avoir un message comme: This is my logging statement - Repeated 100 times

Voir aussi cette question de moi .

Je ne suis pas qualifié pour commenter la connexion à .Net, puisque mon pain et mon beurre sont Java, mais que nous avons effectué une migration au cours des 8 dernières années, vous pouvez trouver une analogie utile avec votre question.

Nous avons commencé avec un enregistreur Singleton qui était utilisé par chaque thread dans la machine virtuelle Java et définissait le niveau de journalisation pour l’ensemble du processus. Cela a abouti à des journaux énormes si nous devions déboguer même une partie très spécifique du système, alors la première leçon consiste à segmenter votre journalisation.

Notre incarnation actuelle de l’enregistreur permet plusieurs instances dont l’une est définie par défaut. Nous pouvons instancier un nombre illimité d’enregistreurs enfants ayant des niveaux de journalisation différents, mais la facette la plus utile de cette architecture est la possibilité de créer des enregistreurs pour des packages et des classes individuels en modifiant simplement les propriétés de journalisation. La leçon numéro deux consiste à créer un système flexible qui permette de modifier son comportement sans modifier le code.

Nous utilisons la bibliothèque Apache commons-logging entourant Log4J.

J’espère que cela t’aides!

* Modifier *

Après avoir lu le post de Jeffrey Hantin ci-dessous, j’ai réalisé que j’aurais dû noter ce que notre wrapper de journalisation interne est réellement devenu. Il s’agit désormais essentiellement d’une fabrique et est ssortingctement utilisé pour obtenir un enregistreur fonctionnel à l’aide du fichier de propriétés correct (qui, pour des raisons héritées, n’a pas été déplacé vers la position par défaut). Étant donné que vous pouvez spécifier le fichier de configuration de journalisation sur la ligne de commande maintenant, je pense qu’il deviendra encore plus léger et si vous lancez une nouvelle application, je serais tout à fait d’accord avec votre déclaration.

Nous utilisons Log4Net au travail en tant que fournisseur de journalisation, avec un wrapper singleton pour l’instance de journal (bien que le singleton soit en cours de révision, se demandant s’ils sont une bonne idée ou non).

Nous l’avons choisi pour les raisons suivantes:

  • Configuration / reconfiguration simple sur différents environnements
  • Bon nombre d’appendeurs pré-construits
  • L’un des CMS que nous utilisons l’avait déjà intégré
  • Bon nombre de niveaux de journalisation et de configurations autour d’eux

Je devrais mentionner, cela parle d’un sharepoint vue de développement ASP.NET

Je peux voir certains avantages à utiliser le Trace qui se trouve dans le framework .NET mais je ne suis pas entièrement vendu, principalement parce que les composants avec lesquels je travaille ne font pas vraiment d’appels de trace. La seule chose que j’utilise fréquemment est System.Net.Mail de ce que je peux dire.

Donc, nous avons une bibliothèque qui encapsule log4net et dans notre code, nous avons juste besoin de choses comme ceci:

 Logger.Instance.Warn("Something to warn about"); Logger.Instance.Fatal("Something went bad!", new Exception()); try { var i = int.Parse("Hello World"); } catch(FormatException, ex) { Logger.Instance.Error(ex); } 

Dans les méthodes, nous vérifions si le niveau de journalisation est activé, donc vous n’avez pas d’appels redondants à l’API log4net (donc, si Debug n’est pas activé, les instructions de débogage sont ignorées), mais quand j’ai du temps Je vais le mettre à jour pour les exposer afin que vous puissiez faire les vérifications vous-même. Cela évitera que des évaluations soient entresockets alors qu’elles ne le devraient pas, par exemple:

 Logger.Instance.Debug(ssortingng.Format("Something to debug at {0}", DateTime.Now); 

Cela deviendra:

 if(Logger.DebugEnabled) Logger.Instance.Debug(ssortingng.Format("Something to debug at {0}", DateTime.Now); 

(Économiser un peu de temps d’expiration)

Par défaut, nous nous connectons à deux endroits:

  1. Système de fichiers du site Web (dans une extension de fichier non servi)
  2. Envoi d’email pour Error & Fatal

Les fichiers se font en roulement de chaque jour ou 10 Mo (IIRC). Nous n’utilisons pas le EventLog car il peut nécessiter une sécurité supérieure à celle que nous souhaitons souvent donner à un site.

Je trouve que Notepad fonctionne très bien pour lire les journaux.

Quels frameworks utilisez-vous?

Nous utilisons un mélange du bloc d’application de journalisation et d’un assistant de journalisation personnalisé qui fonctionne autour des bits du framework .Net. Le LAB est configuré pour générer des fichiers journaux assez étendus, y compris des fichiers de trace généraux distincts pour les entrées / sorties de méthodes de service et des fichiers d’erreur spécifiques pour les problèmes inattendus. La configuration inclut la date / heure, le thread, le pId etc. pour l’assistance au débogage, ainsi que le détail complet des exceptions et la stack (dans le cas d’une exception inattendue).

L’assistant de journalisation personnalisé utilise la fonction Trace.Correlation et est particulièrement utile dans le contexte de la journalisation dans WF. Par exemple, nous avons une machine d’état qui appelle une série de stream de travail séquentiels. A chacune de ces activités d’invocation, nous enregistrons le début (en utilisant StartLogicalOperation) et à la fin, nous arrêtons l’opération logique avec un gestionnaire d’événement de retour gérérique.

Cela s’est avéré utile à quelques resockets lors de la tentative de débogage des défaillances dans des séquences métier complexes, car cela nous permet de déterminer plus rapidement les décisions de twig If / Else, en fonction de la séquence d’exécution de l’activité.

Quelles sorties de journal utilisez-vous?

Nous utilisons des fichiers texte et des fichiers XML. Les fichiers texte sont configurés via le bloc d’application, mais nous avons également des sorties XML à partir de notre service WF. Cela nous permet de capturer les événements d’exécution (persistance, etc.) ainsi que les exceptions de type métier génériques. Les fichiers texte sont des journaux déroulants par jour et par taille (je pense que la taille totale de 1 Mo est un sharepoint basculement).

Quels outils utiliser pour afficher les journaux?

Nous utilisons Notepad et WCF Service Trace Viewer selon le groupe de résultats que nous examinons. Le service de suivi de trace du service WCF est vraiment très pratique si vous avez correctement configuré votre sortie et que vous pouvez simplifier la lecture de la sortie. Cela dit, si je sais à peu près où l’erreur est de toute façon – il suffit également de lire un fichier texte bien annoté.

Les journaux sont envoyés dans un répertoire unique qui est ensuite divisé en sous-répertoires basés sur le service source. Le répertoire racine est exposé via un site Web dont l’access est contrôlé par un groupe d’utilisateurs de support. Cela nous permet de consulter les journaux de production sans avoir à introduire de requêtes et à passer par de longues procédures administratives pour les données de production.

En tant qu’auteurs de l’outil, nous utilisons bien sûr SmartInspect pour la journalisation et le traçage des applications .NET. Nous utilisons généralement le protocole de canal nommé pour la journalisation en direct et les fichiers journaux binarys (cryptés) pour les journaux des utilisateurs finaux. Nous utilisons la console SmartInspect comme visualiseur et outil de surveillance.

Il existe en fait un grand nombre de frameworks et d’outils de journalisation pour .NET. Il y a un aperçu et une comparaison des différents outils sur DotNetLogging.com .

Il y a beaucoup de bonnes recommandations dans les réponses.

Une bonne pratique générale consiste à déterminer qui lit le journal. Dans mon cas, ce sera un administrateur sur le site du client. Donc, je consigne les messages qui leur donnent quelque chose sur lequel ils peuvent agir. Par exemple, “Impossible d’initialiser l’application. Cela est généralement dû à ……”

Nous utilisons log4net sur nos applications Web.

La possibilité de personnaliser la journalisation au moment de l’exécution en modifiant le fichier de configuration XML est très pratique lorsqu’une application ne fonctionne pas correctement au moment de l’exécution et que vous avez besoin de plus d’informations.

Il vous permet également de cibler des classes ou des atsortingbuts spécifiques pour vous connecter. C’est très pratique lorsque vous avez une idée de l’erreur. Un exemple classique est NHibernate où vous voulez voir uniquement le SQL qui va à la firebase database.

Modifier:

Nous écrivons tous les événements dans une firebase database et le système de trace. Le journal des événements que nous utilisons pour les erreurs ou les exceptions. Nous enregistrons la plupart des événements dans une firebase database afin que nous puissions créer des rapports personnalisés et laisser les utilisateurs consulter le journal s’ils le souhaitent directement depuis l’application.

En ce qui concerne la journalisation orientée aspect, j’ai été recommandé PostSharp sur une autre question SO –

Enregistrement orienté aspect avec Unity \ T4 \ autre chose

Le lien fourni dans la réponse mérite d’être visité si vous évaluez les frameworks de journalisation.