Logging Frameworks sind Bibliotheken, die dem Programmierer erleichtern, flexible Log-Ausgaben zu erzeugen.

Dabei muss der Entwickler im Programmcode nur angeben, dass er an einer Stelle eine Log-Meldung ausgeben möchte, etwa mit der Zeile:

logger.Error("Ein Fehler ist aufgetreten");

Wohin diese Meldung geschrieben wird (z.B. in eine Datei, ins Netzwerk, in eine Datenbank oder in eine E-Mail), wird über die Konfiguration des Logging-Frameworks festgelegt.  Dabei stehen sehr mächtige und flexible Möglichkeiten zur Verfügung. So ist es möglich, Meldungen parallel an mehrere Ziele zu schicken und Meldungen in Abhängigkeit vom Schweregrad oder dem Ort im Programm nur an bestimmte Empfänger zu schicken oder gar nicht auszugeben. Daneben bieten die Frameworks vielfältige Möglichkeiten der Formatierung der Log-Ausgaben über die Definition von Layouts.

Durch die Vielfalt an verschiedenen Ausgabe-Kanälen und die Mächtigkeit der Konfigurations-Möglichkeiten ist dem Logging-Framework auf jeden Fall der Vorzug vor einer selbst geschriebenen Lösung zu geben.

Die Konfiguration des Logging-Frameworks erfolgt durch eine XML-Datei oder programmatisch. Der große Vorteil einer Konfig-Datei ist die Möglichkeit, jederzeit die Logging-Einstellungen anpassen zu können, ohne die Applikation neu zu übersetzen. Alle Logging-Frameworks ermöglichen es zudem, Änderungen in der Konfig-Datei im laufenden Betrieb zu lesen und sofort zu aktivieren.


Log4j, log4net, log4cxx, log4php

Die Geschichte der hier betrachteten Logging-Frameworks beginnt mit log4j. Die Java-Bibliothek ist seit 2004 der de-Fakto Standard in der Java-Welt. Inspiriert durch den Erfolg der Original-Implementierung enstanden in darauf folgenden Jahren Implementierungen für .NET (log4net), C++ (log4cxx) und PHP (log4php). Diese folgen alle dem bewährten log4j-Ansatz, sind aber native Implementierung in und für die jeweilige Zielplattform und berücksichtigen dabei auch deren Möglichkeiten und Konventionen. 

Log4j und log4net sind in unzähligen Softwareprojekten im Einsatz und sehr ausgereift. Die zur Verfügung stehenden Appender und Layouts sind für die allermeisten Anforderungen ausreichend. Bei Bedarf ist es nicht schwer, eigene Appender für spezielle Einsatzzwecke zu erstellen.

Log4net ist inzwischen ein offizielles Projekt der Apache Foundation. Die letzte Version 1.2.11 ist vom 12.10.2011.


NLog

NLog ist ein alternatives Logging-Framework, das von Jarek Kowalski initiiert und koordiniert wird. Es ist stark von log4j und log4net beeinflusst, bringt jedoch einige neue Ansätze und Ideen mit und wird ständig weiter entwickelt. Allerdings muss man ein wenig aufpassen, wenn man von log4net kommt und seine Applikation auf NLog umstellt. Die notwendigen Anpassungen im Code sind schnell gemacht. Auch die Konfigurations-Datei von NLog ist ähnlich aufgebaut und läßt sich scheinbar 1:1 anpassen. Allerdings kann es passieren, dass de Anwedung nach der Umstellung deutlich langsamer läuft als vorher Dies liegt nicht daran, dass log4net grundsätzlich schneller ist, sondern an einem unterschiedlichen Default-Verhalten des NLog File-Targets im Vergleich zum File-Appender von log4net. Während log4net die Log-Datei zwischen zwei Schreibvorgängen offen hält, wird die Log-Datei von NLog nach jedem Schreibzugriff standardmäßig geschlossen. Dies kann durch das Attribut "keepFileOpen" des File-Targets aber geändert werden. 


Welches Framework soll ich nehmen?

Der .NET Entwickler hat mit log4net und NLog zwei gute Logging-Frameworks zur Auswahl. Für log4net spricht die Ausgereiftheit und die große Verbreitung. Wer noch andere Frameworks benutzt, die ihrerseits log4net einsetzen (z.B. der O/R-Mapper NHibernate), der sollte mit der eigenen Software auch bei log4net bleiben. Auch wer viel Erfahrung mit log4net hat kann guten Gewissens weiter damit arbeiten. Für NLog spricht die höhere Entwicklungsgeschwindigkeit und zusätzliche Features. 

Beide Frameworks werden von Log4View unterstützt.