Mehrere Protokollverwaltungsmethoden unter .Net
Log sind ein unverzichtbarer Bestandteil der Anwendung. Sie können nicht nur den Ausführungsstatus der Anwendung aufzeichnen, sondern auch einige Fehler aufzeichnen, um die Aktualisierung und Änderung der Anwendung zu erleichtern.
Es gibt verschiedene Möglichkeiten, Protokolle in .Net zu verwalten.
1. Datenbankprotokoll.
2. Textprotokoll.
3. Systemereignisprotokoll.
Erstens ist es einfach und bequem für Datenbankprotokolle zu verwenden. Ich werde hier nicht zu viel diskutieren. Ich glaube, dass jeder, der datenbezogene Projekte geschrieben hat, Daten zum Aufzeichnen einiger Protokolle verwenden wird. Der einzige Nachteil besteht jedoch darin, dass Sie zunächst sicherstellen müssen, dass Ihre Datenbankverknüpfung korrekt ist.
Diese Garantie ist jedoch nicht zwangsläufig, daher werde ich hier die beiden anderen Situationen besprechen, Textprotokolle und Systemereignisprotokolle.
Textprotokoll:
Es ist einfach zu bedienen und leicht anzuzeigen. Der Nachteil besteht darin, dass es nicht bequem ist, eine große Anzahl von Protokollen zu erstellen und den Protokollinhalt nicht bequem anzuzeigen und zu analysieren. Es kann jedoch immer noch an einigen Stellen verwendet werden, an denen die Datenbankprotokollierung nicht geeignet ist. Zum Beispiel die Ausgabe einiger Testnachrichten, eine kleine Menge Protokolle einiger unabhängiger Komponenten usw.
Um die Verwaltung zu erleichtern, werden Protokolldateien unter normalen Umständen in Tageseinheiten klassifiziert. Auf diese Weise können Dateien einfach verwaltet werden. Beispiel: Sie können anhand Ihres Dateinamens erkennen, wann sich dieses Protokoll befindet, und dann können Sie einfach eine Abfrage ähnlich einer Datenbank durchführen, und die Verwaltung ist ebenfalls bequem. Schließlich ist Text für das System so einfach.
.Net verfügt über eine Diagnoseklasse, die Text in Form von Listening zu Trace und Debug hinzufügen kann. Auf diese Weise werden alle an Trace und Degug gerichteten Ausgaben in der Datei aufgezeichnet. Das ist eine sehr gute Methode.
using System.Diagnostics;
Debug.Listeners.Add(new System.Diagnostics.TextWriterTraceListener(DateTime.Now.ToString("yyyyMMdd")+"..log"));
Debug.Listeners.Add(new System.Diagnostics.TextWriterTraceListener(Console.Out));
oder:
Trace.Listeners.Add(new System.Diagnostics.TextWriterTraceListener(DateTime.Now.ToString("yyyyMMdd")+"..log"));
Trace.Listeners.Add(new System.Diagnostics.TextWriterTraceListener(Console.Out));
Der Unterschied besteht darin, dass Trace unter Release verwendet werden kann, während Debug nur unter Debug verwendet werden kann.
Ich denke, von allen Textprotokollen ist die obige Methode die nützlichste. Sie müssen lediglich eine weitere Protokollverwaltungsklasse erstellen.
Natürlich sollten Sie auch beachten, dass der Monitor nach 24 Stunden aktualisiert werden muss. Sie sollten den aktuellen Monitor bereinigen und einen neuen hinzufügen. Es ist auch einfach.
Eine andere Methode besteht darin, den Text für das Management selbst zu schreiben. Diese Methode ist etwas mühsamer, aber nicht schwierig.
Textprotokolle sind jedoch nicht nur unpraktisch, da sie viele Protokollierungsaufgaben erledigen, sondern haben auch ein schwerwiegendes Problem: Prozesskonflikte!
Da die Textprotokollierung die zu schreibende Textdatei sperrt, treten bei anderen Programmen, die in die Datei schreiben möchten, Fehler auf. Wenn unter normalen Umständen nur eine Kopie des Programms ausgeführt wird und das Protokoll als globales statisches Objekt verarbeitet wird, treten keine großen Probleme auf. Die zweite Kopie des Programms kann jedoch nicht gestartet werden, da die Datei nicht geöffnet werden kann.
Dies ist kein unlösbares Problem. Stellen Sie lediglich sicher, dass Sie eine Kopie des Programms haben. Wenn dies nicht garantiert ist, ist es etwas kompliziert, daher werden wir es hier nicht mehr besprechen. Wir werden dieses Problem beim nächsten Mal besprechen.
Für das obige Problem möchte ich das Textprotokoll vorübergehend aufgeben und das Systemereignisprotokoll verwenden, um damit umzugehen.
Systemereignisprotokoll:
Unter .net gibt es eine EventLog-Klasse, die direkt mit dem Ereignisprotokoll des Systems verknüpft ist.
Ganz einfach:
EventLog.WriteEntry("LogSource","Dies ist ein Testprotokoll.");
Sie können ein Ereignis in das System schreiben.
Es kann jedoch etwas schwierig sein, es richtig einzusetzen. Zunächst schreibt die obige Methode ein Ereignisprotokoll unter die Anwendung des Systems. Der Standardwert ist der Informationstyp. Dies ist nicht förderlich für die Verwaltung. Wenn Sie sich die Protokolle im Verwaltungstool ansehen, ist es unmöglich, eine große Anzahl von Protokollen zu finden, die Sie selbst geschrieben haben.
.Net bietet uns jedoch mehrere Methoden zur besseren Verwaltung von Protokollen.
1. Fügen Sie eine neue LogSource hinzu.
Was ist LogSource? Vereinfacht ausgedrückt handelt es sich um ein Klassifizierungszeichen für Protokolle. Sie können beispielsweise ein Programm verwenden, um Protokolle abzurufen, deren LogSource jeweils der angegebene Inhalt ist. Auf diese Weise können Sie die Protokolle lesen und kategorisieren, solange Sie sich an den Quellnamen erinnern.
Wenn Sie Protokolle direkt mit der statischen Funktion von EventLog schreiben, müssen Sie standardmäßig eine LogSource angeben. Wenn die LogSource nicht vorhanden ist, wird automatisch eine unter der Anwendung erstellt. Daher ist das Erstellen einer LogSource so einfach.
2. Fügen Sie ein neues Protokoll hinzu.
Was ist Protokoll? Hier bezieht sich das Protokoll auf die große Protokollklassifizierung im Systemereignisprotokoll. Im Allgemeinen verfügt das System über drei Protokolle: Anwendung, System und Dienst, die jeweils eine andere Quelle haben und somit ein Protokollsystem bilden.
Sie können ein Protokoll nicht unabhängig erstellen, da .NET keine Methode zum Erstellen eines Protokolls bereitstellt. Sie können nur die Funktion verwenden: CreateEventSource(string, string)
Um eine Quelle zu erstellen, gehen Sie wie folgt vor: CreateEventSource("MySource", "MyLog");
Sie sehen eine zusätzliche MyLog-Klasse im Protokollmanager und schreiben das Protokoll dann wie folgt:
EventLog.WriteEntry("MySource","Dies ist ein Testprotokoll.");
Sie können einen Eintrag in die Kategorie „MyLog“ schreiben, sodass Sie Ihre eigenen Protokolle gut verwalten können.
Was erklärt werden muss ist:
Wenn die Quelle bereits vorhanden ist, schlägt die Erstellung fehl. Hinweis: Unabhängig vom Quellprotokoll schlägt die Erstellung fehl, solange der Name der Quelle bereits vorhanden ist. Beispiel: Wenn es in der Anwendung ein Protokoll mit dem Namen „Quelle1“ gibt, können Sie in anderen Protokollen kein Protokoll mit dem Namen „Quelle1“ erstellen. Außerdem: Die Protokolle, die Sie mit dem Programm erstellen, können im Protokollmanager nicht gelöscht werden (Nachrichten können gelöscht werden, Protokollkategorien können jedoch nicht gelöscht werden). Die Methode besteht darin, dass Sie es weiterhin mit einem Programm löschen oder in der Registrierung löschen können. Sein Speicherort: [HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesEventlog]
Werfen Sie einen Blick in die Registry, vielleicht verstehen Sie etwas.
Der letzte Schritt besteht darin, das Protokollinstanzobjekt zum Schreiben des Protokolls zu verwenden. Sie können zum Schreiben von Protokollen einen Protokollnamen und einen Quellennamen angeben. Beachten Sie jedoch, dass Protokoll und Quelle übereinstimmen müssen, da andernfalls ein Fehler auftritt. Dies ist etwas komplizierter als die direkte Protokollierung mit statischen Methoden, bietet aber mehr Freiheit.
Der Nachteil des Systemereignisprotokolls besteht darin, dass das Protokoll nur drei Monate lang gespeichert wird und schwer zu verwalten ist. Es wäre besser, wenn Sie den Server direkt verwalten oder lokal ausführen könnten, andernfalls müssten Sie selbst Code schreiben, um die Protokolle zu verwalten. Natürlich können einige wichtige Protokolle in andere Dateien exportiert werden.
Die Vorteile sind vielfältig:
1. Es ist keine Verbindung zur Datenbank erforderlich, die Effizienz ist höher und es treten keine Probleme mit Datenbankzugriffsfehlern auf.
2. Es kommt zu keinen Prozesskonflikten. Es handelt sich um ein Systemprotokoll, egal um welche Anwendung es sich handelt.
3. Global verfügbar, Protokolle können direkt geschrieben werden, egal wo sie sich befinden, und sind lesbar. Daher kann es als Messaging-Kommunikationsplattform betrachtet werden. (Natürlich tun dies möglicherweise nur diejenigen mit einigen Gehirnproblemen.) Ich möchte jedoch nur erklären: Das von Prozess A geschriebene Protokoll kann von Prozess B direkt gelesen werden.
Okay, diesmal dreht sich alles um das Protokoll.
http://www.cnblogs.com/WuCountry/archive/2006/08/22/483090.html