再試行限度

デフォルトでは、 ロギング・エージェント、エラーが発生した場合、成功するまでログの送信を再試行し続けるように設定されている。 デフォルトの動作は retryLimit: false パラメータで設定されます。 Kubernetes、これは ロギング・エージェント コンフィグマップで管理され、 Linux 環境では ロギング・エージェント コンフィグファイルで管理される。

デフォルトの retryLimit の値を変更すると、データが落ちる可能性があります。 例えば、 retryLimit: "no_retries" は、 ロギング・エージェント がエラー発生時にログの送信を全く再試行しないことを示す。 例えば、 retryLimit: 8 のように整数値を指定すると、 ロギング・エージェント は、ログが削除される前に、指定された回数（8回）のログ送信を再試行することを示す。

Fluent Bit が再試行間隔をスケジュールする方法については、 スケジューリングと再試行を参照してください

フルエント・ビット・バッファリング

ロギング・エージェント はデフォルトでFluent Bit filesystem バッファリングを使用するように設定されている。 この構成は、システム障害に備えて、 ロギング・エージェント によって処理されたログがファイルストレージに保管されることを意味する。 ロギング・エージェント が再起動すると、 filesystem バッファ内のログが処理される。

memory バッファリングを使用するように設定を変更した場合、 ロギング・エージェント が終了したり、予期せず終了したりする問題が発生すると、 memory バッファ内のログがドロップされることがあります。

詳細は バッファリングとストレージを参照。

ログローテーション

ロギング・エージェント がログファイルを処理する前に、環境がログファイルをローテートする場合、ログがドロップされる可能性がある。 ログローテーションによるデータの欠落は、 ロギング・エージェント の実行がかなりの時間停止した場合に発生する可能性があります。

Kubernetes

IBM 管理クラスタでは、 /var/log/containers の stdout コンテナ・ログ・ファイルはすべて kublet によって管理される。 各コンテナ・ログ・ファイルは、サイズが 100MiB に達するとローテートされる。 ローテーション後、コンテナごとに最大3つのログファイルが保持される。 これらのファイルのサイズや数は設定できない。

ロギング・エージェント、データを処理する前にログファイルがいっぱいになり、回転してしまった場合、未処理のログを削除することができる。

Linux

ログローテーション処理は Linux で設定できる。 例えば、 logrotate。

ロギング・エージェント、データを処理する前にログファイルがいっぱいになり、回転してしまった場合、未処理のログを削除することができる。

Windows

ログローテーション処理はWindowsで設定できる。 しかし、ログローテーションのためのWindows組み込みツールは存在しない。 サードパーティのアプリケーション、または組み込みのアプリケーション設定を使用して、ログのローテーションを設定することができます。

ロギング・エージェント、データを処理する前にログファイルがいっぱいになり、回転してしまった場合、未処理のログを削除することができる。