Zunächst entschuldige ich mich für den subjektiv klingenden Titel. Dies ist als direkte Frage gedacht.
Derzeit arbeite ich an einer Reihe von Tools:
Derzeit wurden die Windows-Dienste als Konsolen-Anwendungen entwickelt (um das Debuggen / Entwickeln zu erleichtern) und ich bin dabei, diese in Dienste umzuwandeln. Nach ein paar Tagen Test mit diesen Diensten, möchte ich die Granularität meiner Protokollierung erhöhen. Ich stelle fest, dass ich Console.WriteLine () vermisse und ich möchte eine alternative Protokollquelle wie eine Flat-Datei für diese Art von Ausgabe bereitstellen. Das hat mich dazu gebracht zu denken: "Soll ich einen Rahmen verwenden, oder habe ich genug?"
Der Grund, warum ich die Aspekte erwähnt habe, die ich entwickle, ist, Einblick in meine Situation zu geben. Eine "Core" -DLL wurde erstellt, die für alle Komponenten gilt und die Interaktionsebene zwischen den Anwendungen und der Datenbank abstrahiert. In dieser DLL wurde eine Klasse erstellt, die versucht, sich an einer Tabelle in der Datenbank anzumelden, andernfalls bei fehlgeschlagener Protokollierung im lokalen Ereignisprotokoll. Das ist es, das ist der Umfang der Protokollierung.
In den oben genannten Tools gibt es mehrere Protokollierungsvorgänge, die nicht unähnlich sind zu:
%Vor%Obwohl diese Methode ziemlich einfach ist, verwendet sie die Reflektion, um die Quelle des Fehlers zu identifizieren.
Meine Frage
Wenn ich meine aktuelle Logging-Lösung anschaue, erscheint sie "ausreichend" in Bezug darauf, was sie tut und wie sie in alle meine Lösungen integriert ist. Ich habe mich jedoch mit Logging-Frameworks (namentlich log4net) beschäftigt und ihre Features beeindrucken mich. Die Möglichkeit, in Zukunft ein anderes Ausgabeformat (zB einen SMTP-Server) hinzuzufügen, hört sich für mich irgendwie cool an! :)
Was ich gerne wissen möchte, sind die Vorteile des Umstiegs auf ein Framework (wie log4net)? Wie weit muss ich meinen Code anpassen? Ob ich nur auf das grünere Gras auf der anderen Seite schaue? Und schließlich, aber wahrscheinlich am wichtigsten, mache ich das Richtige? Sollte ich einfach die Fähigkeit zu meiner Log-Klasse "LogDebug" hinzufügen und damit fertig sein? Das letzte, was ich tun möchte, ist meine Suite komplett zu überholen, nur für eine "grundlegende" Funktion, aber wenn es andere Vorteile (Design, Vertrauen, gute Praxis? Usw.) gibt, bin ich interessiert.
Danke,
Die ordnungsgemäße Protokollierung ist besonders nützlich, wenn Code auf mehreren Remote-Systemen ausgeführt wird. Soweit ich mich erinnere, können Sie mit log4net Ihre Protokolle ohne großen Programmieraufwand an einen Remote-Syslog-Server senden (dh Sie können Ihre Protokolle von allen Maschinen in einem anzeigen) Wenn Sie dies tun, wird die Zeit, die Sie benötigen, um Informationen über einen Fehler oder ein Problem mit dem System zu erhalten, massiv reduziert und Sie sollten auch einen Hinweis darauf geben, wie häufig das Problem auftritt.
Wie bereits in anderen Beiträgen erwähnt, erlaubt log4net auch mehrere Appender und mehrere Loglevels, um zu bestimmen, wo bestimmte Log-Informationen gespeichert werden sollen (z. B. in einer Datenbank oder in einer lokalen Flat-Datei) ) zu speichern ist ein absolutes Kinderspiel.
Um es zu implementieren, gibt es mehrere gute Seiten, die Sie durch das Setup unterhalten. Wie Sie die Logging-Objekte verwenden, die log4net Ihnen zur Verfügung stellt, ist eine architektonische Wahl, aber Sie könnten einfach den Konstruktor eines Objekts ändern, um ein log4net-Objekt zu verwenden. Verwenden Sie einfach das log4net-Objekt wie in Console.WriteLine .
Ich finde die Tutorial-Serie hier besonders nützlich, und es wird auch tiefer gehen als ich hier über die Vorteile und die verschiedenen Arten der Konfiguration von log4net.
Ja. Die Verwendung eines vorhandenen, bewährten Logging-Frameworks (wie Log4net) ist eine gute Idee.
Log4Net ist zur Laufzeit konfigurierbar (ideal zum Aufspüren von Problemen im Produktionscode).
Wie ein Kommentator hervorgehoben hat, ist es auch sehr einfach zu benutzen.
Ja, Sie möchten definitiv ein Protokollierungs-Framework verwenden. Ein Protokollierungs-Framework ermöglicht Ihnen:
Vielleicht ist es noch wichtiger, wenn Sie ein Protokollierungsframework verwenden, ist es sehr einfach, eine Implementierung des Protokollierungsframeworks gegen eine andere auszutauschen (vielleicht eine Nullimplementierung, die einfach Nachrichten verwirft); wohingegen, wenn Sie alle Ihre Logging-Anweisungen schreiben, ist das Auslagern der Implementierung ein Alptraum.
Ich denke, Sie sollten Log4net verwenden, einfach weil es immer besser ist, es wiederzuverwenden als Ihr eigenes Ding zu bauen. log4net wurde von vielen Entwicklern verwendet und ist ziemlich ausgereift.
Denken Sie über Ihre Wartungsansicht nach; Ein oder zwei Monate später müssen Sie möglicherweise Ihre benutzerdefinierte Protokollierungsklasse ein wenig optimieren, etwas Multithreading-Unterstützung hinzufügen usw. Und wenn Sie die Fehler beheben, die sich aus Ihrer Protokollierungsklasse ergeben, werden Sie Log4net vermissen.
Einer der größten Vorteile ist, dass Sie den Code nicht selbst pflegen müssen. In den meisten Fällen haben Logging-Frameworks viel mehr Funktionen als Ihre eigene Lösung. Da sie sich so sehr auf die Protokollierung konzentrieren, sind diese Frameworks in der Regel sowohl in der Funktionalität als auch in der Art der Implementierung ziemlich vollständig. Und dann gibt es Zuverlässigkeit; es gibt nichts Schlimmeres als ein Logging-Framework, das nichts protokolliert, weil es abgehört wird. ;)
Nehmen Sie zum Beispiel ELMAH für ASP.net-Anwendungen. Es enthält auch Benachrichtigungen, exportiert in verschiedene Zielformate usw. Dinge, die ziemlich praktisch sind, aber Sie werden nie selbst bauen, wenn Sie es wirklich brauchen.
Wie viele Änderungen an Ihrem Code erforderlich sind, hängt natürlich sowohl von Ihrem Code als auch vom gewählten Framework ab. Es ist schwer darüber etwas zu sagen.
Ich werde NLog ( Ссылка ) sagen, da es nicht unter dem "Straight Java Port" leidet - dann schreibe 'Syndrom der meisten Oss. Net-Bibliotheken.
Einige der wichtigsten Vorteile für uns waren der sehr schnelle Logger.IsFooEnabled (volatile read) und die Gesamtleistung des Systems.
Jedem sein eigenes, aber ich persönlich bevorzuge NLog für meine Projekte (und einige meiner Kunden auch).
Prost, Florian
Der Vorteil eines guten Logging-Frameworks wie Log4Net ist, dass sie einen kleinen Einfluss auf Ihren Code haben, in Bezug auf Codezeilen, die Sie ändern müssen (mit anderen Worten, Sie müssen nur jede existierende Logging-Zeile ändern) / p>
Wenn Sie Bedenken haben, Ihren Code zu ändern, wenn Sie Frameworks ändern oder wenn Sie das Gefühl haben, einen eigenen Code zu erstellen, könnten Sie immer eine eigene Schnittstelle zum a Logging-Framework erstellen. Dann müssen Sie Ihren Code danach immer nur an einer Stelle ändern.
Ich denke, dass Sysadmins erwarten, dass Dienste im Anwendungsereignisprotokoll in Windows protokolliert werden.
Schlagen Sie System.Diagnostics.EventLog nach, obwohl log4net auch dazu schreibt ..
Die erste Aussage in der log4j-Website könnte in einigen Ihrer Fragen helfen, die zugrunde liegenden Prinzipien sind das selbe von log4net:
Mit log4j ist es möglich zu aktivieren Protokollieren zur Laufzeit ohne zu ändern die Anwendung binär. Das log4j Paket ist so konzipiert, dass diese Anweisungen können im versendeten Code verbleiben ohne eine schwere Leistung zu erleiden Kosten. Protokollierungsverhalten kann sein gesteuert durch Bearbeiten einer Konfiguration Datei, ohne die Anwendung zu berühren binär.
Mit einer Logger-Hierarchie ist es möglich, welches Protokoll zu steuern Anweisungen werden willkürlich ausgegeben feine Granularität aber auch große Leichtigkeit. Dies hilft, die Menge der protokollierten Daten zu reduzieren ausgeben und minimieren die Kosten von Protokollierung.
In diesem Fall muss das Rad nicht neu erfunden werden. Die meisten Logging-Frameworks sind etwas einfach, so dass der Umfang der Änderungen höchstwahrscheinlich von der Größe Ihrer vorhandenen Programme abhängt.
Wenn Sie Ihre Logger-Klasse richtig schreiben, kann sie leicht auf Ihre Bedürfnisse entbehrlich gemacht werden. Jedes Framework könnte Sie mit vielen Funktionen beeindrucken, aber ein anderes Framework ist eine weitere Variable in Ihrem Debugging-Prozess, da es Ihnen einen Fehler geben kann, der nicht existiert oder in Kombination mit Ihrer Anwendung einen Fehler verursachen kann. Wenn Sie bereit sind, Beta-Tests für Open-Source-Software-Projekt zu machen, ist das in Ordnung ...
An Ihrer Stelle würde ich eine Protokollklasse schreiben mit der Fähigkeit, die Funktionen zu erweitern, die Sie aufgrund der Liste der Funktionen, die bekannte Frameworks haben, für Ihr Projekt interessant finden. Ich sehe kein Problem, etwas in Datei zu protokollieren und es dann über SMS zu senden, nur eine kleine Funktion erledigt den Job.
Darüber hinaus können Sie Ihre eigene Klasse schreiben, die ziemlich abstrakt ist und Ihren Basiscode dort einfügt. Wenn Sie jemals ein externes Framework zum Testen Ihrer Klasse benötigen, könnten Sie es mit minimalen Auswirkungen auf den Code verwenden. Sehen Sie sich an, wie Frameworks auf Codeebene implementiert sind.
Denken Sie daran, dass Sie lernen müssen, wie Sie diese Frameworks richtig verwenden, wenn Sie nur einen sehr kleinen Teil davon nur noch protokollieren müssen ...