Frage

Zunächst einmal Entschuldigung für den subjektiven klingenden Titel. Dies wird als eine direkte Frage bestimmt.

Zur Zeit ich auf einer Reihe von Werkzeugen arbeitete:

  • A C # Windows-Dienst, um in erster Linie pflegen eine Oracle-Datenbank.
  • A C # Windows-Dienst, (welche wird auf mehreren Knotenstellen verwendet) zu Prozess Inhalt der Datenbank.
  • Eine ASP.NET Web-Interface erleichtern Steuerung des Gesamt "System"

Derzeit ist die tho Windows-Dienste wurden als Konsolenanwendungen (erleichtert das Debugging / Entwicklung) und ich bin mitten in der Umwandlung dieser Dienste entwickelt. Nach der Prüfung für ein paar Tage jetzt mit diesen Diensten, ich finde, dass ich die Granularität meiner Protokollierung erhöhen möchte. Ich finde, dass ich Console.WriteLine verpassen (), und ich möchte eine alternative Protokollquelle wie eine Flat-Datei für diese Art von Ausgabe liefern. Das hat mich führen zu denken: „Soll ich einen Rahmen verwenden, oder habe ich habe genug?“

Der Grund, warum ich die Aspekte erwähnt habe ich die Entwicklung bin, ist Einsicht in meine Situation. Ein „Core“ DLL wurde für alle Komponenten erstellt, gemeinsam, die Wechselwirkung Schicht zwischen den Anwendungen und Datenbank zu abstrahieren. Es ist innerhalb dieser DLL, die eine Klasse erstellt wurde, die „auf eine Tabelle log in der Datenbank“ wird versuchen, andere auf fail „anmelden, um lokale Ereignisprotokoll“. Das ist es, das ist das Ausmaß der Protokollierung.

In den oben genannten Tools gibt es mehrere Instanzen der Protokollierung nicht unähnlich:

Log.LogError("Code", e.Message + "\n" + e.StackTrace);

recht einfach Obwohl diese Methode macht Gebrauch von Reflexion, um die Ursache des Fehlers zu identifizieren.

Meine Frage

Ein Blick auf meiner aktuellen Logging-Lösung scheint es „ausreichend“ in Hinblick darauf, was sie tut und wie es integriert ist, mit allen meinen Lösungen. Allerdings habe ich bei Logging Frameworks gesucht (Bemerkenswerter log4net) und ihre Eigenschaften beeindrucken mich. Die Fähigkeit zu, wenn in der Zukunft benötigt wird, ein anderes Ausgabeformat (wie ein SMTP-Server) hinzufügen klingt irgendwie cool zu mir! :)

Was würde Ich mag wissen, sind die Vorteile auf einen Rahmen zu bewegen (wie log4net)? Das Ausmaß, wie viel ich habe meinen Code anzupassen? Unabhängig davon, ob schaue ich nur auf grünere Gras auf der anderen Seite? Und schließlich, aber wahrscheinlich am wichtigsten ist, mache ich das Richtige? Soll ich nur hinzufügen, die Fähigkeit, meine Log-Klasse „LogDebug“ und mit ihr geschehen? Das letzte, was ich möchte zu tun ist völlig meine Suite Überholung, nur für eine „grundlegende“ -Funktion, aber wenn es andere Vorteile sind (zu entwerfen, Vertrauen, gute Praxis? Etc.) Ich bin interessiert.

Danke,

War es hilfreich?

Lösung

Die richtige Protokollierung ist besonders vorteilhaft, wenn der Code auf mehreren Remote-Systemen ausgeführt wird, soweit ich mich erinnere, wird log4net können Sie Ihre Protokolle an einen entfernten Syslog-Server ohne viel Codierung Overhead senden (das heißt, Sie Ihre Protokolle von allen Maschinen in einem sehen können zentraler Ort) Dadurch wird die Zeit, die Sie massiv reduzieren braucht, um einen Fehler oder ein Problem mit dem System beziehen Informationen zu erhalten, und sollen Ihnen auch einen Hinweis darauf geben, wie weit verbreitet das Problem ist.

Wie in anderen Beiträgen erwähnt, log4net ermöglicht auch mehrere Appen und mehrere Protokollebenen, so zu bestimmen, wo Sie bestimmte Protokollinformationen wollen (dh in einer Datenbank oder in einem lokalen Flat File-, hey log4net können Sie sogar Protokolle ausspucken über Telnet ) ist ein absolutes doddle gespeichert werden.

Wie bei ihrer Umsetzung gibt es mehrere gute Websites, die Sie durch den Setup-Gespräch. Wie Sie tatsächlich Nutzung der Protokollierung Objekte machen, die log4net gibt Ihnen eine architektonische Wahl ist, aber man konnte einfach den Konstruktor eines Objekts ändern, um ein log4net Objekt zu nehmen und aus diesem Objekt, benutzen Sie einfach die log4net Objekt, wie Sie es Console.WriteLine .

Ich finde die Tutorial-Reihe hier besonders nützlich, und es wird auch zu mehr Tiefe als ich hier gehen über die Vorteile und die verschiedenen Möglichkeiten der Konfiguration von log4net.

Andere Tipps

Ja. Mit Hilfe eine bestehende, bewährte Logging-Framework (wie Log4net) ist eine gute Idee.

Log4Net ist konfigurierbar zur Laufzeit (ideal für das Aufspüren von Problemen in der Produktion Code).

Wie ein Kommentator wies darauf hin, es ist auch sehr einfach zu bedienen.

Ja, wollen Sie auf jeden Fall eine Logging-Framework verwenden. Ein Logging-Framework ermöglicht es Ihnen, zu:

      
  • Stellen Sie die Protokollierungsstufen für die verschiedenen Logger-Instanzen.
  •   
  • Stellen Sie den „Appen“ oder Ausgang für jede der verschiedenen Logger-Instanzen.

Vielleicht noch wichtiger ist, wenn Sie einen Logging-Framework verwenden, ist es sehr einfach für einen weitere Umsetzung der Logging-Framework zu tauschen (vielleicht eine Null-Implementierung, die einfach verwirft Nachrichten); während, wenn Sie alle Ihre Logging-Anweisungen schreiben, direkt, die Umsetzung Auslagern wird ein Alptraum sein.

Ich glaube, Sie Log4net verwenden sollten, einfach weil es immer besser, wieder zu verwenden als die eigene Sache zu bauen. log4net wird von vielen Entwicklern und ist ziemlich gereift verwendet.

Denken Sie über Ihre Wartung Aussicht; ein oder zwei Monate auf der Straße, könnten Sie Ihre benutzerdefinierte Protokollierung-Klasse ein wenig zwicken müssen, Multithreading-Unterstützung usw. hinzuzufügen Und wenn Du den Fehler ergab sich aus Ihrer Protokollierungsklasse Fixierung, werden Sie Log4net verpassen.

Nun ja, eine des größeren Nutzen ist nicht mit dem Code selbst zu halten. Die meiste Zeit, bei der Anmeldung haben Frameworks viel mehr Funktionen als Ihre eigene Lösung. Weil sie so auf der Protokollierung fokussiert sind, sind die Rahmenbedingungen in der Regel ziemlich komplett in den beiden Funktionen und Möglichkeiten, es zu implementieren. Und dann ist da noch die Zuverlässigkeit; es gibt nichts Schlimmeres als ein Logging-Framework, das nichts ist Protokollierung, weil es abgehört wird. ;)

Nehmen Sie zum Beispiel ELMAH für ASP.net Anwendungen. Es enthält auch Meldungen, die Ausfuhren in verschiedene Zielformate etc. Dinge, die ziemlich praktisch sind, aber Sie werden sich nie bauen, wenn Sie es wirklich brauchen.

Wie viele Änderungen an Ihrem Code erforderlich sind, hängt offensichtlich sowohl auf dem Code und dem Rahmen der Wahl. Es ist schwer, etwas darüber zu sagen.

Ich werde ein shout out zu NLog geben ( http://nlog-project.org/home ), da sie nicht aus dem leiden. - Syndrom der meisten oss .Net libs 'Straight Java-Port dann neu schreiben'

Einige der wichtigsten Vorteile für uns waren die sehr schnell Logger.IsFooEnabled (volatile Lesen) und die Gesamtleistung des Systems.

Zu jedem seines eigenen zwar, aber ich persönlich bevor NLog für meine Projekte (und einige meiner Kunden auch).

Cheers, Florian

Der Vorteil einer guten Logging-Framework wie Log4Net ist, dass sie einen geringen Einfluss auf den Code in Bezug auf die Codezeilen, die Sie ändern müssen (in anderen Worten: Sie jede vorhandene Protokoll Linie zu ändern haben).

Auch wenn Sie verändern den Code betroffen sind, wenn Sie Frameworks ändern, oder wenn Sie Sie Ihre eigene Rolle fühlen wollen, dann können Sie immer Ihre eigene Schnittstelle zu a Logging-Framework erstellen. Dann müssen Sie immer nur den Code in einem Ort nach dem ändern.

Ich denke, sysadmins Dienstleistungen für das Anwendungsereignisprotokoll in Windows anmelden erwarten.

nachschlagen System.Diagnostics.EventLog, obwohl log4net zu, dass schreiben, wird ..

Die erste Anweisung in der log4j Webseite könnte in einigen helfen, Ihre Fragen, sind die zugrundeliegenden Prinzipien das gleiche von log4net:

  

Mit log4j ist es möglich, zu ermöglichen,   zur Laufzeit Protokollierung ohne Änderung   die Anwendung binär. die log4j   Paket ist so ausgelegt, dass diese   Anweisungen können in verschifft Code bleiben   ohne eine schwere Leistung entstehen   Kosten. kann das Verhalten der Anmeldung sein   gesteuert durch eine Konfiguration der Bearbeitung   Datei, ohne die Anwendung zu berühren   binär.

     

Mit einer Logger Hierarchie wird   möglich zu steuern, welche log   Anweisungen ausgegeben an willkürlich   feine Granularität, sondern auch große Leichtigkeit.   Dies hilft, das Volumen der protokollierten reduzieren   Ausgabe und minimieren die Kosten für   Protokollierung.

In diesem Fall gibt es offensichtlich keine Notwendigkeit, das Rad neu zu erfinden. Die meisten Logging Frameworks sind etwas einfach, so dass die Änderungen verlängern wird höchstwahrscheinlich auf die Größe Ihrer vorhandenen Programme ab.

Wenn Sie Ihre Logger Klasse schreiben richtig wird es leicht auf alle Ihre Bedürfnisse entbehrlich sein. Jeder Rahmen könnte man mit vielen Funktionen beeindrucken, aber ein anderer Rahmen ist eine andere Variable in Ihrem Debug-Prozess, wie es können Sie einen Fehler geben, die nicht existiert nicht oder kann selbst in Kombination einen Fehler machen mit Ihrer Anwendung. Wenn Sie bereit sind, Beta-Test für Open-Source-Software-Projekt zu machen, das ist in Ordnung ...

An deiner Stelle würde ich schreiben Klasse log mit der Fähigkeit zu erweitern es Funktionen, die Sie interessant finden Sie auf der Liste der Features bekannten Frameworks haben basierte Projekt. Ich sehe kein Problem, etwas zu einer Datei zu protokollieren und dann über smpt senden, nur eine kleine Funktion macht den Job.

Darüber hinaus können Sie Ihre eigene Klasse schreiben, die ziemlich abstrakt sein und dort Ihre grundlegenden Code setzen, wenn Sie jemals äußeren Rahmen benötigen verwenden Sie Klasse Prüfung der Lage wäre, es mit minimalen Auswirkungen auf den Code zu verwenden. Werfen Sie einen Blick, wie es Frameworks auf die Code-Ebene umgesetzt werden.

denken, dass müssen Sie lernen, wie man richtig diese Frameworks verwenden, wenn Ihr nur Bedarf für jetzt sehr kleiner Teil davon einzuloggen ...

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top