40

標準トレース、Logger.NET、Enterprise Library、log4net、または Ukadc.Diagnostics のいずれかを選択するにはどうすればよいですか?

一方が他方よりも適切な状況はありますか? ...それは何でしょう？(ASP.NET、コンソール アプリ、Azure クラウド、SOHO、エンタープライズ...)

メリットやデメリットは？

他の主要なロギング フレームワークを見逃していませんか?

4

6 に答える 6

103

ここSOには多くの同様の質問があります:

一般的に使用されるいくつかのロギング フレームワークを見逃していました。一般的に使用されるフレームワークのリストを次に示します。そのうちのいくつかをリストしました。

ロギングの抽象化:

System.Diagnostics アドオン:

他の

codeplex からの他のいくつかのロギング フレームワーク (SO でここで言及されているのを見たことがあります):

どちらか一方を選択できるのはなぜですか。それは大変なことです。その多くは個人的な好みです。その一部は、技術 (または機能) の優位性です。

ロギング フレームワーク (特にサード パーティのフレームワーク) の明らかな欠点の 1 つは、サポートの品質です。log4net、NLog、Common.Logging などに問題がある場合はどうなりますか? それらのフレームワークの開発者から修正を得ることができますか? これらのフレームワークのソース コードを利用できるため、これはさほど重要ではないかもしれません。ただし、修正や拡張を行うためだけにソース ツリーを「継承」したくない場合があります。フレームワークは非常に拡張性が高いため、通常の拡張ポイントを介して多くの拡張機能を追加できます。

上に投稿したリンクを読んだら、好意的な言及の量だけに基づいて、log4net が明確な「勝者」であると言っても過言ではないと思います。これは、履歴ログのお気に入りであり、多くの人が今後使用することを選択するものとして、より頻繁に言及されるでしょう.

NLogには支持者がいますが、log4netが非常に似ているにもかかわらず、log4netが行う浸透、または「最優先」の認識がないようです。NLog の機能は log4net と非常に似ており、最近重要な開発サイクルを経ているという特別な利点があります。

Enterprise Library は、良い選択として宣伝されることがよくありますが、ひどい選択として宣伝されることもほぼ同じです。たぶん、その否定的な評判のいくつかは、初期のバージョンではあまり良くないのでしょうか? 多分それは今より良いですか？

System.Diagnostics は、多くの場合、少なくとも 3 つの強力な利点を持つ合理的な選択肢として推奨されます。サード パーティへの依存がない、多くの Microsoft コンポーネントが System.Diagnostics でインストルメント化されている、簡単に拡張できる (おそらく「無料で」既に存在するいくつかの機能を追加する) log4net や NLog? などのフレームワークで)。System.Diagnostics を使用する場合、Trace.WriteLine/Debug.WriteLine ではなく TraceSource オブジェクトを使用することが (私の推奨と同様に) コンセンサスになると思います。

System.Diagnostics と WCF はうまく連携することにも注意してください。WCF メッセージ トラフィックは System.Diagnostics でログに記録でき、WCF は System.Diagnostics アクティビティ情報 (System.Diagnostics.CorrelationManager.ActivityId) も WCF サービス境界呼び出し全体に伝達します。

log4net が引き続き最も人気のあるステータスを維持する必要があるかどうかはわかりません。 ここSOの他の場所で指摘されているように、log4netは最近多くの開発を受けていないようです（「log4netは死んでいる」というのは誇張だと思います）が、NLog 2.0は現在ベータ版であり、最終リリースは第1四半期に予定されています2011 (更新: NLog 2.0は2011 年 7 月 17 日にリリースされました)。これにより、NLog は明らかに log4net よりも優れた選択肢になりますか? わかりませんが、相対的に言えば、NLog は、少なくとも log4net 開発がより多くの生命の兆しを示すまで、新しい開発の推定お気に入りになるはずです。

log4net と NLog はどちらも非常に柔軟な構成オプションを提供します。これらを使用すると、ログ ステートメントの定義を非常に細かくすることができます (タイプごとにロガーを定義する「標準」パターンによって)。また、独自の「ロギング先」オブジェクト (log4net アペンダーと NLog ターゲット) と「フォーマット」オブジェクト (log4net パターン コンバーターと NLog LayoutRenderer) を開発できるようにすることで、ライブラリを簡単に拡張できます。

ロギング フレームワークの選択とは別に、一部 (多くの?) は、抽象化レイヤーを使用して、特定のロギング フレームワークへの強い依存関係からアプリケーション コードを隔離することを提唱しています。これは、おそらく既存のフレームワークの上に実装する独自の ILogger インターフェイスの形式を取ることができます。将来的には、別のフレームワークで ILogger を実装することにより、フレームワークを変更できます。または、DI/IoC を使用して「ILogger」をコードに挿入することもできます。多くの DI/IoC フレームワークは、組み込みの ILogger 抽象化を提供します。これは、log4net、NLog、または Enterprise Library を使用するように構成するか、独自の ILogger 実装を作成してそれを挿入することができます)。実装が何であるかを誰が気にしますか? コードが特定のロギング フレームワークに大きく依存しないようにするもう 1 つの方法は、Common.Logging や SLF などの既存のロギング抽象化フレームワークを使用することです。この利点は、アプリケーションが特定のロギング フレームワークに依存しないことです。ただし、ある依存関係 (ロギング フレームワーク) を別の依存関係 (ロギング抽象化フレームワーク) と交換したと言う人もいます。

ロギングの抽象化について、さらに 2 つの注意事項があります。

  1. ロギングを適切に抽象化すると、異なるロギング フレームワークからの出力を同じ出力ファイルにキャプチャできるようになります。Common.Logging ではこれを「ブリッジング」と呼んでいます。NLog に支えられた Common.Logging を使用してアプリを作成したとします。ここで、log4net を直接使用して作成されたサード パーティのクラス ライブラリを使用しているとします。ブリッジング システムを使用すると、(カスタム アペンダーを介して) log4net 出力をキャプチャし、それを Common.Logging 経由で再ルーティングして、サード パーティ クラス ライブラリのログ出力をアプリのログ出力のコンテキストで表示できます。

  2. ロギングの抽象化を使用すると、開発中にロギング フレームワークを「テストドライブ」することもできます。log4net がその方法だと考え始めるかもしれませんが、NLog を試してみることにオープンなままにしておく必要があります。ロギングの抽象化を使用すると、2 つの間を比較的簡単に切り替えることができます。最終的には、どのロギング フレームワークを選択するかを決めることができますが、それまでの間、特定のロギング フレームワークにまったく依存しない大量のコードを作成することができました。

別のフレームワークよりも 1 つのフレームワークを選択するもう 1 つの理由は、作業環境です。Enterprise Library の一部を既に使用している場合は、Enterprise Library のログを使用するように促すのに十分な場合があります。

Silverlight で開発している場合はどうなりますか? Calcium の一部である Clog のようなものを使用することもできます。Silverlight および WP7 と互換性のある NLog 2.0 を使用することもできます。

System.Diagnostics アドオン (Ukadc.Diagnostics、Essential.Diagnostics)。これらはロギング フレームワーク自体ではありません。むしろ、既存の System.Diagnostics フレームワークで使用できる便利なオブジェクトと拡張ポイントのコレクションを表しています。私の意見では、これらの各アドオンが追加する最も優れた点の 1 つは、log4net と NLog でフォーマットする方法と同様に、ログ出力をフォーマットする機能です。私は Essential.Diagnostics を使用したことはありませんが、Ukadc.Diagnostics を試してみて、本当に素晴らしいと思います。独自の「フォーマット トークン」を作成することも簡単です。

これがあなたの質問に完全に答えたかどうかはわかりませんが（とにかくかなり広いです）、ここには考える余地がたくさんあると思います.

于 2011-01-23T21:37:43.817 に答える
5

VS2010 で log4net の使用を開始したところ、System.Web に依存していることを発見しました...これにより、「.NET xx クライアント プロファイル」フレームワーク ターゲットと互換性がなくなります...クライアント プロファイルが .NET 再配布可能として選択されました。これは、大部分のマシンでコードを実行したい場合、log4net が最適なロガーではなくなったことを意味します...

他のオプションに関する情報をありがとう-私はそれらをチェックアウトします...

于 2011-03-02T17:30:05.873 に答える
0

GitHub の NetLog.Logging パッケージを見てください。これは私の作成です。これには監視アプリがあり、java.util.logging API パラダイムに従っています。これを使用するのが好きだからです。「書き込み」にアクセスするためのスピンロックがあり、ロック保持者は、次に進む前に、キューに入れられたすべてのレコードを制限まで書き込みます。これにより、ログの競合ベースの I/O が少なくなり、適切な妥協点が提供されます。

于 2013-12-30T19:00:32.623 に答える
0

何らかの理由で、System.Diagnostics は、すべてのトレース出力を単一のリスナーに送信する方法をサポートしていません。複数のソースを同じリスナーに送信する場合は、各ソースを名前で明示的にリストする必要があります。

多くの依存関係を持つ大規模なシステムでは、すべてのソースを知っているわけではなく、おそらく気にしないでしょう。カバーの下で何が起こっているかを出力で確認したいだけです。ソースごとにリスナーを個別に設定する必要があるため、大規模なシステムで System.Diagnostics を使用するのは非常に困難です。

log4net は、ルートレベルのアペンダー (リスナー) をサポートするだけでなく、ソースの論理セットのログをグループとして構成できる階層ログもサポートします。私の考えでは、これにより log4net が明確な選択になります。

于 2016-12-14T17:19:13.943 に答える