Nlog und benutzerdefinierte Ebenen

@SemVanmeenen hat Recht, NLog erlaubt nicht das Hinzufügen von benutzerdefinierten Ebenen (dh die Erweiterung der möglichen Werte in der LogLevel-Klasse). Angesichts der Funktionsweise von Ebenen, zumindest in NLog, gibt jede Ebene im Allgemeinen die Priorität der Nachricht an. Wenn Sie also einige (oder alle) Logger so konfiguriert haben, dass nur Fehler und Nachrichten auf höherer Ebene protokolliert werden, werden Trace-, Debug-, Info und Warnmeldungen nicht protokolliert. Wo würde ein DBLog-Level passen? Es scheint, als wäre das eher eine "Kategorie" (die in etwa analog zu Loggernamen sein kann) als eine Ebene.

Brauchen Sie wirklich eine spezielle Ebene (oder mehr als eine), um Dinge wie "DBLog" zu protokollieren? Warum definieren Sie nicht einfach einen anderen Logger in Ihrer Konfigurationsdatei namens "DBLog"? Auf diese Weise können Sie mithilfe von Filtern und Zielen diese Protokolle an ein bestimmtes Ziel senden oder diesen Logger aktivieren oder deaktivieren. Siehe diesen Link für einige Beispiele, die Sie mit der NLog-Konfiguration machen können.

Eines der gebräuchlichsten Muster in NLog und log4net ist ein Logger pro Klasse wie folgt:

Sie können auch beliebige Logger-Namen verwenden:

Im zweiten Beispiel verwenden beide Klassen den gleichen Logger ("DbStuff") und beide können auf der Basis dieses Loggernamens gesteuert werden (Protokollierungsgrad, Ziel usw.).

Sie können auch verschiedene Logger innerhalb derselben Klasse verwenden (möglicherweise verwenden Sie standardmäßig den Logger-Stil "pro Klasse", aber Sie definieren auch einige "übergreifende" Logger, um ähnliche Informationen leichter zu protokollieren und zu steuern Klassen). Möglicherweise haben Sie einen Logger namens "SQL" oder "PERFORMANCE", mit dem Sie gelegentlich bestimmte Informationen protokollieren, die Sie auf einer anderen Ebene als der Klassenebene steuern möchten.

Mit verschiedenen Loggernamen können Sie Logging-Nachrichten sicher an verschiedene Ziele weiterleiten, ohne neue Log-Levels zu definieren.

Wenn das nicht hilft, könnten Sie vielleicht in Ihrer Frage genauer ausführen, was Sie tun möchten. Welchen Protokollierungscode wünschen Sie, dass Sie schreiben könnten, dass Sie das Gefühl haben, dass Sie jetzt nicht schreiben können?

[AKTUALISIEREN]

Nehmen Sie an, dass f1, f2, f3 und f4 Dateiziele sind.

Zeile 1 bewirkt, dass der Logger für Class1 in das f1-Ziel für Debug- und höhere Nachrichten schreibt (d. h. Trace wird übersprungen).

Zeile 2 bewirkt, dass der Logger für Class1 auf das f1-Ziel nur Debug- und Error-Level-Nachrichten schreibt (d. h. Trace, Info, Warn und Fatal werden übersprungen)

Zeile 3 bewirkt, dass die Protokollierer für alle Klassen im Namespace Name.Space unabhängig von der Ebene in die Ziele f3 und f4 schreiben.

Zeile 4 bewirkt, dass die Protokollierer für alle Klassen im Namespace Name.Space nur dann auf die Ziele f3 und f4 schreiben, wenn die Protokollstufe Warnung oder höher ist (d. h. Trace, Debug und Info werden übersprungen)

Zeile 5 bewirkt, dass die Protokollierer für alle Klassen im Namespace Name.Space alle Nachrichten zurückweisen, deren Ebene sich zwischen Debug und Fehler befindet. Sie werden abgelehnt, weil es keine writeTo-Klausel gibt. Aufgrund von final=true

Diese Beispiele zeigen, wie auf der Logger-Ebene gefiltert wird. Sie können weitere Filterungen auf der Zielebene mit dem FilteringTargetWrapper durchführen. Ich habe es nicht benutzt, aber es gibt ein Beispiel für die Konfiguration eines FilteringTargetWrapper:
Die nützlichsten NLog-Konfigurationen

Ich habe diese Beispiele aus der Hilfedatei, die mit der Aktualisierungsinstallation von NLog 1.0 geliefert wurde. Ich habe NLog 2.0 noch nicht installiert, da ich gerade mitten in einem Projekt bin und lieber warte, bis NLog 2.0 aus der Beta raus ist, bevor ich mich dazu bewege. Wenn Sie NLog 2.0 verwenden und die Hilfedatei keine besseren Beispiele enthält als auf der NLog-Website, sollten Sie zumindest die NLog 1.0-Hilfe installieren. Sie können die NLog 1.0 Hilfe hier bekommen: Ссылка

Soweit ich weiß, unmöglich. Die Log-Level-Klasse von nlog hat nicht einmal einen öffentlichen Konstruktor und nur vordefinierte statische Loglevel-Objekte ( dh die übliche Info, Trace, etc).

Aber gibt es einen Grund, warum ein Ziel allein nicht ausreicht?