テキストファイルまたはデータベースにログインしますか？
いつデータベースをログに使用し、いつテキストファイルを使用すればよいですか？
通常、（常に？）WebサーバーとWebフレームワーク（アプリが内部で使用する）は、デフォルトで要求とエラーをテキストファイルに記録します。しかし、これらのサーバーとフレームワークを中心にアプリを開発している人は、データベースにログインすることがあります（外部DBではなく、アプリのメインDBでさえも）。
また、debug logsとaudit logsの間に違いがあるかもしれません-この分類をこのサイトのどこかで読みました。
一般的に、テキストファイルへのロギングは、データベースへのロギングよりもはるかに高速です。これが、考慮する必要があるロギングの主な側面です。
DBにログを記録する理由は、結果をクエリする必要があるためです。特に、ログエントリをグループ化するために使用できるコンテキスト情報をログに記録すると、特定のログ情報の検索がより簡単になります。中央のDBにアクセスする方が、安全でアクセスできないサーバー上のログファイルよりも通常は簡単です。
ローカルでファイルにログを記録し、後で必要に応じて検査のためにこのデータをDBに移行するのが理想的です。
現在、監査はまったく別の獣です。ロギングの概念は似ていますが、監査は通常、長期間保持する必要があります（デバッグやトレースに使用されるログファイルが気まぐれに削除される場合とは異なります）。監査は重要な情報を示すためにあります。監査情報を記録する頻度は通常より少なく、パフォーマンスは問題になりません。このため、この監査情報を中央のDBに書き込むことの利点が見られます。
すべてのアプローチに適合する1つのサイズはありません。回復力のために、複数のアプローチを使用したい場合があります。例として、デバッグログをファイルに保存し、監査ログをDBに保存することができます。
アプリケーションブレッドクラム
長所：実装が簡単で、すぐにユーザーに表示
短所：情報は、アプリケーションが起動している間のみ保持されます
テキストファイル
長所：実装が簡単
短所：ファイルロックが発生しないようにする必要があります。ログドライブでディスク領域が不足した場合はどうすればよいですか？
イベントログ
長所：実装が簡単
短所：正しく設定されていないと、イベントログがいっぱいになるか、保持ポリシー/クリアダウンが原因で古いログが失われる可能性があります。
データベース
長所：実装が簡単
短所：DBトラフィックが増える。 DBの損失またはその他のDBの問題を記録する方法
メッセージング（MQ）
長所：火を忘れて
短所：もう1つレイヤーが間違っているセットアップが必要
監査ログは、データベースのコンテンツを完全に正当化することを目的として、監査目的で長時間にわたる操作の完全な追跡可能性を保証する必要があります。
場合によっては（財務アプリケーションなど）、これらのログは、保持（一部の国では10年間）や改ざん不能などの法的要件の遵守を保証する必要がある場合があります。これらのログはアプリケーションレベルでdbの内容を正当化する必要があるため、不正な変更を防ぐためにアクセスを制御できるdbに保存するのが一般的です。
監視ログやセキュリティログなどの他のログは、パフォーマンスとボリュームの制約に対処する必要があります。オフラインでアーカイブする方が簡単で（トランザクション管理オーバーヘッドなし）、外部モニタリングと統合しやすい [〜＃〜] siem [〜＃〜] ツール。
これらの種類のログは、監査ログの信頼性を実証するために使用できますが（たとえば、不正アクセスがないこと）、それらは一般に保持制限が短いことに注意してください（たとえば、通信ログの法執行目的で6か月から2年）。制約がある場合。
デバッグログにdbを使用する多くの理由の1つは、イベントビューアまたはテキストファイルを表示するためのアプリケーションまたはWebサーバーにアクセスできない場合です。
監査ログは、Webアプリケーションのコンテキストではデバッグログとは異なります。一部のアプリケーションでは、簡単に取得できるようにデータベースにアクセスできるように、エンドユーザーに監査ログを表示する必要がある場合があります。
DBツールを使用して、フィルタリングや簡単な表示もできます。