エンタープライズアプリケーションをログに記録するためのベストプラクティスは何ですか？
エンタープライズアプリケーションのロギング標準にはどのようなものがありますか？
このトピックに関するホワイトペーパーはありますか？
Microsoft Enterprise Library を参照してください。これには Logging Application Block が含まれており、そのドキュメントが探しているものである可能性があります。最初にライブラリをインストールしなくても、 MSDNドキュメント を表示できます。具体的には、 主要なシナリオ および ロギングアプリケーションブロックの設計 を参照して、質問に回答してください（.NETを使用していない場合でも） ）。
更新（2013年4月23日）新しい セマンティックロギングアプリケーションブロック を使用した セマンティックロギングの採用 を参照してください。
これについては、 効果的なロギングの実践により企業の発展が容易になる という良い記事が書かれています。
重要なのは：
- ロギングの必要性を知っています。
- 利用可能なオプションと最適なオプションを理解します（プラットフォーム/ OSなどによって異なります）
- 実装前に事前に戦略を計画します。
- 確認を続け、変更を加えます。
いくつかのヒント ：
- リリース/本番環境で必要以上にログを記録しない
- これまでにエラーをログに記録します。可能であれば、これを作成します：
- ログ操作を一時変数（ベクトル/リスト）に入れます
- 最後に、エラーが発生しない場合はログを破棄し、別の場合はログファイルに送信します
- ログに記録する情報のレベルを制御するフラグを作成します
- 本番/開発環境でのログの動作を制御する
- ログファイルで同時実行アクセスを制御する
- 必要なファイルログの長さを制御する
- ファイルログを維持する時間を制御する
- パフォーマンス検証を実行する必要がある場合があり、必要に応じてタイマーを配置します
Log4netやlog4jを含むログフレームワークはたくさんありますが、適切なものはプラットフォームとシステムによって異なります。
最適なロギング手法は、プラットフォームとシステムの設計に大きく依存します。特定のタイプの問題を診断するために必要な情報の量を知る/決定する必要があります。一般に、コードの繰り返しや変更をあまり必要としない方法でコードをインストルメント化する必要があります。 Attributedクラスとメソッドを使用する.NETのロギングフレームワークは、影響の少ないインストルメンテーションの良い例です。また、サービスをシャットダウンまたは再起動しなくても、構成を通じてロギングのレベル（LowからVerbose）を変更できる必要があります。
このテーマに関する哲学に本当に飛び込みたい場合は、MiloslavTrmačのブログで "構造化ロギングを信じないでください" を試してください。
「...これらのレッスンは難しい方法で学んだ...」
Serilog は、質問が最初に行われて以来人気が高まっているもう1つの構造化ロギングソリューションです。
Blumhardt氏はインタビューの中で、私たち全員が経験した伐採の苦痛を経験した結果としての図書館の建設について語っています。彼らはショーで、初期開発中の単純なロギングと、プロジェクトが成熟するにつれてロギングを形式化することについて話します。良いものであり、質問で提起されたベストプラクティスの知識ベースに追加される可能性があります。
ウェブサイトから：
.NETの他のログライブラリと同様に、Serilogはファイルやコンソールなどに診断ログを提供します。セットアップが簡単で、クリーンなAPIを備えており、最近の.NETプラットフォーム間で移植可能です。
.NETの他のログライブラリとは異なり、Serilogは構造化ログデータを念頭に置いて構築されています。ログメッセージとともに渡されるパラメータは、破壊的にテキスト形式にレンダリングされません。代わりに、ドキュメント形式でNoSQLデータストアに書き込むことができる構造化データとして保存されます