log4net versus TraceSource [geschlossen]

In diesem Thread haben viele Leute angegeben, dass sie log4net verwenden. Ich bin ein Fan von TraceSources und möchte wissen, warum log4net verwendet wird.

Hier ist, warum ich Spurenquellen mag:

• Steckbare Listener - XML, TextFile, Console, EventLog, rollen Sie Ihre eigenen
• Anpassbare Trace-Schalter (Fehler, Warnung, Info, ausführlich, Start, Ende, benutzerdefiniert)
• Anpassbare Konfiguration
• Der Protokollierungsanwendungsblock ist nur eine große Anzahl von TraceListenern
• Korrelation von Aktivitäten / Bereichen (z. B. Verknüpfen aller Protokolle innerhalb einer ASP.NET-Anforderung mit einem bestimmten Kunden
• Mit dem Service Trace Viewer können Sie Ereignisse für diese Aktivitäten einzeln visualisieren
• Alles ist in app.config / web.config konfigurierbar.

Da das .NET Framework intern TraceSources verwendet, kann ich auch die Ablaufverfolgung konsistent konfigurieren. Mit log4net muss ich sowohl log4net als auch TraceSources konfigurieren.

Was gibt mir log4net, was TraceSources nicht tut (oder was nicht durch das Schreiben einiger benutzerdefinierter TraceListener möglich ist)?

Ich denke, dass log4net alles tut, was Sie für mich aufgelistet haben.

Steckbare Listener klingen wie Appender - es gibt viele davon. Tatsächlich habe ich sogar die fortlaufende Protokolldatei gehackt, um immer in .log zu enden (für Dateizuordnungen), dem E-Mail-Appender ein CC-Feld hinzugefügt und schließlich meine Lieblingswerte für optimiert der farbige Konsolen-Appender. Wenn ich so mutig sein darf - mein farbiges Konsolenglück:

<appender name="ColoredConsoleAppender" type="log4net.Appender.ColoredConsoleAppender">
<!-- Can Use:
        Blue
        Green
        Red
        White
        Yellow
        Purple
        Cyan
        HighIntensity
        -->
<mapping>
  <level value="FATAL" />
  <foreColor value="Yellow, HighIntensity" />
  <backColor value="Red" />
</mapping>
<mapping>
  <level value="ERROR" />
  <foreColor value="White" />
  <backColor value="Purple, HighIntensity" />
</mapping>
<mapping>
  <level value="WARN" />
  <backColor value="Blue" />
  <foreColor value="White" />
</mapping>
<mapping>
  <level value="INFO" />
  <backColor value="Green" />
  <foreColor value="White" />
</mapping>
<mapping>
  <level value="DEBUG" />
  <foreColor value="White" />
</mapping>
<layout type="log4net.Layout.PatternLayout">
  <!--<conversionPattern value="%date [%thread] %-5level %logger [%property{NDC}] - %message%newline" />-->
  <!--<conversionPattern value="%-5level %file:%line - %message%newline" />-->
  <conversionPattern value="%level %logger:%line %newline     %message%newline" />
</layout>

Anpassbare Trace-Schalter: Log4net wird nur mit FATAL ERROR WARN INFO DEBUG geliefert, um die Ausführlichkeit zu erhöhen. Das einzige, was ich wirklich vermisse, ist AUDIT für wer-hat-was-Protokollierung.

Anpassbare Konfiguration: Ich verwende eine log4net.config-Datei, die ich zur Laufzeit lade (oder schreibe ein Protokoll in c: \ whining, dass ich die Konfiguration nicht finden kann.)

    Try
        ' Get log4net configuration from file
        Dim logConfigFile As FileInfo
        logConfigFile = New FileInfo(".\log4net.config")

        If logConfigFile.Exists Then
            XmlConfigurator.Configure(logConfigFile)
        Else
            CreateEmergenceLogFile(logConfigFile.FullName)
        End If

    Catch ex As Exception
        Console.Out.WriteLine("Could not load the log4net config file")
    End Try

Nur eine große Anzahl von TraceListenern: Tut mir leid, dass ich diese übersprungen habe - ich nehme Ihr Wort dafür.

Korrelation von Aktivitäten / Bereichen: Meinen Sie, dass jede Datei (Leseklasse) ein eigenes benanntes Protokoll erhält, das separate Schwellenwerte für die Protokollebene haben kann? Tatsächlich können Sie die Protokollierung sogar in eine einzelne Klasse segmentieren (die in Wahrheit möglicherweise zu viel geworden ist ...)

In einer Klassendatei:

    Private Shared _logger As log4net.ILog = _
log4net.LogManager.GetLogger(System.Reflection.MethodBase.GetCurrentMethod().DeclaringType)

Private Shared _loggerAttribute As log4net.ILog = _
log4net.LogManager.GetLogger(System.Reflection.MethodBase.GetCurrentMethod().DeclaringType.FullName & ".Attribute")

Private Shared _loggerCache As log4net.ILog = _
log4net.LogManager.GetLogger(System.Reflection.MethodBase.GetCurrentMethod().DeclaringType.FullName & ".Cache")

Der Service Trace Viewer: in der log4net.config:

  <logger name="NipissingU.ADWrapper.EntryTools.Attribute">
    <level value="INFO" />
  </logger>
  <logger name="NipissingU.ADWrapper.EntryTools.Cache">
    <level value="WARN" />
  </logger>

Alles ist in app.config / web.config konfigurierbar: Nun, vielleicht ist das eine gute Sache in ASP.NET, ich weiß es nicht, aber wenn ich Rich Client Bean Counting Apps mache, mag ich eine separate Konfigurationsdatei.

Alles hier ist nur meine eigenen kleinen Gebrauchstricks.

hth, -Mike

In den frühen Tagen (.NET 1.0) war die Ablaufverfolgung in .NET Framework ziemlich eingeschränkt.

Zum Beispiel kam die TraceSource-Partitionierung erst in .NET 2.0 und Sie hatten nur vier Ebenen (Fehler, Warnung, Information, Verbose), obwohl Sie ein halbes Dutzend boolescher Switches für die Partitionierung verwenden konnten, wenn Sie wollten.

log4j ist in Java sehr beliebt und hat daher viel Unterstützung für einen .NET-Port erhalten. Als es populär wurde, blieb es auch so, obwohl die Leute es nicht einmal richtig verwenden (z. B. in einen Singleton-Logger einwickeln und verlieren es ist Hauptmerkmal).

Dennoch denke ich, dass log4net und andere Frameworks (z. B. NLog, Common.Logging und sogar EntLib) den falschen Weg eingeschlagen haben, indem sie ihr eigenes Protokollierungssystem von Grund auf implementiert haben, dh sogar die Art und Weise geändert haben, wie Sie Protokollanweisungen schreiben.

Ich hätte es sehr vorgezogen, Anstrengungen zu sehen, insbesondere seit .NET 2.0, um die solide Basis dessen, was bereits in .NET vorhanden ist, zu erweitern. Ein Projekt, das das bereits Vorhandene erweitert, finden Sie im Essential Diagnostics-Projekt auf CodePlex ( http://essentialdiagnostics.codeplex.com/ ).

Einige Stärken von log4net:

• Es ähnelt log4j, wenn Sie eine gemischte Umgebung ausführen und eine konsistente Protokollierung wünschen.

• Die automatische Logger-Hierarchie, die Einstellungen erbt, ist im Vergleich zu der Anzahl der Trace-Quellen, die Sie implementieren und konfigurieren müssen, recht ordentlich. (obwohl wahrscheinlich in einigen Fällen übertrieben).

• log4net hat bereits ungefähr 28 Appender (entspricht Trace-Listenern), während System.Diagnostics nur 10 hat (weitere Informationen finden Sie im Essential.Diagnostics-Projekt). Wenn Sie also wirklich glauben, dass Sie RemoteSyslogAppender, NetSendAppender, AnsiColorTerminalAppender oder TelnetAppender benötigen du hast Glück.

Nachteile (im Vergleich zu System.Diagnostics):

• Sie müssen eine andere Protokollierungssyntax verwenden. Wenn Sie also bereits source.TraceEvent () verwenden, müssen Sie alles ersetzen.

• Dies erstreckt sich auch auf unterschiedliche Syntax für die Korrelation, sodass Sie von CorrelationManager zu log4net-Kontexten wechseln müssen.

• Kann nicht einfach in die Framework-Ablaufverfolgung (z. B. WCF) integriert werden.

• Schlechte Unterstützung für Ereignis-IDs (es muss ein separates Erweiterungsprojekt IEventLog verwendet werden).

• Unterstützt noch nicht die Ereignisverfolgung für Windows (Vista) oder das XML-Format des Service Trace Viewer.

Ein weiterer Grund für die Verwendung von TraceSources anstelle von Log4Net ist die Verfolgung selbst: Log4Net kann nur für die Protokollierung (Nachrichten) verwendet werden. Wie kann jedoch ein Objekt verfolgt werden (mehrere Informationen gleichzeitig)? Natürlich hat Log4Net viele Listener implementiert, aber brauche ich all diese? In den meisten Fällen nicht. Und wenn ich einen speziellen Hörer brauche, ist es nicht so schwer, meinen eigenen zu implementieren, nicht wahr? Zum Beispiel brauche ich einen Listener, um in eine Datenbank zu gelangen (nicht nur Nachrichten, sondern auch verschiedene Informationen (Zeichenfolgen, Ints usw.) gleichzeitig).

Habe ich recht

Der Grund, warum ich Log4Net der Verwendung von Trace als Targeting vorziehe - mit Log4Net kann ich verschiedene Ebenen meiner Anwendung (Datenzugriff, Dienste, Geschäftslogik usw.) und verschiedene Subsysteme (Authentifizierung, Verarbeitung usw.) unabhängig voneinander instrumentieren und / aktivieren / aktivieren Deaktivieren Sie die Protokollierung jedes Subsystems unabhängig voneinander.

Diese Flexibilität ermöglicht es mir, die detaillierte Protokollierung für ein Subsystem zu konfigurieren, ohne den Firehose für das gesamte System einzuschalten.

Die in der Trace-Klasse bereitgestellten statischen Methoden [wie TraceInformation ()] bieten keine Möglichkeit, anzugeben, von welchem ​​Subsystem die Protokollierung stammt. Daher ist dies nicht einfach durch Schreiben meines eigenen TraceListener möglich.

Ein weiterer Grund ist die Leistung - es gibt Teile meiner Anwendung, die möglicherweise mehrere tausend Nachrichten pro Sekunde protokollieren. Log4Net verursacht einen geringen Overhead. Im Gegensatz dazu hat der Protokollierungsanwendungsblock beim letzten Betrachten seine XML-Konfiguration für jede protokollierte Nachricht neu berechnet, wodurch der Block sehr schwer und langsam wurde.

Während ich nur mit der Funktionsweise von log4net vertraut bin, ist ein offensichtlicher Bonus für die Verwendung dieses Frameworks die unmittelbare Vertrautheit derjenigen, die an die Verwendung von log4j gewöhnt sind.

Ein weiterer kleiner Vorteil ist, dass das Testen der Protokollierung mit log4net äußerst einfach ist. Logger implementieren log4net.ILog. Wieder bin ich nicht mit der Microsoft-Lösung vertraut, aber ich frage mich, wie man das machen würde, ohne zuerst eine Fassade in die System.Diagnostics.Trace-Klasse zu schreiben.

Bei einem flüchtigen Blick auf die Dokumentation zu den Trace-Quellen konnte ich kein Äquivalent zu Layouts finden und wäre interessiert zu wissen, ob es ein solches Äquivalent gibt. Das PatternLayout ist sehr praktisch zum Formatieren von Protokolleinträgen mit allgemeinen Daten wie Datenstempeln, Thread-Informationen, Protokollkontext usw. Log4net PatternLayout-Dokumente: http://logging.apache.org/log4net/release/sdk/log4net.Layout.PatternLayout.html

Da das Schreiben von Erweiterungen für ein Protokollierungsframework wahrscheinlich ein klassisches „Meta-Problem“ ist, bringt log4net eine große Liste steckbarer Listener-Entsprechungen in die Tabelle.

Liste der Appender: http://logging.apache.org/log4net/release/config-examples.html