.net - ロギングのベストプラクティス

Question

人々が実際のアプリケーションでトレースとロギングをどのように処理しているかについての話を聞きたいです。あなたの答えを説明するのに役立ついくつかの質問があります。

フレームワーク

どのようなフレームワークを使用していますか?

log4net
System.Diagnostics.Trace
System.Diagnostics.TraceSource
ロギングアプリケーションブロック
他の？

トレースを使用する場合、Trace.Correlation.StartLogicalOperation を使用しますか?

このコードを手動で記述しますか、それともなんらかのアスペクト指向プログラミングを使用しますか? コードスニペットを共有しますか?

トレースソースに対して何らかの形式の粒度を提供していますか? たとえば、WPF TraceSource を使用すると、さまざまなレベルで構成できます。

System.Windows -すべての WPF の設定
System.Windows.Animation -特にアニメーション用にオーバーライドします。

リスナー

どのログ出力を使用していますか?

テキストファイル
XML ファイル
イベントログ
他の？

ファイルを使用する場合、ローリングログを使用しますか、それとも単一のファイルのみを使用しますか? 人々がログを利用できるようにするにはどうすればよいですか?

閲覧中

ログを表示するためにどのツールを使用しますか?

メモ帳
しっぽ
イベントビューア
システムセンターオペレーションマネージャー/マイクロソフトオペレーションマネージャー
WCF サービストレースビューアー
他の？

ASP.NET ソリューションを構築している場合、ASP.NET ヘルスモニタリングも使用しますか? ヘルスモニターイベントにトレース出力を含めますか? Trace.axd はどうですか?

カスタムパフォーマンスカウンターはどうですか?

score 232 · Accepted Answer

更新: System.Diagnostics の拡張機能については、欠落しているリスナーの一部を提供するために、CodePlex の Essential.Diagnostics ( http://essentialdiagnostics.codeplex.com/ )を参照してください。

フレームワーク

Q: どのようなフレームワークを使用していますか?

A: .NET 2.0 に組み込まれている System.Diagnostics.TraceSource。

アプリケーションに強力で柔軟な高パフォーマンスのロギングを提供しますが、多くの開発者はその機能を認識しておらず、十分に活用していません。

追加機能が役立つ領域や、機能は存在するが十分に文書化されていない領域がありますが、これは、ロギングフレームワーク全体 (拡張可能に設計されている) を捨てて、いくつかの一般的な代替手段のように完全に置き換える必要があることを意味するものではありません。 (NLog、log4net、Common.Logging、さらには EntLib Logging)。

アプリケーションにログステートメントを追加する方法を変更して車輪を再発明するのではなく、必要な数か所で System.Diagnostics フレームワークを拡張するだけです。

他のフレームワークは、EntLib でさえも、Not Invented Here 症候群に苦しんでいるように思えます。System.Diagnostics で既に完全に機能している基本 (ログステートメントの書き方など) を再発明するのに時間を無駄にしていると思います。存在するいくつかのギャップを埋めるのではなく。要するに、それらを使用しないでください。それらは必要ありません。

あなたが知らなかったかもしれない機能:

Filter.ShouldTrace() が成功するまでパラメーターは個別の参照として保持されるため、フォーマット文字列と引数を取る TraceEvent オーバーロードを使用すると、パフォーマンスが向上します。これは、システムがメッセージが実際にログに記録されることを確認するまで、パラメーター値で ToString() への高価な呼び出しを行わないことを意味します。
Trace.CorrelationManager を使用すると、同じ論理操作に関するログステートメントを関連付けることができます (以下を参照)。
VisualBasic.Logging.FileLogTraceListener は、ログファイルへの書き込みに適しており、ファイルローテーションをサポートしています。VisualBasic 名前空間ではありますが、DLL を含めるだけで、C# (または他の言語) プロジェクトでも同じように簡単に使用できます。
EventLogTraceListener を使用して、複数の引数と空または null のフォーマット文字列を指定して TraceEvent を呼び出した場合、ローカライズされたメッセージリソースを使用している場合、引数は EventLog.WriteEntry() に直接渡されます。
Service Trace Viewer ツール (WCF から) は、(WCF を使用していない場合でも) アクティビティに関連するログファイルのグラフを表示するのに役立ちます。これは、複数のスレッド/アクティビティが関係する複雑な問題のデバッグに非常に役立ちます。
すべてのリスナーをクリアする (または Default を削除する) ことで、オーバーヘッドを回避します。それ以外の場合、Default はすべてをトレースシステムに渡します (そして、すべての ToString() オーバーヘッドが発生します)。

拡張を検討したい領域 (必要な場合):

データベーストレースリスナー
色付きのコンソールトレースリスナー
MSMQ / 電子メール / WMI トレースリスナー (必要な場合)
動的な構成変更のために Trace.Refresh を呼び出す FileSystemWatcher を実装する

その他の推奨事項:

構造化されたイベント ID を使用し、参照リストを保持します (たとえば、それらを列挙型で文書化します)。

システム内の (重要な) イベントごとに一意のイベント ID を持つことは、特定の問題を関連付けて見つけるのに非常に役立ちます。イベント ID を記録/使用する特定のコードを追跡するのは簡単で、一般的なエラーのガイダンスを簡単に提供できます。たとえば、エラー 5178 はデータベース接続文字列が間違っていることを意味します。

イベント ID は、特定のコードを知らなくてもカテゴリ別に扱うことができる、ある種の構造 (電子メールや HTTP で使用される応答コードの理論と同様) に従う必要があります。

たとえば、最初の桁は一般的なクラスを詳述できます。1xxx は「開始」操作、2xxx は通常の動作、3xxx はアクティビティトレース、4xxx は警告、5xxx はエラー、8xxx は「停止」操作、9xxx は致命的なエラー、等

2 桁目は領域の詳細を示すことができます。たとえば、21xx はデータベース情報 (41xx はデータベース警告、51xx はデータベースエラー)、22xx は計算モード (42xx は計算警告など)、23xx は別のモジュールなどです。

割り当てられた構造化されたイベント ID をフィルターで使用することもできます。

Q: トレースを使用する場合、Trace.Correlation.StartLogicalOperation を使用しますか?

A: Trace.CorrelationManager は、あらゆる種類のマルチスレッド環境 (最近ではほぼすべての環境) でログステートメントを関連付けるのに非常に役立ちます。

相互に関連付けるために、論理操作ごとに少なくとも 1 回、ActivityId を設定する必要があります。

Start/Stop と LogicalOperationStack は、単純なスタックベースのコンテキストに使用できます。より複雑なコンテキスト (非同期操作など) の場合、TraceTransfer を新しい ActivityId に (変更する前に) 使用すると、関連付けが可能になります。

Service Trace Viewer ツールは、(WCF を使用していない場合でも) アクティビティグラフを表示するのに役立ちます。

Q: このコードは手動で作成しますか? それとも、なんらかのアスペクト指向プログラミングを使用しますか? コードスニペットを共有しますか?

A: LogicalOperationScope など、(a) 作成時にコンテキストを設定し、(b) 破棄時にコンテキストをリセットするスコープクラスを作成するとよいでしょう。

これにより、次のようなコードを記述して、操作を自動的にラップできます。

  using( LogicalOperationScope operation = new LogicalOperationScope("Operation") )
  {
    // .. do work here
  }

スコープの作成時に、必要に応じて最初に ActivityId を設定し、StartLogicalOperation を呼び出してから、TraceEventType.Start メッセージをログに記録できます。Dispose では、Stop メッセージをログに記録し、StopLogicalOperation を呼び出すことができます。

Q: トレースソースに対して何らかの形式の粒度を提供していますか? たとえば、WPF TraceSource を使用すると、さまざまなレベルで構成できます。

A: はい。システムが大きくなるにつれて、複数のトレースソースが有用/重要になります。

警告と上記のすべてのメッセージ、または情報と上記のすべてのメッセージを一貫してログに記録したい場合がありますが、適度なサイズのシステムでは、アクティビティトレース (開始、停止など) と詳細ログの量が多すぎます。

すべてをオンまたはオフにするスイッチを 1 つだけ持つのではなく、一度にシステムの 1 つのセクションに対してこの情報をオンにできると便利です。

このようにして、通常のログ (すべての警告、エラーなど) から重大な問題を特定し、必要なセクションに「ズームイン」して、それらをアクティビティトレースまたはデバッグレベルに設定することができます。

必要なトレースソースの数は、アプリケーションによって異なります。たとえば、アセンブリごと、またはアプリケーションの主要セクションごとに 1 つのトレースソースが必要な場合があります。

さらに細かく制御する必要がある場合は、個別のブールスイッチを追加して、生のメッセージダンプなどの特定の大容量トレースをオン/オフにします。(または、WCF/WPF と同様に、別のトレースソースを使用することもできます)。

また、アクティビティトレースと一般的な (その他の) ログのトレースソースを別々にすることを検討することもできます。これにより、フィルターを希望どおりに正確に構成することが少し簡単になる可能性があります。

異なるソースが使用されている場合でも、ActivityId を介してメッセージを関連付けることができることに注意してください。そのため、必要な数だけ使用してください。

リスナー

Q: どのログ出力を使用していますか?

これは、作成しているアプリケーションの種類と、ログに記録される内容によって異なります。通常、異なるものは異なる場所に配置されます (つまり、複数の出力)。

私は通常、出力を次の 3 つのグループに分類します。

(1) イベント - Windows イベントログ (およびトレースファイル)

たとえば、サーバー/サービスを作成する場合、Windows でのベストプラクティスは、Windows イベントログを使用することです (レポートする UI がありません)。

この場合、致命的、エラー、警告、および (サービスレベルの) 情報イベントはすべて、Windows イベントログに記録されます。情報レベルは、これらのタイプの高レベルイベント、イベントログに記録したいイベント (「サービス開始」、「サービス停止」、「Xyz への接続」、場合によっては「スケジュール開始」など) 用に予約する必要があります。、「ユーザーがログオンしました」など。

場合によっては、イベントログへの書き込みを、トレースシステム経由ではなく、アプリケーションの組み込み部分にしたい場合があります (つまり、イベントログエントリを直接書き込みます)。これは、誤ってオフにできないことを意味します。(相関できるように、トレースシステムで同じイベントを記録する必要があることに注意してください)。

対照的に、Windows GUI アプリケーションは通常、これらをユーザーに報告します (ただし、Windows イベントログにも記録される場合があります)。

イベントには、関連するパフォーマンスカウンター (エラー数/秒など) がある場合もあります。イベントログへの直接書き込み、パフォーマンスカウンター、トレースシステムへの書き込み、およびユーザーへのレポートを調整して、イベントが発生するようにすることが重要です。同時に。

つまり、ユーザーが特定の時間にエラーメッセージを表示した場合、Windows イベントログで同じエラーメッセージを見つけ、トレースログで同じタイムスタンプを持つ同じイベントを (その他のトレースの詳細と共に) 見つけることができるはずです。

(2) アクティビティ - アプリケーションログファイルまたはデータベーステーブル (およびトレースファイル)

これは、システムが実行する通常のアクティビティです。たとえば、Web ページの提供、株式市場での取引の登録、注文の実行、計算の実行などです。

アクティビティトレース (開始、停止など) は、ここで (適切な粒度で) 役立ちます。

また、特定のアプリケーションログ (監査ログと呼ばれることもあります) を使用することも非常に一般的です。通常、これはデータベーステーブルまたはアプリケーションログファイルであり、構造化データ (つまり、一連のフィールド) が含まれています。

アプリケーションによっては、ここで少しぼやけることがあります。良い例は、各リクエストを Web ログに書き込む Web サーバーです。同様の例として、各操作がアプリケーション固有の詳細とともにログに記録されるメッセージングシステムまたは計算システムが考えられます。

あまり良くない例としては、株式市場の取引や販売注文システムがあります。これらのシステムでは、重要なビジネス価値があるため、おそらくすでにアクティビティをログに記録していますが、それらを他のアクションに関連付けるという原則は依然として重要です。

カスタムアプリケーションログだけでなく、多くの場合、アクティビティには関連するパフォーマンスカウンター (1 秒あたりのトランザクション数など) もあります。

一般に、さまざまなシステム間でアクティビティのログを調整する必要があります。つまり、パフォーマンスカウンターを増やしてトレースシステムにログを記録すると同時に、アプリケーションログに書き込みます。すべてを同時に (またはコード内で連続して) 実行すると、問題のデバッグが容易になります (コード内の異なる時間/場所ですべてが発生する場合よりも)。

(3) デバッグトレース - テキストファイル、または XML またはデータベース。

これは、Verbose レベル以下の情報です (生データダンプのオン/オフを切り替えるカスタムブールスイッチなど)。これにより、システムがサブアクティビティレベルで行っていることの内臓または詳細が提供されます。

これは、アプリケーションの個々のセクション (したがって複数のソース) に対してオン/オフできるようにするレベルです。このようなものが Windows イベントログを乱雑にするのは望ましくありません。データベースが使用されることもありますが、一定時間後にパージされるローリングログファイルである可能性が高くなります。

この情報とアプリケーションログファイルの大きな違いは、構造化されていないことです。アプリケーションログには、To、From、Amount などのフィールドが含まれる場合がありますが、詳細なデバッグトレースは、プログラマーが入力したもの、たとえば「値 X={value}、Y=false のチェック」、または「やった、やり直そう」。

重要なプラクティスの 1 つは、アプリケーションログファイルまたは Windows イベントログに入力した内容も、同じ詳細 (タイムスタンプなど) でトレースシステムに記録されるようにすることです。これにより、調査時にさまざまなログを関連付けることができます。

複雑な相関があるために特定のログビューア (サービストレースビューアなど) を使用する場合は、XML などの適切な形式を使用する必要があります。それ以外の場合は、通常は単純なテキストファイルで十分です。下位レベルでは情報の大部分が構造化されていないため、配列のダンプ、スタックダンプなどを見つけることができます。上位レベルでより構造化されたログに関連付けることができれば、物事は次のようになります。大丈夫。

Q: ファイルを使用する場合、ローリングログを使用しますか、それとも単一のファイルのみを使用しますか? 人々がログを利用できるようにするにはどうすればよいですか?

A: ファイルの場合、通常、管理の容易性の観点からローリングログファイルが必要です (System.Diagnostics では、VisualBasic.Logging.FileLogTraceListener を使用するだけです)。

可用性は、システムによって異なります。ファイルについてのみ話している場合、サーバー/サービスの場合、必要に応じてローリングファイルにアクセスできます。(Windows イベントログまたはデータベースアプリケーションログには、独自のアクセスメカニズムがあります)。

ファイルシステムに簡単にアクセスできない場合は、データベースへのデバッグトレースの方が簡単な場合があります。[つまり、データベースの TraceListener を実装する]。

私が Windows GUI アプリケーションで見た興味深い解決策の 1 つは、実行中に非常に詳細なトレース情報を「フライトレコーダー」に記録し、問題がなければシャットダウンすると、単にファイルを削除するというものでした。

ただし、クラッシュまたは問題が発生した場合、ファイルは削除されませんでした。エラーを検出した場合、または次回の実行時にファイルに気付き、圧縮 (7zip など) して電子メールで送信するなどのアクションを実行できます。

最近の多くのシステムには、中央サーバーへの障害の自動レポートが組み込まれています (プライバシー上の理由などでユーザーに確認した後)。

閲覧中

Q: ログを表示するためにどのツールを使用しますか?

A: さまざまな理由で複数のログがある場合は、複数のビューアーを使用します。

Notepad/vi/Notepad++ またはその他のテキストエディタは、プレーンテキストログの基本です。

転送を伴うアクティビティなどの複雑な操作がある場合は、明らかに、Service Trace Viewer などの専用ツールを使用します。(ただし、必要ない場合は、テキストエディターの方が簡単です)。

私は通常、高レベルの情報を Windows イベントログに記録するので、構造化された方法で概要をすばやく把握できます (きれいなエラー/警告アイコンを探してください)。ログに十分な量がない場合にのみ、テキストファイルの検索を開始する必要がありますが、少なくともログは出発点となります。(この時点で、ログ全体が調整されていることを確認すると便利です)。

一般に、Windows イベントログは、MOM や OpenView などの監視ツールでこれらの重要なイベントを利用できるようにもします。

その他 --

データベースにログインすると、情報を簡単にフィルタリングおよびソートできます (たとえば、特定のアクティビティ ID を拡大します。(テキストファイルでは、Grep/PowerShell などを使用して、必要な特定の GUID をフィルタリングできます)。

MS Excel (または別のスプレッドシートプログラム)。これは、異なる値が異なる列に入るように適切な区切り文字を使用してインポートできる場合、構造化または半構造化された情報を分析するのに役立ちます。

デバッグ/テストでサービスを実行するときは、簡単にするために通常はコンソールアプリケーションでホストします。色付きのコンソールロガーが便利だと思います (たとえば、エラーは赤、警告は黄色など)。カスタムトレースリスナーを実装する必要があります。

フレームワークにはカラーコンソールロガーやデータベースロガーが含まれていないため、現時点では必要に応じてこれらを作成する必要があります (それほど難しくありません)。

いくつかのフレームワーク (log4net、EntLib など) が車輪の再発明に時間を浪費し、基本的なロギング、フィルタリング、およびテキストファイルへのロギング、Windows イベントログ、および XML ファイルをそれぞれ独自に再実装したことは、本当に腹立たしいことです。異なる方法 (ログステートメントはそれぞれ異なります)。その後、データベースロガーなどの独自のバージョンを実装しましたが、そのほとんどは既に存在しており、必要なのは System.Diagnostics 用のトレースリスナーを 2 つ追加するだけでした。重複した努力の大きな無駄について話してください。

Q: ASP.NET ソリューションを構築している場合、ASP.NET ヘルスモニタリングも使用しますか? ヘルスモニターイベントにトレース出力を含めますか? Trace.axd はどうですか?

これらは必要に応じてオン/オフできます。サーバーが特定のものにどのように応答するかをデバッグするには、Trace.axd が非常に便利だと思いますが、使用頻度の高い環境や長期間のトレースでは一般的には役に立ちません。

Q: カスタムパフォーマンスカウンターはどうですか?

プロフェッショナルなアプリケーション、特にサーバー/サービスの場合、パフォーマンスモニターカウンターと Windows イベントログへのログ記録の両方が完全に装備されていることを期待しています。これらは Windows の標準ツールであり、使用する必要があります。

使用するパフォーマンスカウンターとイベントログのインストーラーが含まれていることを確認する必要があります。これらはインストール時に作成する必要があります (管理者としてインストールする場合)。アプリケーションが正常に実行されている場合、管理者権限は必要ありません (したがって、不足しているログを作成することはできません)。

これは、非管理者として開発を練習する正当な理由です (サービスをインストールする必要がある場合などに備えて、別の管理者アカウントを用意してください)。イベントログに書き込む場合、.NET は、最初に書き込むときに不足しているログを自動的に作成します。非管理者として開発している場合は、これを早期に見つけて、顧客がシステムをインストールした後、管理者として実行していないために使用できないという厄介な驚きを回避できます。

score 40 · Accepted Answer

私の場合、プラットフォームの柔軟性 (デスクトップ .Net/Compact Framework、32/64 ビット) の観点から、log4net を推奨するコーラスに参加する必要があります。

ただし、それをプライベートラベルの API にラップすることは、主要なアンチパターンです。はすでにCommons LoggingラッパーAPIlog4net.ILoggerの .Net 対応物であるため、結合は既に最小限に抑えられています。また、Apache ライブラリでもあるため、制御を放棄していないため、通常は問題になりません。しなければならない。

私が見たほとんどのハウスラッパーライブラリも、1 つ以上の一連の障害を犯しています。

グローバルシングルトンロガー (または同等の静的エントリポイント) を使用すると、推奨されるクラスごとのロガーパターンの細かい解像度が失われ、他の選択性が向上しません。
オプションのException引数を公開しないと、複数の問題が発生します。
- これにより、例外ロギングポリシーの維持がさらに困難になるため、例外に対して一貫した処理が行われません。
- 一貫したポリシーを使用しても、例外を文字列にフォーマットすると、データが早期に失われます。ILayout一連のイベントを特定するために、例外を詳細にドリルダウンするカスタムデコレーターを作成しました。
プロパティの公開に失敗するとIsLevelEnabled、ロギングの領域またはレベルがオフになっている場合に書式設定コードをスキップする機能が破棄されます。

score 18 · Accepted Answer

私は asp.net で開発することはあまりありませんが、ロガーに関しては、多くのベストプラクティスが普遍的だと思います。私が長年にわたって学んだロギングに関するランダムな考えのいくつかを以下に示します。

フレームワーク

slf4j などのロガー抽象化フレームワークを使用して (または独自に作成して)、ロガーの実装を API から分離します。私は多くのロガーフレームワークが行き来するのを見てきましたが、手間をかけずに新しいものを採用できる方がよいでしょう。
さまざまな出力形式をサポートするフレームワークを見つけてみてください。
プラグイン/カスタムフィルターをサポートするフレームワークを探してみてください。
外部ファイルで構成できるフレームワークを使用して、顧客/消費者がログ出力を簡単に微調整して、商用のログ管理アプリケーションで簡単に読み取れるようにします。
カスタムロギングレベルを使いすぎないように注意してください。そうしないと、別のロギングフレームワークに移行できなくなる可能性があります。

ロガー出力

壊滅的な障害が発生する可能性があるロギングには、XML/RSS スタイルのログを避けるようにしてください。ロガーが終了タグを書き込まずに電源スイッチをオフにする</xxx>と、ログが破損するため、これは重要です。
スレッドをログに記録します。そうしないと、プログラムの流れを追跡することが非常に困難になる可能性があります。
ログを国際化する必要がある場合は、開発者に英語 (または選択した言語) でのみログインさせたい場合があります。
ログステートメントを SQL クエリに挿入するオプションがあると、デバッグの状況で命の恩人になることがあります。そのような：

    -- 呼び出しクラス: com.foocorp.foopackage.FooClass:9021
    SELECT * FROM foo;

クラスレベルのロギングが必要です。通常、ロガーの静的インスタンスも必要ありません。マイクロ最適化の価値はありません。
すべての例外が同じように作成されるわけではないため、ログに記録された例外のマーク付けと分類が役立つ場合があります。そのため、重大な状態で通知を送信する必要があるログモニターがある場合は、重要な例外のサブセットを事前に知っておくと役立ちます。
複製フィルターは視力とハードディスクを節約します。同じログステートメントが 10^10000000 回繰り返されるのを本当に見たいですか? 次のようなメッセージを受け取るだけでよいのではないでしょうか。 This is my logging statement - Repeated 100 times

この私の質問も参照してください。

score 17 · Accepted Answer

私のパンとバターは Java であるため、.Net のロギングについてコメントする資格はありませんが、過去 8 年間にわたってロギングを移行してきました。

JVM 内のすべてのスレッドで使用されるシングルトンロガーから始めて、プロセス全体のログレベルを設定しました。システムの非常に特定の部分をデバッグしなければならない場合、これにより膨大なログが発生するため、レッスン 1 はログをセグメント化することです。

ロガーの現在の化身は、デフォルトとして定義された 1 つを含む複数のインスタンスを許可します。さまざまなロギングレベルを持つ任意の数の子ロガーをインスタンス化できますが、このアーキテクチャの最も有用な側面は、ロギングプロパティを変更するだけで個々のパッケージとクラスのロガーを作成できることです。2 番目の教訓は、コードを変更せずに動作をオーバーライドできる柔軟なシステムを作成することです。

Log4J にラップされた Apache commons-logging ライブラリを使用しています。

お役に立てれば！

* 編集 *

以下の Jeffrey Hantin の投稿を読んだ後、内部ログラッパーが実際にどのようになったかを書き留めておくべきだったことに気付きました。これは基本的にファクトリであり、正しいプロパティファイルを使用して動作するロガーを取得するために厳密に使用されます (レガシーの理由により、既定の位置に移動されていません)。コマンドラインでロギング構成ファイルを指定できるようになったので、さらにスリムになると思います。新しいアプリケーションを開始する場合は、ロガーをラップする必要さえないという彼の声明に間違いなく同意します。

score 9 · Accepted Answer

Log4Netをログプロバイダーとして使用し、ログインスタンスのシングルトンラッパーを使用します（ただし、シングルトンはレビュー中であり、それらが良いアイデアかどうかを疑問視しています）。

以下の理由で選択しました。

さまざまな環境での簡単な構成/再構成
構築済みのアペンダーの数が多い
私たちが使用しているCMSの1つには、すでに組み込まれています
かなりの数のログレベルとその周辺の構成

言及する必要があります、これはASP.NET開発の観点から話しています

.NET FrameworkにあるTraceを使用することにはいくつかのメリットがありますが、主に、使用するコンポーネントが実際にはTrace呼び出しを行わないため、完全に販売されているわけではありません。私が頻繁に使用するのはSystem.Net.Mail、私が言えることだけです。

したがって、log4netをラップするライブラリがあり、コード内には次のようなものが必要です。

Logger.Instance.Warn("Something to warn about");
Logger.Instance.Fatal("Something went bad!", new Exception());

try {
  var i = int.Parse("Hello World");
} catch(FormatException, ex) {
  Logger.Instance.Error(ex);
}

メソッド内で、ロギングレベルが有効になっているかどうかを確認するため、log4net APIへの冗長な呼び出しはありません（したがって、デバッグが有効になっていない場合、デバッグステートメントは無視されます）が、時間がかかると自分でチェックできるように、それらを公開するように更新します。これにより、評価が行われるべきではないときに評価が行われるのを防ぐことができます。例：

Logger.Instance.Debug(string.Format("Something to debug at {0}", DateTime.Now);

これは次のようになります。

if(Logger.DebugEnabled) Logger.Instance.Debug(string.Format("Something to debug at {0}", DateTime.Now);

（少しの練習時間を節約してください）

デフォルトでは、次の2つの場所でログを記録します。

Webサイトのファイルシステム（提供されていないファイル拡張子）
エラーと致命的なメール送信

ファイルは、毎日または10 MB（IIRC）のローリングとして実行されます。EventLogは、サイトに提供したいよりも高いセキュリティを必要とする可能性があるため、使用しません。

メモ帳はログの読み取りに問題なく機能することがわかりました。

score 8 · Accepted Answer

どのようなフレームワークを使用していますか?

ロギングアプリケーションブロックと、.Net フレームワークビットを回避するカスタムロギングヘルパーを組み合わせて使用します。LAB は、サービスメソッドのエントリ/終了用の個別の一般的なトレースファイルと、予期しない問題用の特定のエラーファイルを含む、かなり広範なログファイルを出力するように構成されています。構成には、デバッグ支援のための日付/時刻、スレッド、pId など、および完全な例外の詳細とスタック (予期しない例外の場合) が含まれます。

カスタムログヘルパーは Trace.Correlation を利用し、特に WF でログを記録する場合に便利です。たとえば、一連のシーケンシャルワークフローを呼び出すステートマシンがあります。これらの呼び出しアクティビティのそれぞれで、(StartLogicalOperation を使用して) 開始をログに記録し、最後に一般的な return イベントハンドラーで論理操作を停止します。

これは、アクティビティの実行シーケンスに基づいて If/Else 分岐の決定などをより迅速に判断できるため、複雑なビジネスシーケンスで失敗をデバッグしようとするときに、何度か役立つことが証明されています。

どのログ出力を使用していますか?

テキストファイルと XML ファイルを使用します。テキストファイルは app ブロックを介して構成されますが、WF サービスからも XML 出力を取得しています。これにより、ランタイムイベント (持続性など) と一般的なビジネスタイプの例外をキャプチャできます。テキストファイルは、日とサイズごとにローリングされるローリングログです (合計サイズ 1MB がロールオーバーポイントであると思います)。

ログを表示するためにどのツールを使用しますか?

対象の出力グループに応じて、メモ帳と WCF Service Trace Viewer を使用しています。WCF Service Trace Viewer は、出力設定が正しく行われている場合に非常に便利で、出力をより簡単に読み取ることができます。とはいえ、とにかくエラーの場所が大まかにわかっている場合は、十分に注釈が付けられたテキストファイルを読み取るだけでも問題ありません。

ログは単一のディレクトリに送信され、ソースサービスに基づいてサブディレクトリに分割されます。ルートディレクトリは、サポートユーザーグループによってアクセスが制御されている Web サイトを介して公開されます。これにより、リクエストを送信したり、実稼働データの長い形式的なプロセスを経たりすることなく、実稼働ログを確認できます。

score 6 · Accepted Answer

ツールの作成者として、もちろん、.NET アプリケーションのログとトレースにSmartInspectを使用しています。通常、ライブログには名前付きパイププロトコルを使用し、エンドユーザーログには (暗号化された) バイナリログファイルを使用します。ビューアおよび監視ツールとして SmartInspect コンソールを使用します。

実際には、.NET 用のロギングフレームワークとツールが数多くあります。DotNetLogging.comには、さまざまなツールの概要と比較があります。

score 5 · Accepted Answer

回答には多くの優れた推奨事項があります。

一般的なベストプラクティスは、誰がログを読むかを検討することです。私の場合、それはクライアントサイトの管理者になります。そのため、彼らが行動できる何かを与えるメッセージをログに記録します。たとえば、「アプリケーションを初期化できません。これは通常、……が原因です」

score 1 · Accepted Answer

Webアプリケーションではlog4netを使用しています。

XML構成ファイルを変更することにより、実行時にログをカスタマイズする機能は、アプリケーションが実行時に誤動作していて、より多くの情報を確認する必要がある場合に非常に便利です。

また、特定のクラスまたは属性をターゲットにしてログインすることもできます。これは、エラーが発生している場所がわかっている場合に非常に便利です。典型的な例は、SQLだけがデータベースに送られるのを見たいNHibernateです。

編集：

すべてのイベントをデータベースとトレースシステムに書き込みます。エラーまたは例外に使用するイベントログ。ほとんどのイベントをデータベースに記録して、カスタムレポートを作成し、ユーザーがアプリケーションから直接ログを表示できるようにします。

score 1 · Accepted Answer

アスペクト指向のロギングに関する限り、別のSOの質問でPostSharpをお勧めしました-

Unity\T4\anything を使用したアスペクト指向ロギング

ロギングフレームワークを評価している場合は、回答で提供されているリンクにアクセスする価値があります。

.net - ロギングのベスト プラクティス

10 に答える 10

Q: どのようなフレームワークを使用していますか?

Q: トレースを使用する場合、Trace.Correlation.StartLogicalOperation を使用しますか?

Q: このコードは手動で作成しますか? それとも、なんらかのアスペクト指向プログラミングを使用しますか? コード スニペットを共有しますか?

Q: トレース ソースに対して何らかの形式の粒度を提供していますか? たとえば、WPF TraceSource を使用すると、さまざまなレベルで構成できます。