テキストファイルまたはデータベースにログインしますか？

いつログにデータベースを使用し、テキストファイルを使用する必要がありますか？
WebサーバーとWebフレームワーク（アプリが内部で使用するもの）は、通常（常に？）要求とエラーをデフォルトでテキストファイルに記録します。しかし、これらのサーバーやフレームワークを中心にアプリを開発する人々は、データベースにログインすることがあります（外部のアプリではなく、アプリのメインDBでも）。
また、デバッグログと監査ログには違いがあるかもしれません-私はこのサイトのどこかでこの分類を読みました。

非常に一般的な用語では、テキストファイルへのログ記録はデータベースへのログ記録よりもはるかに高速です。これが、考慮する必要があるロギングの主な側面です。

DBにログを記録する理由は、結果を照会したいためです-特に、ログエントリをグループ化するために使用できるコンテキスト情報をログに記録する場合、DBで特定のログ情報を検索する方が簡単です。また、通常、セキュリティで保護されていてアクセスできないサーバー上のログファイルよりも中央のDBにアクセスする方が簡単です。

理想は、ローカルでファイルにログを記録し、その後、必要に応じて検査のためにこのデータをDBに移行することです。

現在、監査はまったく別の獣です。概念はロギングと似ていますが、監査は通常、長時間保持する必要があります（デバッグやトレースに使用されるログファイルは気まぐれに削除される可能性があります）。監査は重要な情報を示すためにあります。記録する監査情報は通常のログよりもはるかに少なく、頻度も少ないため、パフォーマンスは問題になりません。このため、この監査情報を中央DBに書き込む利点が見られます。

すべてのアプローチに適合するサイズはありません。復元力のために、複数のアプローチを使用することがあります。たとえば、デバッグログをファイルに隠し、監査ログをDBに保存することができます。

アプリケーションのパンくずリスト

長所：実装が簡単で、すぐにユーザーに見える

短所：情報はアプリケーションが起動している間のみ持続します

テキストファイル

長所：実装が簡単

短所：ファイルのロックが発生しないようにする必要があります。ログドライブのディスク領域が不足した場合の対処方法

イベントログ

長所：実装が簡単

短所：正しく設定されていない場合、または保持ポリシー/クリアダウンにより古いログが失われる可能性がある場合、イベントログがいっぱいになる可能性があります。

データベース

長所：実装が簡単

短所：より多くのDBトラフィック。DBの損失または他のDBの問題を記録する方法は？

メッセージング（MQ）

長所：発射して忘れる

短所：別のレイヤーがうまくいかない。セットアップが必要

監査ログは、データベースの内容を完全に正当化することを目的として、監査目的で長時間にわたって操作の完全なトレーサビリティを確保する必要があります。

いくつかの場合（金融アプリケーションなど）、これらのログは、保持（一部の国では10年間）や変更不可などの法的要件への準拠を保証する必要があります。これらのログはアプリケーションレベルでdbの内容を正当化する必要があるため、dbに保存するのが一般的な方法です。dbでアクセスを制御し、不正な変更を回避できます。

監視ログやセキュリティログなどの他のログは、パフォーマンスとボリュームの制約に対処する必要が頻繁にあります。これらは一般にファイルに書き込まれます。これは、書き込みが高速（トランザクション管理のオーバーヘッドなし）でオフラインでのアーカイブが容易であり、外部監視SIEMツールとの統合が容易だからです。

これらの種類のログは監査ログの信頼性を示すために使用できますが（たとえば、不正アクセスがない）、一般的に保持期間が短くなります（たとえば、通信ログの法執行目的で6か月から2年）制約がある場合。

デバッグロギングにdbを使用する多くの理由の1つは、イベントビューアーまたはテキストファイルを表示するためにアプリケーションまたはWebサーバーにアクセスできない場合です。

監査ログは異なり、Webアプリケーションのコンテキストでデバッグログがあります。一部のアプリケーションでは、簡単に取得できるようにデータベースにアクセスする必要があるため、エンドユーザーに表示する必要がある場合があります。

DBツールを使用して、フィルタリングと簡単な表示を行うこともできます。