私が取り組んできたすべてのプロジェクトで、ログ ファイルが大きくなりすぎるという問題が常にありました。RollingFileAppenderLog4j を使用して、許可されている最大サイズを設定することは、既製の簡単な解決策でした。ただし、誰かが手動で介入する前に、同じ例外が繰り返し発生し、非常に迅速に最大サイズに達する状況があります。このシナリオでは、ローリング ポリシーが原因で、例外の直前に発生した重要なイベントの情報が失われることになります。誰でもこの問題の修正を提案できますか?
PS私が考えることができるのは、Exceptionsこれまでに発生したキャッシュを保持することです。これにより、同じ例外が再発生したときに、大量のスタックトレース行をログに記録しません。それでも、これはよく知られた問題だと思いますし、車輪の再発明はしたくありません。
Log4J 機能を使用して、「Rolling File Appender」を使用して指定したサイズに達した後にログ ファイルを圧縮します。zip は、1 MB のファイルで約 85 KB です。これには、サイズに基づいて圧縮するトリガー ポリシーを指定し、ローリング ポリシーで zip ファイルを指定します。
情報が必要な場合はお知らせください。
私の経験では、ロギングはコードの適切なテストとデバッグの代わりとして使用されます。プログラマーは、「このコードが機能するかどうか確信が持てないので、ログ メッセージを散りばめて、失敗したときにログ メッセージを使用して問題の原因を突き止めることができる」と考えています。
何も考えずにログ メッセージをばらまくのではなく、各ログ メッセージをソフトウェアのユーザー インターフェイスの一部と考えてください。DBA、ウェブマスター、またはシステム管理者向けのユーザー インターフェイスですが、それでもユーザー インターフェイスの一部です。すべてのメッセージは何か役に立つはずです。メッセージは、行動を促すものであるか、ユーザーが使用できる情報を提供する必要があります。メッセージが役に立たない場合は、ログに記録しないでください。
各メッセージに適切なログ レベルを指定します。メッセージが実際の問題を説明しておらず、有用なステータス情報を提供していない場合、そのメッセージはデバッグにのみ役立つ可能性が高いため、DEBUG または TRACING メッセージとしてマークしてください。通常の Log4J 構成では、これらのメッセージはまったく書き込まれません。問題をデバッグしているときにのみ書き込むように構成を変更します。
メッセージは、頻繁に発生する例外によるものであると述べています。すべての例外がプログラムのバグや、プログラムの操作上の問題を示しているわけではありません。プログラムのバグを示すすべての例外をログに記録し、それらのスタック トレースをログに記録する必要があります。多くの場合、これでバグの原因を突き止めることができます。心配している例外がバグによるものである場合は、間違った問題に焦点を合わせていることになります。つまり、バグを修正する必要があります。例外がプログラムのバグを示していない場合は、スタックトレースをログに記録しないでください。スタックトレースは、問題をデバッグしようとしているプログラマにのみ役立ちます。例外が問題をまったく示さない場合は、ログに記録する必要はまったくありません。
最大サイズに達した場合に戦略を使用し、新しいログ ファイルに追加します。毎日のようにスケジューラを実行して、古いログファイルを消去します