Plusieurs méthodes de gestion des journaux sous .Net
Log sont un élément indispensable de l'application. Il peut non seulement enregistrer l'état d'exécution de l'application, mais également enregistrer certains BUG pour faciliter la mise à jour et la modification de l'application.
Il existe plusieurs façons de gérer les journaux dans .Net.
1. Journal de base de données.
2. Journal de texte.
3. Journal des événements système.
Tout d’abord, il est simple et pratique à utiliser pour les journaux de base de données. Je n'en parlerai pas trop ici. Je pense que quiconque a écrit des projets liés aux données utilisera les données pour enregistrer certains journaux. Cependant, le seul inconvénient est que vous devez d’abord vous assurer que le lien de votre base de données est correct.
Cependant, cette garantie n'est pas inévitable, je vais donc discuter ici des deux autres situations, les journaux de texte et les journaux d'événements système.
Journal texte :
C'est simple à utiliser et facile à visualiser. L'inconvénient est qu'il n'est pas pratique de créer un grand nombre de journaux et qu'il n'est pas pratique de visualiser et d'analyser le contenu du journal. Cependant, il peut toujours être utilisé dans certains endroits où la journalisation dans la base de données n'est pas adaptée. Par exemple, la sortie de certains messages de test, une petite quantité de journaux de certains composants indépendants, etc.
Dans des circonstances normales, afin de faciliter la gestion, les fichiers journaux sont classés en unités de jours. De cette façon, les fichiers peuvent être facilement gérés. Par exemple : vous pouvez savoir quand ce journal se trouve grâce à votre nom de fichier, puis vous pouvez simplement effectuer une requête similaire à une base de données, et la gestion est également pratique. Après tout, le texte est si simple pour le système.
.Net dispose d'une classe de diagnostic qui peut ajouter du texte à Trace et Debug sous forme d'écoute. De cette façon, toutes vos sorties dirigées vers Trace et Degug seront enregistrées dans le fichier. C'est une très bonne méthode.
en utilisant System.Diagnostics ;
Debug.Listeners.Add(new System.Diagnostics.TextWriterTraceListener(DateTime.Now.ToString("aaaaMMjj")+"..log"));
(
new System.Diagnostics.TextWriterTraceListener(Console.Out));
Trace.Listeners.Add(new System.Diagnostics.TextWriterTraceListener(DateTime.Now.ToString("aaaaMMjj")+"..log"));
Trace.Listeners.Add(new System.Diagnostics.TextWriterTraceListener(Console.Out));
La différence ici est la suivante : Trace peut être utilisé sous Release, tandis que Debug ne peut être utilisé que sous Debug.
Je pense que parmi tous les journaux texte, la méthode ci-dessus est la plus utile. Il vous suffit de créer une autre classe de gestion des journaux.
Bien entendu, vous devez également noter que le moniteur doit être mis à jour après 24 heures. Vous devez nettoyer le moniteur actuel et en ajouter un nouveau. C'est aussi simple.
Une autre méthode consiste à rédiger vous-même le texte pour la direction. Cette méthode est un peu plus compliquée, mais ce n'est pas difficile.
Cependant, en plus d'être peu pratiques pour effectuer beaucoup de travail de journalisation, les journaux de texte ont également un problème fatal : les conflits de processus !
Étant donné que la journalisation de texte verrouille le fichier texte en cours d'écriture, les autres programmes souhaitant écrire dans le fichier rencontreront des erreurs. Dans des circonstances normales, s'il n'y a qu'une seule copie du programme en cours d'exécution et que le journal est traité comme un objet statique global, il n'y aura pas de gros problème. Mais la deuxième copie du programme ne démarrera pas car le fichier ne peut pas être ouvert.
Ce n’est pas un problème insoluble, assurez-vous simplement d’avoir une copie du programme. Si ce n’est pas garanti, alors c’est un peu compliqué, nous n’en discuterons donc plus ici. Nous aborderons cette question la prochaine fois lorsque nous en aurons l’occasion.
Pour le problème ci-dessus, je souhaite abandonner temporairement le journal de texte et utiliser le journal des événements système pour le résoudre.
Journal des événements système :
Il existe une classe EventLog sous .net, qui est directement associée au journal des événements du système.
Simple :
EventLog.WriteEntry("LogSource","Ceci est un journal de test.");
Vous pouvez écrire un événement dans le système.
Cependant, bien l’utiliser peut s’avérer un peu délicat. Tout d'abord, la méthode ci-dessus écrira un journal des événements sous l'application du système, et la valeur par défaut est le type d'information. Ceci n'est pas propice à la gestion. Vous pouvez consulter les journaux dans l'outil de gestion et vous trouverez un grand nombre de journaux. Il est impossible de trouver un petit journal écrit par vous-même.
Cependant, .Net nous propose plusieurs méthodes pour mieux gérer les journaux.
1. Ajoutez une nouvelle LogSource.
Qu’est-ce que LogSource ? En fait, pour faire simple, il s'agit d'une marque de classification des journaux. Par exemple, vous pouvez utiliser un programme pour récupérer des journaux dont LogSource est le contenu spécifié à un moment donné. De cette façon, tant que vous vous souvenez du nom de la source, vous pouvez lire et classer les journaux.
Par défaut, lorsque vous écrivez des journaux directement à l'aide de la fonction statique d'EventLog, vous devez spécifier un LogSource. Si le LogSource n'existe pas, il en créera automatiquement un sous l'application. Par conséquent, la création d'un LogSource est aussi simple que cela.
2. Ajoutez un nouveau journal.
Qu'est-ce que le journal ? Le journal fait ici référence à la classification des grands journaux dans le journal des événements système. Généralement, le système comporte trois journaux : application, système et service, chacun avec une source différente, formant ainsi un système de journalisation.
Vous ne pouvez pas créer un journal indépendamment, car .NET ne fournit aucune méthode pour créer un journal, vous pouvez uniquement utiliser la fonction : CreateEventSource(string, string)
Pour créer une source, si vous faites ceci : CreateEventSource("MySource", "MyLog");
Vous verrez une classe MyLog supplémentaire dans le gestionnaire de journaux, puis écrirez le journal comme ceci :
EventLog.WriteEntry("MySource","Ceci est un journal de test.");
Vous pouvez écrire un enregistrement dans la catégorie MyLog, afin de pouvoir bien gérer vos propres journaux.
Ce qu'il faut expliquer c'est :
Si la Source existe déjà, la création échouera. Remarque : quel que soit le journal de la source, tant que le nom de la source existe déjà, votre création échouera. Par exemple : s'il existe un journal « Source1 » dans l'application, vous ne pouvez pas créer un journal nommé « Source1 » dans d'autres journaux. De plus : les journaux que vous créez à l'aide du programme ne peuvent pas être supprimés dans le gestionnaire de journaux (les messages peuvent être supprimés, mais les catégories de journaux ne peuvent pas être supprimées). La méthode est que vous pouvez toujours utiliser un programme pour le supprimer ou le supprimer dans le registre. Son emplacement : [HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesEventlog]
Jetez un œil au registre, vous comprendrez peut-être quelque chose.
La dernière étape consiste à utiliser l'objet instance de journal pour écrire le journal. Vous pouvez spécifier un nom de journal et un nom de source pour écrire des journaux, mais sachez que le journal et la source doivent correspondre, sinon une erreur se produira. C'est un peu plus compliqué que de journaliser directement à l'aide de méthodes statiques, mais vous avez plus de liberté.
L'inconvénient du journal des événements système est qu'il n'est conservé que pendant trois mois et est difficile à gérer. Il serait préférable que vous puissiez gérer le serveur directement ou l'exécuter localement, sinon vous devrez écrire du code pour gérer vous-même les journaux. Bien sûr, certains journaux importants peuvent être exportés vers d’autres fichiers.
Ses avantages sont nombreux :
1. Il n'est pas nécessaire de se connecter à la base de données, l'efficacité sera plus élevée et il n'y aura aucun problème d'échec d'accès à la base de données.
2. Il n'y aura aucun conflit de processus. Il s'agit d'un journal système, quelle que soit l'application, il peut écrire des journaux.
3. Disponibles dans le monde entier, les journaux peuvent être écrits directement, où qu'ils se trouvent et sont lisibles. Il peut donc être considéré comme une plateforme de communication par messagerie. (Bien sûr, peut-être que seuls ceux qui ont des problèmes cérébraux le feront.) Cependant, je veux juste expliquer : le journal écrit par le processus A peut être lu directement par le processus B.
D'accord, cette fois, c'est tout à propos du journal.
http://www.cnblogs.com/WuCountry/archive/2006/08/22/483090.html