ローリングファイルアペンダーのガイド
1. 概要
ログファイルは多くの場合、有用な情報を伝達しますが、時間の経過とともに自然に大きくなり、無期限に大きくなると、サイズが問題になる可能性があります。
ロギングライブラリは、特定の事前定義された条件が発生したときにrolling file appenders, which automatically “roll” or archive the current log file and resume logging in a new fileを使用してこの問題に対処し、それによって不要なダウンタイムを防ぎます。
この記事では、Log4j、Log4j2、Slf4jなど、最も広く使用されているロギングライブラリのいくつかでローリングファイルアペンダーを構成する方法を検討します。
サイズ、日付/時刻、およびサイズと日付/時刻の組み合わせに基づいてログファイルをロールする方法を示します。 また、古いログファイルを自動的に圧縮して後で削除するように各ライブラリを構成する方法を示し、面倒なハウスキーピングコードを記述しないようにします。
2. サンプルアプリケーション
いくつかのメッセージをログに記録するサンプルアプリケーションから始めましょう。 このコードはLog4jに基づいていますが、Log4j2またはSlf4jで動作するように簡単に変更できます。
import org.apache.log4j.Logger;
public class Log4jRollingExample {
private static Logger logger = Logger.getLogger(Log4jRollingExample.class);
public static void main(String[] args) throws InterruptedException {
for(int i = 0; i < 2000; i++) {
logger.info("This is the " + i + " time I say 'Hello World'.");
Thread.sleep(100);
}
}
}このアプリケーションは非常に単純です。ループ内にいくつかのメッセージを書き込み、反復間の短い遅延があります。 実行する2,000のループと各ループで100ミリ秒の一時停止により、アプリケーションの完了には3分強かかります。
このサンプルを使用して、さまざまな種類のローリングファイルアペンダーのいくつかの機能を示します。
3. Log4jのローリングファイルアペンダー
3.1. Mavenの依存関係
まず、アプリケーションでLog4jを使用するには、この依存関係をプロジェクトのpom.xmlファイルに追加します。
log4j
log4j
1.2.17
次の例で使用するapache-log-extrasによって提供される追加のアペンダーを使用するには、次の依存関係を追加します。完全な互換性を確保するために、Log4jに対して宣言したものと同じバージョンを使用してください。
log4j
apache-log4j-extras
1.2.17
Log4jとApache Log4j Extrasの最新リリースはMavenCentralにあります。
3.2. ファイルサイズに基づくローリング
Log4jでは、他のロギングライブラリと同様に、ファイルのローリングはアペンダーに委任されます。 ファイルサイズに基づいてローリングするLog4jのローリングファイルアペンダーの構成を見てみましょう。
ここでは、MaxFileSizeパラメータを使用して、サイズが5KBに達したときにログファイルをロールするようにLog4jを構成しました。 また、MaxBackupIndexパラメータを使用して、最大2つのロールログファイルを保持するようにLog4jに指示しました。
サンプルアプリケーションを実行すると、次のファイルが取得されました。
27/11/2016 10:28 138 app.log
27/11/2016 10:28 5.281 app.log.1
27/11/2016 10:28 5.281 app.log.2何が起こった？ Log4jはapp.logファイルへの書き込みを開始しました。 ファイルサイズが5KBの制限を超えると、Log4jはapp.logをapp.log.1に移動し、新しい空のapp.logを作成し、新しいログメッセージをapp.logに書き込み続けました。
次に、新しいapp.logが5KBの制限を超えた後、このローリングプロセスが繰り返されました。 今回は、app.log.1がapp.log.2,に移動され、別の新しい空のapp.log用のスペースが確保されました。
ローリングプロセスは実行中に数回繰り返されましたが、最大2つのローリングされたファイルを保持するようにアペンダーを構成したため、app.log.3というファイルはありません。
生成されたログファイルのサイズに制限を設定できるようになったため、元の問題の1つを解決しました。
一方、app.log.2の最初の行を確認すると、700回目の反復に関連するメッセージが含まれていました。つまり、以前のすべてのログメッセージが失われていました。
2016-11-27 10:28:34 INFO This is the 700 time I say 'Hello World'.ログメッセージを失うことが最善のアプローチとは見なされない本番環境により適したセットアップを考え出すことができるかどうかを見てみましょう。
そのために、apache-log4j-extrasと呼ばれる専用パッケージで出荷される他のより強力で柔軟で構成可能なLog4jアペンダーを使用します。
このアーティファクトに含まれるアペンダーは、ログローリングを微調整するための多くのオプションを提供し、triggering policyとrolling policyの異なる概念を導入します。 triggering policyはロールが発生するタイミングを示し、rolling policyはロールの実行方法を示します。 これら2つの概念は、ログファイルをローリングするための鍵であり、すぐにわかるように、他のライブラリでも多少明示的に使用されます。
3.3. 自動圧縮によるローリング
Log4jの例に戻り、ロールされたファイルの自動圧縮を追加してスペースを節約することにより、セットアップを改善しましょう。
triggering policy要素を使用して、ログが5,120バイトのサイズを超えたときにロールが発生する必要があることを示しました。
rolling policyタグ,内で、ActiveFileNameパラメータは最新のメッセージを含むメインログファイルのパスを示し、FileNamePatternパラメータはパスを説明するテンプレートを指定します。ロールされたファイル。 特別なプレースホルダー%iがロールされたファイルのインデックスに置き換えられるため、これは確かにパターンであることに注意してください。
また、FileNamePatternは「.gz”拡張子」で終わることに注意してください。 サポートされている圧縮形式に関連付けられた拡張機能を使用する場合は常に、私たちの側から余計な労力をかけることなく、古いロールファイルを圧縮します。
アプリケーションを実行すると、異なるログファイルのセットが取得されます。
03/12/2016 19:24 88 app.1.log.gz
...
03/12/2016 19:26 88 app.2.log.gz
03/12/2016 19:26 88 app.3.log.gz
03/12/2016 19:27 70 app.current.logファイルapp.current.logは、最後のログが発生した場所です。 以前のログは、サイズが設定された制限に達したときにロールおよび圧縮されています。
3.4. 日付と時刻に基づくローリング
他のシナリオでは、ファイルのサイズではなくログメッセージの日付と時刻に基づいてファイルをロールするようにLog4jを構成することができます。 たとえば、Webアプリケーションでは、1日ですべてのログメッセージを同じログファイルに発行したい場合があります。
これを行うには、TimeBasedRollingPolicyを使用できます。 このポリシーでは、時間関連のプレースホルダーを含むログファイルのパスのテンプレートを指定することが必須です。 ログメッセージが発行されるたびに、アペンダーは結果のログパスがどうなるかを確認し、最後に使用したパスと異なる場合はロールが発生します。 このようなアペンダーを構成する簡単な例を次に示します。
3.5. サイズと時間に基づくローリング
SizeBasedTriggeringPolicyとTimeBasedRollingPolicy,を組み合わせると、日付/時刻に基づいてロールするアペンダーを取得できます。ファイルのサイズが設定された制限に達すると、サイズにも基づいてロールします。
このセットアップでアプリケーションを実行すると、次のログファイルが取得されました。
03/12/2016 19:25 234 app.19-25.1481393432120.log.gz
03/12/2016 19:25 234 app.19-25.1481393438939.log.gz
03/12/2016 19:26 244 app.19-26.1481393441940.log.gz
03/12/2016 19:26 240 app.19-26.1481393449152.log.gz
03/12/2016 19:26 3.528 app.19-26.1481393470902.logファイルapp.19-26.1481393470902.logは、現在のロギングが行われる場所です。 ご覧のとおり、19：25から19:26までの間隔のすべてのログは、「app.19-25″.」で始まる名前の複数の圧縮ログファイルに保存されます。“%i”プレースホルダーは、増え続ける数値に置き換えられます。 。
4. Log4j2のローリングファイルアペンダー
4.1. Mavenの依存関係
Log4j2を優先ロギングライブラリとして使用するには、次の依存関係でプロジェクトのPOMを更新する必要があります。
org.apache.logging.log4j
log4j-core
2.7
いつものように、latest versionはMavenCentralにあります。
4.2. ファイルサイズに基づくローリング
Log4j2ログライブラリを使用するようにサンプルアプリケーションを変更し、log4j2.xml構成ファイルのログファイルのサイズに基づいてファイルローリングを設定する方法を見てみましょう。
%d{yyyy-MM-dd HH:mm:ss} %p %m%n
Policiesタグで、適用するすべてのトリガーポリシーを指定しました。 OnStartupTriggeringPolicyは、アプリケーションが起動するたびにロールをトリガーします。これは、スタンドアロンアプリケーションに役立つ可能性があります。 次に、ログファイルが5KBに達するたびにロールが発生することを示すSizeBasedTriggeringPolicyを指定しました。
4.3. 日付と時刻に基づくローリング
Log4j2が提供するポリシーを使用して、時間に基づいてログファイルをロールおよび圧縮するアペンダーを設定しましょう。
%d{yyyy-MM-dd HH:mm:ss} %p %m%n
ここで重要なのは、ロールされたファイル名のテンプレートで時間に関連するプレースホルダーを使用できるようにするTimeBasedTriggeringPolicyの使用です。 必要なトリガーポリシーは1つだけなので、前の例のようにPoliciesタグを使用する必要がないことに注意してください。
4.4. サイズと時間に基づくローリング
前述したように、より魅力的なシナリオは、時間とサイズの両方に基づいてログファイルをロールおよび圧縮することです。 このタスク用にLog4j2を設定する方法の例を次に示します。
%d{yyyy-MM-dd HH:mm:ss} %p %m%n
この構成では、時間とサイズに基づいてロールを行う必要があると述べました。 アペンダーは、ファイル名「app.%d{MM-dd-yyyy-HH-mm}.%i.log.gz”」に使用されるパターンにより、参照している時間間隔を理解できます。これは、毎分発生するロールを暗黙的に設定し、ロールされたファイルを圧縮します。
また、特定の条件に一致する古いロールファイルを削除するためにDefaultRolloverStrategyを追加しました。 20日以上経過した場合、指定されたパターンに一致するファイルを削除するように設定します。
4.5. Mavenの依存関係
Log4j2を優先ロギングライブラリとして使用するには、次の依存関係でプロジェクトのPOMを更新する必要があります。
org.apache.logging.log4j
log4j-core
2.7
いつものように、latest versionはMavenCentralにあります。
5. Slf4jのローリングファイルアペンダー
5.1. Mavenの依存関係
ログバックバックエンドでSlf4j2をログライブラリとして使用する場合は、次の依存関係をpom.xmlに追加します。
ch.qos.logback
logback-classic
1.1.7
いつものように、latest versionはMavenCentralにあります。
5.2. ファイルサイズに基づくローリング
代わりに、デフォルトのバックエンドLogbackでSlf4jを使用する方法を見てみましょう。 アプリケーションのクラスパスに配置されている構成ファイルlogback.xmlでファイルローリングを設定する方法を見てみましょう。
target/slf4j/roll-by-size/app.log
target/slf4j/roll-by-size/app.%i.log.zip
1
3
1MB
5KB
%-4relative [%thread] %-5level %logger{35} - %msg%n
繰り返しますが、ローリングポリシーの概念に遭遇します。 基本的なメカニズムは、Log4jおよびLog4j2で使用されるメカニズムと同じです。 FixedWindowRollingPolicyを使用すると、ロールされたファイルの名前パターンでインデックスプレースホルダーを使用できます。
ログファイルのサイズが設定された制限を超えると、新しいファイルが割り当てられ、リストの最初のファイルとして古いコンテンツが保存され、既存のファイルがさらに1桁移動します。
5.3. 時間に基づくローリング
Slf4jでは、提供されたTimeBasedRollingPolicyを使用して、時間に基づいてログファイルをロールできます。 このポリシーにより、日時に関連するプレースホルダーを使用してローリングファイルのテンプレート名を指定できます。
target/slf4j/roll-by-time/app.log
target/slf4j/roll-by-time/app.%d{yyyy-MM-dd-HH-mm}.log.zip
20
1MB
%d{yyyy-MM-dd HH:mm:ss} %p %m%n
5.4. サイズと時間に基づくローリング
時間とサイズの両方に基づいてファイルをロールする必要がある場合は、提供されているSizeAndTimeBasedRollingPolicyを使用できます。 このポリシーを使用する場合、時間関連のプレースホルダーとインデックスプレースホルダーの両方を指定する必要があります。
特定の時間間隔のログファイルのサイズが構成されたサイズ制限を超えるたびに、時間に関連するプレースホルダーの値は同じであるがインデックスが増分された別のログファイルが作成されます。
target/slf4j/roll-by-time-and-size/app.log
target/slf4j/roll-by-time-and-size/app.%d{yyyy-MM-dd-mm}.%i.log.zip
5KB
20
1MB
%d{yyyy-MM-dd HH:mm:ss} %p %m%n
6. 結論
既に説明したように、ログライブラリを使用してファイルをロールすることにより、ログファイルを手動で管理する負担が軽減され、ビジネスロジックの開発に集中できます。 ローリングファイルアペンダーは、すべての開発者のツールボックスに含まれている必要がある貴重なツールです。
いつものように、ソースon GitHubがあります。この記事で紹介するサンプルアプリケーションは、いくつかの異なるローリングセットアップを使用してログに記録するように構成されており、適切な基本構成を見つけて、自分に合わせてさらに調整することができます。ニーズ。