ロガーがクラスごとにロガーの使用を推奨するのはなぜですか？

Question 1

NLogのドキュメントによると：

ほとんどのアプリケーションは、クラスごとに1つのロガーを使用します。ここで、ロガーの名前はクラスの名前と同じです。

これは、log4netが動作するのと同じ方法です。なぜこれが良い習慣なのですか？

Question 2

log4netでは、クラスごとに1つのロガーを使用すると、ログメッセージのソース（つまり、クラスがログに書き込む）を簡単にキャプチャできます。クラスごとに1つのロガーがなく、代わりにアプリ全体に1つのロガーがある場合は、ログメッセージの送信元を知るために、より多くのリフレクショントリックに頼る必要があります。

以下を比較してください。

クラスごとのログ

using System.Reflection;
private static readonly ILog _logger = 
    LogManager.GetLogger(MethodBase.GetCurrentMethod().DeclaringType);    

public void SomeMethod()
{
    _logger.DebugFormat("File not found: {0}", _filename);
}

アプリごとに1つのロガー（または同様のもの）

Logger.DebugFormat("File not found: {0}", _filename); // Logger determines caller

-- or --

Logger.DebugFormat(this, "File not found: {0}", _filename); // Pass in the caller

2番目の例を使用すると、ロガーはスタックトレースを作成して、誰が呼び出しているかを確認する必要があります。そうしないと、コードは常に呼び出し元に渡される必要があります。クラスごとのロガースタイルでもこれを行うことができますが、呼び出しごとに1回ではなく、クラスごとに1回行うことができ、深刻なパフォーマンスの問題を排除できます。

Question 3

NLogで「ファイルごとのロガー」を使用する利点：名前空間とクラス名でログを管理/フィルタリングできる可能性があります。例：

<logger name="A.NameSpace.MyClass"      minlevel="Debug" writeTo="ImportantLogs" /> 
<logger name="A.NameSpace.MyOtherClass" minlevel="Trace" writeTo="ImportantLogs" /> 
<logger name="StupidLibrary.*"          minlevel="Error" writeTo="StupidLibraryLogs" />

<!-- Hide other messages from StupidLibrary -->
<logger name="StupidLibrary.*" final="true" /> 

<!-- Log all but hidden messages -->
<logger name="*" writeTo="AllLogs" />

NLoggerには、これを行うための非常に便利なコードスニペットがあります。nloggerスニペットは、次のコードを作成します。

private static NLog.Logger logger = NLog.LogManager.GetCurrentClassLogger();

したがって、キーストロークはわずかで、クラスごとにロガーがあります。ロガーの名前として名前空間とクラス名を使用します。クラスロガーに別の名前を設定するには、次を使用できます。

private static NLog.Logger logger = NLog.LogManager.GetLogger("MyLib.MyName");

また、@ JeremyWiebeが言ったように、メッセージをログに記録しようとしているクラスの名前を取得するためにトリックを使用する必要はありません。ロガーの名前（通常はクラスの名前）をファイルに簡単に記録できます。（または他のターゲット）${logger}レイアウトで使用する。

Question 4

私はこの選択のいくつかの理由を見ることができます。

ログ出力形式にロガーの名前を含めると、特定のログステートメントがどこから来たのかを常に知ることができます。
特定のロガーをオンまたはオフにするか、それらのレベルを設定することにより、きめ細かいレベルで表示するログステートメントを制御できます。

Question 5

NLogの場合、パフォーマンス上の利点もあります。ほとんどのユーザーは

Logger logger = LogManager.GetCurrentClassLogger()

スタックトレースから現在のクラスを検索すると、ある程度の（ただしそれほどではない）パフォーマンスが必要になります。

Question 6

ほとんどの場合、クラスの名前はロガーに適切な名前を提供します。ログファイルをスキャンすると、ログメッセージが表示され、コード行に直接関連付けることができます。

これが最善のアプローチではない良い例は、HibernateのSQLログです。「Hibernate.SQL」などの名前の共有ロガーがあり、さまざまなクラスが生のSQLを単一のロガーカテゴリに書き込みます。

Question 7

開発の観点からは、毎回ロガーオブジェクトを作成する必要がない場合が最も簡単です。一方、そうではなく、リフレクションを使用して動的に作成すると、パフォーマンスが低下します。これを解決するには、ロガーを動的に非同期で作成する次のコードを使用できます。

using NLog;
using System;
using System.Collections.Generic;
using System.Diagnostics;
using System.Linq;
using System.Text;
using System.Threading.Tasks;

namespace WinForms
{
    class log
    {

        public static async void Log(int severity, string message)
        {
            await Task.Run(() => LogIt(severity, message));
        }

        private static void LogIt(int severity, string message)
        {
            StackTrace st = new StackTrace();
            StackFrame x = st.GetFrame(2);     //the third one goes back to the original caller
            Type t = x.GetMethod().DeclaringType;
            Logger theLogger = LogManager.GetLogger(t.FullName);

            //https://github.com/NLog/NLog/wiki/Log-levels
            string[] levels = { "Off", "Trace", "Debug", "Info", "Warn", "Error", "Fatal" };
            int level = Math.Min(levels.Length, severity);
            theLogger.Log(LogLevel.FromOrdinal(level), message);

        }
    }
}

Question 8

2つの理由がすぐに思い浮かびます。

クラスごとに個別のログがあると、特定のクラスに関連するすべてのログメッセージ/エラーを簡単にグループ化できます。
クラス内にログを作成すると、クラス外ではアクセスできない可能性のある内部の詳細（たとえば、プライベート状態、クラスの実装を処理する情報など）をログに記録できます。

Question 9

おそらく、カプセル化を壊すことなくクラスにのみ表示されるメソッドをログに記録できるようにしたいため、これにより、ログ機能を壊すことなく、別のアプリケーションでクラスを簡単に使用できるようになります。

Question 10

名前空間またはクラスごとにアペンダーを簡単に構成できます。

Question 11

NLOGを使用している場合は、構成でcallsiteを指定できます。これにより、ロギングステートメントが配置されたクラス名とメソッドが記録されます。

<property name="CallSite" value="${callsite}" />

次に、ロガー名またはアセンブリ名に定数を使用できます。

免責事項：NLOGがこの情報を収集する方法がわかりません。私の推測は反映であるため、パフォーマンスを考慮する必要がある場合があります。NLOG v4.4以降を使用していない場合、非同期メソッドにはいくつかの問題があります。