ククログ

株式会社クリアコード > ククログ > Fluentd v1.19.0 リリース - 運用コスト削減

Fluentd v1.19.0 リリース - 運用コスト削減

2025年7月30日にFluentdの最新版となるv1.19.0をリリースしました。

本リリースでは、多くの機能追加や不具合修正をしています。 特に、運用コストとランニングコスト削減に効果のある機能や安定性向上の強化を複数実施しています。

本記事では、Fluentd開発者が最新のリリース内容を紹介します。

主な新機能と改善

Fluentd v1.19.0では、運用コストとランニングコスト削減のための機能改善を多数実施しています。 主要な改善は次のとおりです。

  • 対障害性の向上、およびリカバリーの簡易化
    • リトライ超過時のバッファー退避に対応
      • リトライ超過したデータを自動退避しておき、後からFluentdに簡単に再送させられるようになりました。
    • バッファー破損検出の強化
      • 強制システム停止によってバッファーファイルが破損しても、破損ファイルを自動退避して安全に起動しやすくなりました。
    • メトリクスの充実
      • in_tailの追跡ファイル数など、Fluentdの正常稼働の監視に役立つメトリクスを複数追加しました。
  • パフォーマンス改善
    • Zstandard (zstd)圧縮形式をサポート
      • 従来のgzip圧縮と比べて、ディスク使用量の削減や転送速度の向上が期待できます。
    • その他のパフォーマンス改善
      • その他にも多くのパフォーマンス改善を実施し、処理速度やメモリー消費が改善しました。

以下、それぞれ解説します。

リトライ超過時のバッファー退避に対応

今回のリリースでは、buf_fileおよびbuf_file_singleプラグインにバッファー退避機能を追加しました。 この機能を利用することで、障害後のリカバリーが簡単になります。

ネットワーク障害などでOutputプラグインが出力に失敗すると、Fluentdはある程度リトライを試みます。 セカンダリー設定をしない場合、リトライが上限に達すると以前のバージョンではデータを破棄してしまっていましたが、 本バージョンから自動的にバッファーファイルを退避するようになりました。 障害が解消された後、退避されたバッファーファイルを元のバッファーディレクトリに戻してFluentdをリスタートすると、そのデータの送信を再開できます。

退避先は次のとおりです。

${rootディレクトリ}/buffer/${プラグインID}/

rootディレクトリは、system設定のroot_dirパラメーターで設定できます。 デフォルト値は/tmp/fluent/です。

リスタートについては、ゼロダウンタイム・リスタート機能を利用することで、in_udpプラグインなどにダウンタイムを生じさせずにリスタートできます。 ゼロダウンタイム・リスタート機能については、別記事「Fluent Package v5.2.0 リリース - ゼロダウンタイム・アップデート」で詳しく紹介しているので、ぜひご覧ください。

なお、セカンダリー設定またはretry_forever設定をしている場合は、本機能は発動しません。 本機能を使いたい場合は、これらの設定を削除してください。

公式ドキュメントは次になります。

セカンダリー設定との使い分け

障害時のデータ破棄を防ぐ方法として、本バージョン以降は、セカンダリー設定を使わずに新しいバッファー退避機能を使う、という選択肢が生まれるわけですが、どのように使い分けるのが適切でしょうか?

結論としては、障害回復後に再度Fluentdに送信させたい場合は、セカンダリー設定ではなくて新しい自動バッファー退避機能を使う方が、リカバリーが簡単で好ましいです。

セカンダリー設定の利点は、送信に失敗するデータの退避方法を柔軟に設定できるところにあります。 一方で、セカンダリー設定の欠点として、Fluentdにデータを入れ直して再送信させることが難しい、という点があります。 つまり、リカバリーが難しいということです。

この問題は、セカンダリー設定を使わずに新しいバッファー退避機能を使うことで解決できます。

バッファー破損検出の強化

システム障害や電源断などによって保存中のバッファーファイルが破損する場合があります。 Fluentdは起動時に破損したバッファーファイルを自動検出して退避しますが、検出できないケースもありました。 検出できない場合には、次の問題がありました。

  • ユーザーが手動で破損データの範囲を特定する必要がある
  • Fluentdが破損データを無理に処理してしまう
    • 想定外のエラーを招きうる
    • 破損に気付かないまま送信完了してしまう

本リリースでは自動検出機能を強化し、従来検出できなかったパターンも検出して、より安全に起動できるようになりました。

メトリクスの充実

Fluentdの正常稼働の監視がしやすくなるよう、メトリクス機能を強化しました。

  • Inputプラグインのメトリクス取得を有効化
    • 従来はenable_input_metricstrueに変更する必要がありましたが、本バージョンからはデフォルトで取得します。メトリクスを無効化したい場合はenable_input_metrics falseと設定してください。
  • in_tailプラグインに新規メトリクスを追加
    • tracked_file_count: ログ収集中のファイル数を示します。
  • outputプラグインに新規メトリクスを追加
    • write_secondary_count: セカンダリーに出力されたレコードの累計数を示します。
    • drop_oldest_chunk_count: バッファーのoverflow_actiondrop_oldest_chunkに設定した場合、破棄されたチャンクの累計数を示します。

これらの改善により、一部のログファイルの収集停止や送信できなかったデータの発生などを検出しやすくなり、正常稼働の監視がしやすくなりました。

パフォーマンス改善

Zstandard (zstd)圧縮形式をサポート

高圧縮かつ高速なZstandard (zstd)圧縮形式のサポートを追加しました。これにより、従来のgzip圧縮と比べて、ディスク使用量の削減や転送速度の向上が期待できます。

  • 次のプラグインで、compressパラメーターにzstdを指定可能になりました。
  • in_forwardプラグイン: zstd圧縮形式データの受信に対応しました。

※注: out_forwardについては、転送先サーバーもzstd圧縮をサポートしている必要がある点に注意が必要です。 Fluent Bitや、v1.19.0よりも前のバージョンのFluentdに転送する場合は、使うことができません。

その他のパフォーマンス改善

次のように多くのパフォーマンス改善を実施し、処理速度やメモリー消費が改善しました。

特に「JSON処理のパフォーマンス改善」については、JSON形式のバッファーファイルやparser_jsonプラグインなどで、従来のバージョンでは高速なJSON処理のために yajl-ruby を使用していました。 しかし近年、Ruby 本体に標準添付されている jsonライブラリのパフォーマンスが大幅に向上したことを受け、今後はjson gemを標準として使用するように変更しました。

その他の有用な改善

  • in_forwardプラグイン
    • skip_invalid_eventをデフォルトで有効化し破損データをスキップするようにしました。
  • out_stdoutプラグイン
    • use_loggerパラメーターを追加しました。
    • use_logger falseと設定することで、Fluentdの動作ログ出力先(-o起動オプションなど)に依らずに、常に標準出力に出力させられるようになりました。
    • Kubernetesなどのコンテナー環境で、標準出力にデータを出力したい場合に利用できます。
  • out_fileプラグイン
  • out_httpプラグイン
    • tls_versionでTLS 1.3をサポートし、よりセキュアな通信が可能になりました。
  • system設定
    • スタックトレースのログレベルを強制するforced_stacktrace_levelパラメーターを追加しました。

主な不具合修正

formatter_csvプラグインのメモリリークを修正

パフォーマンス改善のためにformatter_csvプラグインでキャッシュが導入されていましたが、不適切にスレッドをキャッシュしていました。in_execプラグインではログを取り込むたびにスレッドを生成しているのですが、formatter_csvプラグインと組み合わせて利用すると、すべてのスレッドがformatter_csvプラグインでキャッシュされ、メモリリークを引き起こしていました。

この修正は Fluentd v1.16.8 にバックポートされています。

in_tailプラグイン: encodingオプション使用時の不具合を修正

in_tailプラグインでは、文字エンコーディングの設定としてencodingfrom_encodingがあります。

本来の想定された使い方は以下の通りです:

  • encodingのみを設定: エンコーディング情報の指定
  • from_encodingencodingの両方を設定: エンコーディングの変換

Fluentd v0.14.12 (少なくとも td-agent v3 以降)から存在していたバグにより、encodingのみを設定した場合でも、 意図しないエンコーディング変換が行われ、ログデータを破損する可能性がありました。 本リリースでこの不具合が修正され、想定通りの動作となりました。

従来バージョンでの回避策について

従来のバージョンでエンコーディング情報の指定のみを行いたい場合は、encodingfrom_encodingの双方に同じエンコードを指定する必要があります。 この際、意味のない設定である旨の警告ログが発生しますが、実際には効果がありますので、無視してください。

'encoding' and 'from_encoding' are same encoding. No effect

また、fluent-plugin-record-modifierなどの他のFilterプラグインを使って、エンコーディング情報の指定を行うことも可能です。

Windows: Supervisorプロセスが停止したときに、サービスが停止しない不具合を修正

設定エラーなどでSupervisorプロセスが停止した際に、 サービスが実行され続ける不具合を修正しました。サービスが正しく停止するようになり、設定エラー時の異常検知が容易になりました。

この修正は Fluentd v1.16.8 にバックポートされています。

--umaskの不具合を修正

--daemon--umask起動オプション使用時にumaskの設定値が正しく反映されず、 ファイルが意図と異なるパーミッションで生成される不具合を修正しました。

関連リンク

まとめ

Fluentd v1.19.0は、圧縮形式の強化(Zstandard対応)、バッファーの信頼性向上、メトリクスやパフォーマンスの改善など、 多岐にわたる機能追加と不具合修正が含まれた重要なリリースです。

とくにリトライ超過時のバッファー退避機能の追加やバッファー破損検出の強化により、 障害時のログ損失リスクが大きく低減され、より堅牢な運用が可能になりました。

Fluentd を安全かつ効率的に運用するためにも、本バージョンへのアップデートをご検討ください。

クリアコードはFluentdのサポートサービスやプラグイン開発を行っています。 td-agentやFluent Packageのアップデートについてもサポートいたしますので、詳しくはFluentdのサポートサービスをご覧いただき、お問い合わせフォームよりお気軽にお問い合わせください。

日本コミュニティ向けのXアカウントでは、日々、Fluentdに関する情報を発信しております。 ぜひ @fluentd_jp をフォローしてください!