ロギングとトレースを区別する必要があります。行は少しあいまいですが、私はロギングを「開発者以外のもの」と考える傾向があります。未処理の例外、破損したファイルなど。これらは間違いなく正常ではなく、非常にまれな問題であるはずです。
トレースは、開発者が関心を持っているものです。スタックトレース、メソッドパラメータ、Webサーバーが401.3のHTTPステータスを返したことなど。これらは非常にノイズが多く、短時間で大量のデータを生成できます。通常、ノイズを削減するために、さまざまなレベルのトレースがあります。
クライアントアプリにログインするには、イベントログを使用する方法だと思います（再確認する必要がありますが、ASP.NET Health Monitoringでもイベントログに書き込むことができると思います）。通常のユーザーには、セットアップ（とにかく管理者によってインストールされます）がイベントソースを作成している限り、イベントログに書き込む権限があります。
SQLロギングの利点のほとんどは、本当ですが、イベントロギングには適用できません。
- 大量のデータを処理できます：
処理されていない例外やその他の高レベルの障害が本当に大量にありますか？
- 例外の急速なボリューム挿入を処理できます：単一の未処理の例外はアプリをダウンさせる必要があります-それは本質的にレート制限されています。開発者以外の人にとって他の興味深いイベントも同様に集約する必要があります。
- 非常にカスタマイズ可能：イベントログのメッセージはほとんどフリーテキストです。さらに情報が必要な場合は、テキスト、構造化XML、またはバイナリファイルログを指定するだけです。
- SQLストレージからレポート/通知を作成するのが少し簡単：レポートはイベントログビューアに組み込まれており、通知システムは、アプリケーションのクラッシュが原因で固有のものであるか、他の非常に重要な通知と混合されているため、言い訳はほとんどありません。イベントログメッセージがありません。企業またはその他のネットワーク化されたアプリの場合、エラーのイベントログからすでにカリングされている1,000と1の異なるアプリがあります...システム管理者がすでに1つを使用している可能性があります。
例外やエラーの特定の詳細が含まれているトレースについては、フラットファイルが好きです。フラットファイルは、保守が簡単で、grepが簡単で、必要に応じてSQLにインポートして分析できます。
90％の場合、それらは必要なく、WARNまたはERRORに設定されています。ただし、それらをINFOまたはDEBUGに設定すると、大量のデータが生成されます。RDBMSには、パフォーマンス（ACID、同時実行性など）、ストレージ（トランザクションログ、SCSI RAID-5ドライブなど）、および管理（バックアップ、サーバーメンテナンスなど）など、多くのオーバーヘッドがあります。トレースログには不要です。