c# - Logging フレームワークを使用するポイントは何ですか?

Question

アプリケーション用のロギング フレームワークを使用するという点を見逃している可能性があると思います。すべての小さなアプリで、私は常に小さな「ロギング」クラスを作成し、ファイルに書き込まれるメソッドにログ メッセージを渡すだけです。

log4net のようなサードパーティのロギング フレームワークの目的は何ですか? 書き込み操作をログに記録するスレッドセーフですか、それとも何か不足していますか?

Answer 1

それは素晴らしい質問です。

1つ目の理由は「どうして？」ロギング フレームワークを使用している場合は、既にパッケージ化されているものを使用することによる保守性の利点を享受できます。

2 番目の理由は、ロギングが微妙であることです。さまざまなスレッド、セッション、クラス、およびオブジェクト インスタンスがすべてロギングに関与する可能性があり、その場でこの問題を解決する必要はありません。

3 つ目の理由は、コードにパフォーマンスのボトルネックが見つかる可能性があることです。バッファリングせずにファイルに書き込んでいるため、またはロガーが古いファイルをロールオーバーして圧縮しないためにハード ドライブのディスク領域が不足しているために、コードが遅いと判断することは、首の痛みになる可能性があります。

4 番目の理由は、syslog に追加したり、データベース、ソケット、または別のファイルに書き込みたい場合があるためです。フレームワークにはこの機能が組み込まれています。

しかし実際には、最初の答えが最良の答えです。自分で書くメリットはほとんどなく、たくさんの欠点があります。

Answer 2

他のコメントでは省略されているものがあります。必要な処理を実行するライブラリがすでに存在する場合は、コードを記述する必要がなくなります。

おそらく、ここでセマンティクスを実行している可能性があります。私にとって、「ログフレームワーク」は通常、ログメッセージをファイルに書き込むクラスにすぎません。したがって、独自のログフレームワークを作成します。あなたがそうしていることを考えると、「ロギングフレームワークを使用する」ことには明らかにいくつかのポイントがあります！

最終的には、同時ログを正しく処理し（出力ストリームをロックし）、ファイルやsyslogなどにログを記録できること、ログローリングを実行できることなどを確認する必要があります。他の人の十分にテストされたコードを使用することで、その労力を節約できます。

Answer 3

いくつかのメッセージのためにデータベースにログを記録するように切り替えたり、サポートで貧しい人をページングする警告システムに切り替えたりすることができます

ただし、さらに重要なことは、ほとんどのロギング フレームワークでは、さまざまなクラスのログレベルを指定できるため、ロギングを増やしたり減らしたりするたびに新しいバイナリを切り取る必要がないということです (本番環境で見つけたバグの詳細なロギング)。

Log4Net のサイトに詳細があります

Answer 4

ロギング フレームワークは柔軟性を提供し、車輪の再発明を防ぎます。現代の言語でファイルに追加するのは非常に簡単であることは知っていますが、自家製のロガーには複数のターゲットがありますか? 実行時にログのオンとオフを切り替えることはできますか? これらのホイールが無料で入手できるのに、パンクの危険を冒す必要はありません。

Answer 5

一言で言えば、柔軟性です。Log4xxx を使用すると、さまざまなログ レベルを実行したり、コードのさまざまなモジュールをさまざまなファイルに記録したりできます。また、どんな奇妙な状況に遭遇しても信頼できると信頼できます (ディスクの容量が不足している場合、ロガーはどうなりますか)。 ?)

Answer 6

独自のロギング システムの実装がどれほどスマートかによって異なります。

Java では、ログの種類などを継承したい場合、面倒な場合があり、Log4J などのサードパーティ ツールを使用することをお勧めします。C#にも似たようなものがあると思います。同様に、コマンド ラインからログ レベルを確認する場合も同様です。

すべての System.out をルーティングし、コンパイルするたびに出力するかどうかを制御したいだけなら、独自のロガーで問題ありません。