Fluentd v1.20.0 has been released

Hi users!

We released v1.20.0 on October 23, 2026. ChangeLog is here.

Fluentd v1.20.0 is the first release in the v1.20 series. It enables Ruby JIT by default and adds options to limit the size of evacuated buffer files and to discover new log files sooner, along with bug fixes and performance improvements.

Notable changes

Ruby 3.2 is no longer supported

Fluentd now requires Ruby 3.3 or later. Ruby 3.3 is needed to enable Ruby JIT through RubyVM::YJIT.enable.

Ruby JIT is enabled by default

The enable_jit option in the <system> directive now defaults to true. Fluentd enables YJIT in each worker process, and it can improve the throughput.

On the other hand, JIT increases the memory usage of each worker process. If you want to keep the previous behavior, set enable_jit false as follows:

<system>
  enable_jit false
</system>

This option has no effect on Windows, because YJIT is not supported there. In that case, Fluentd just logs Ruby JIT is not available on this Ruby at the info level.

Ref. enable_jit

Fluentd no longer uses yajl-ruby

Fluentd has used the json gem as the default JSON processor since v1.19.0. This release also uses it to parse JSON streams, for example in parser_json with in_exec, and in in_forward and in_unix when they receive JSON. Fluentd itself no longer uses yajl-ruby.

There is one behavior change. When an input stream ends in the middle of a JSON document, Fluentd now logs a warning and discards the incomplete tail instead of raising ParseError. Complete JSON documents received before the truncation are processed as before.

Fluentd now depends on json gem v2.21 or later.

Note for plugin developers: Fluentd still keeps yajl-ruby as a dependency for a while, because some third-party plugins require 'yajl' without declaring it in their gemspec. If your plugin uses yajl-ruby, please add it to the dependencies of your gemspec.

Major new features and improvements

buffer: limit the total size of evacuated chunk files

The new evacuate_limit_size option in the <buffer> section limits the total size of evacuated chunk files.

Fluentd v1.19.0 added a feature to evacuate buffer chunk files when the retry limit is reached. During a long outage, this can happen again and again, and the evacuated files can fill the disk. The new limit also counts the files evacuated before. Chunks that do not fit are discarded without being evacuated.

<match app.**>
  @type forward
  @id forward_app
  <server>
    host 192.168.1.3
  </server>
  <buffer>
    @type file
    path /var/log/fluent/buf
    evacuate_limit_size 1g
  </buffer>
</match>
  • The default is nil (no limit). It keeps the previous v1.19.x behavior.
  • Set 0 to disable evacuation. It is the same as the behavior before v1.19.0.
  • It is an approximate limit. The total size can exceed it, for example when multiple workers of the same plugin evacuate chunks at the same time.
  • We recommend setting @id for the output plugin. Without @id, the evacuation directory can change when the configuration changes, and the files evacuated before are not counted.

Ref. Handling Successive Failures

in_tail: discover new files earlier with directory watching

The new opt-in enable_dir_watcher option lets in_tail discover new files sooner.

in_tail usually finds new files by periodic checks every refresh_interval (60 seconds by default). With this option, in_tail also watches the directories derived from path, and refreshes the file list when they change.

<source>
  @type tail
  path /var/log/myapp/*.log
  pos_file /var/log/fluent/myapp.pos
  tag myapp
  enable_dir_watcher true
  follow_inodes true
  <parse>
    @type none
  </parse>
</source>
  • dir_watcher_limit (default: 100) sets the maximum number of directories watched at once. If there are more candidate directories, in_tail rotates the watched ones at each periodic refresh.
  • Periodic refreshes still run as a fallback.
  • Detection latency depends on the platform and the file system. On Linux, inotify is used where available.
  • Rotated files that match path may also be found earlier. Use follow_inodes true to avoid duplicate collection after rename-based rotation.

Ref. enable_dir_watcher

in_tail: parse lines on worker threads

The new opt-in num_threads option lets in_tail parse lines on worker threads. It can reduce delays in processing other files while a large or fast-growing file is parsed.

The default 1 keeps the previous behavior, which parses lines on the event loop. Set it to 2 or more to enable worker parsing.

<source>
  @type tail
  path /var/log/app/*.log
  pos_file /var/log/fluentd/app.log.pos
  tag app
  num_threads 2
  <parse>
    @type json
  </parse>
</source>
  • It does not guarantee a higher overall throughput. If all worker threads are busy, other files may still wait.
  • The order of the events within a file is preserved.
  • Worker parsing is available with the none, regexp, json, csv, tsv, ltsv, msgpack, apache, apache2, apache_error, nginx and syslog parsers. In other cases, such as multiline parsing or open_on_every_update true, in_tail logs a warning at startup and keeps parsing on the event loop.
  • While worker parsing is active, in_monitor_agent reports worker_pending_batch_count, worker_pending_bytes and worker_parse_error_count.

Ref. num_threads

in_forward: improve interoperability with Fluent Bit v5.0.5 or later

in_forward can now receive events sent by Fluent Bit v5.0.5 or later with its default settings.

Fluent Bit v5.0.5 changed its out_forward plugin to send metadata within each event by default. The timestamp of such an event is encapsulated with the metadata as [EventTime, metadata], as defined in Forward Protocol Specification v1.5. Previous versions of in_forward could not handle this format. With the default skip_invalid_event true, these events were dropped with a skip invalid event warning.

Now in_forward extracts the timestamp and ingests the record. The metadata itself is not processed yet, and it is discarded.

System configuration: add umask option

You can now set the umask of the Fluentd process with the umask option in the <system> directive. Previously, this required the --umask command line option, which is inconvenient for services and container images.

<system>
  umask 0022
</system>

When both are given, the command line option takes precedence.

out_forward: add send_keepalive_packet option

The new send_keepalive_packet option enables TCP keepalive (SO_KEEPALIVE) on out_forward connections. The existing keepalive option only reuses connections and does not send TCP keepalive packets, so dead connections could remain in CLOSE-WAIT state.

send_keepalive_packet is disabled by default, and it requires keepalive true. Otherwise, Fluentd fails to start with a configuration error. in_forward already has a similar option.

<match app.**>
  @type forward
  keepalive true
  send_keepalive_packet true
  <server>
    host 192.168.1.3
  </server>
</match>

in_exec: add command_timeout option

The new command_timeout option limits how long an in_exec command can run. When the command runs longer than this timeout, Fluentd logs child process timed out and kills the process. The default is nil (no timeout).

Without a timeout, a hung command makes in_exec keep logging previous child process is still running. skipped., and it is hard to find the actual cause. out_exec already has the same option.

<source>
  @type exec
  command /path/to/command
  run_interval 10s
  command_timeout 30s
  tag example
  <parse>
    @type json
  </parse>
</source>

Performance improvements

  • parser_csv, parser_tsv and parser_ltsv are faster and allocate fewer objects.
  • Output plugins cache metadata and timekey calculation to reduce object allocations.
  • formatter_out_file is faster.
  • More JSON handling uses the json gem instead of yajl-ruby.
  • On Windows, in_tail reads files in 64KB blocks instead of 8KB, and EventTime.now is faster.

Other improvements

  • parser_syslog: accept one space between the RFC3164 priority and the header. Some syslog senders emit records in this format.
  • fluent-plugin-generate: add a .gitignore file to the generated plugin template.
  • The gem for Windows on Arm (aarch64-mingw-ucrt) is now available.

Major bug fixes

in_tail: improved stability

  • Fixed duplicated logs when a rotated file is appended during rotate_wait with follow_inodes true.
  • Fixed the remaining lines of a file never being collected when the file is rate-limited by <group> and then removed from the watch list, for example by limit_recently_modified.
  • Fixed NameError when flushing buffered lines with emit_unmatched_lines true.
  • Fixed errors and timeouts at shutdown when the shutdown overlaps with file discovery or file rotation.
  • multiline_flush_interval is no longer affected by system clock adjustments.

buffer: fixed a chunk being flushed twice

Fixed a bug that could cause a file buffer chunk to be flushed twice, resulting in closed stream or ENOENT errors and incorrect buffer size metrics. Also fixed the stage_size metric that could briefly become negative.

http_server helper: fixed bind failures and IPv6 addresses

These fixes affect plugins using the http_server helper, such as in_monitor_agent and fluent-plugin-prometheus.

  • Fixed HTTP endpoints never recovering after a bind failure. Previously, the plugin started anyway without listening on the port. Now the plugin fails to start, and the worker is restarted until the port is available. You can slow down the restart with restart_worker_interval in the <system> directive.
  • Fixed URI::InvalidURIError when binding to IPv6 addresses such as :: and ::1.

supervisor: fixed graceful reload with YAML configuration

Fixed graceful reload failing with YAML configuration files, for example when triggered through the RPC endpoint /api/config.gracefulReload. Also fixed <<: !include of a file that contains a mapping. It restores the documented shared parameter syntax.

Other bug fixes

  • out_file: fixed missing symlinks when symlink_path is used with chunk keys other than time. Previously, only one of the chunks with the latest timekey got a symlink.
  • parser_msgpack: fixed leftover data from truncated input mixing into the next request, connection, datagram or record. It affected in_http, in_tcp, in_udp and filter_parser.
  • Fixed emit_records and emit_size metrics always being 0 for input plugins with @label.
  • Fixed the time of an event at the Unix epoch that could be formatted as empty, for example in out_file.

Enjoy logging!

Follow us on X

We have been posting information about Fluentd in Japanese on @fluentd_jp. We would appreciate it if you followed the X account.

Read More

Fluentd v1.19.4 has been released

Hi users!

We have released v1.19.4 on 2026-09-29. ChangeLog is here.

This release is a maintenance release of v1.19 series.

This release will be bundled for fluent-package LTS version v6.0.5!

Security Fixes

Many vulnerabilities were fixed in this release.

In most cases, there is no problem using deployed Fluentd within a closed, trusted network. If you could not update Fluentd immediately, consider to take advised mitigation in above advisories.

Bug Fixes

Many bugs were also fixed in this release.

  • output: fix JSON::GeneratorError as unrecoverable error. (#5423)
    • Failure for content reasons (e.g. non-UTF-8 bytes, NaN/Infinity), is treated as a bad chunk.
  • Set allow_duplicate_key parameter for JSON.parse. It accept duplicate keys silently (last value wins) on every path. It keeps compatibility with older versions even though newer json gem is used. (#5430)
  • Set allow_comments parameter for JSON.parse. It accepts JSON with comments. It keeps compatibility with older versions even though newer json gem is used. (#5432)
  • Accept a bare scalar for an array option in YAML syntax (#5433)
  • parser_syslog: Optimize RFC5424 structured data parsing (#5444)
    • It avoids excessive backtracking when parsing malformed RFC5424 structured data.
  • out_forward: drop keepalive sockets with failed or mismatched acks (#5445)
    • It stops the endless "ack in response and chunk id in sent data are different" warning storm by discarding (instead of reusing) a keepalive socket.
  • buffer: fix stage_byte_size leak when a staged chunk is unstaged (#5456)
    • There was a possibility that it could eventually raise spurious BufferOverflowError. It affects plugins which implementing #format.
  • plugin base: bound the number of worker lock files by hashing the path into a fixed set of buckets. (#5471)
  • supervisor: reduce memory usage of cleanup_lock_dir with huge number of lock files (#5472)
  • config: accept empty lines in quoted strings (#5478)
  • chunk: ensure to close the Tempfile for decompressed data (#5486)
  • buffer: fix spurious BufferOverflowError caused by queue_size leaking when a chunk purge fails (#5487)
  • buffer: clamp exported buffer size metrics to non-negative values (#5488)
  • Support json gem v3.x (#5493)
  • parser_syslog: fix NameError when RFC3164 timestamp has repeated spaces (#5497)
  • parser_syslog: fix NameError when RFC5424 timestamp has repeated spaces (#5500)

Accept a bare scalar for an array option in YAML syntax

In the previous versions, a single scalar value for an array option is rejected in YAML config syntax.

Since v1.19.4, it accepts the following example.

config:
  - match:
      $tag: "**"
      $type: http
      retryable_response_codes: 503

plugin base: bound the number of worker lock files by hashing the path into a fixed set of buckets

When workers > 1, out_file (with append) and out_secondary_file take an inter-worker lock per output path, and get_lock_path derives one lock file per path: /tmp/fluentd-lock-*/fluentd-<sanitized path>.lock.

In the previous versions, a lock file is never removed while fluentd is running; the only cleanup is cleanup_lock_dir at a graceful shutdown. So the number of lock files grows with the number of unique output paths, and with a date or a tag placeholder in path that set is effectively unbounded over time.

In this release, the number of lock files is now bounded by a constant instead of by the number of unique paths. The accumulation, the mass deletion at shutdown, and the dependence on an external tmp cleaner all disappear structurally rather than being mitigated.

Enjoy logging!

Follow us on X

We have been posting information about Fluentd in Japanese on @fluentd_jp. We would appreciate it if you followed the X account.

Read More

fluent-package v6.0.5 has been released

Hi users!

We have released fluent-package v6.0.5 on 2026-09-29. Fluent Package is a stable distribution package of Fluentd. (successor of td-agent)

This is a maintenance release of v6.0.x LTS series.

Fluent Package v6.0.5

Fluent Package v6.0.5 includes the following improvements:

  • Updated bundled Fluentd to v1.19.4 which fixes some vulnerabilities
  • Updated bundled Ruby to 3.4.11
  • Updated bundled gems which fix vulnerabilities and crashes (oj, json)
  • msi: Fixed a broken link to enterprise services on the popup window of the Windows installer
  • rpm: Kept compatibility with older RHEL 9.x and 10.x
  • deb rpm: Reduced build time by disabling LTO on RHEL 10 and Ubuntu

This article explains the changes in Fluent Package v6.0.5.

Changes

Updated bundled Fluentd to v1.19.4 which fixes some vulnerabilities

In this release, some critical vulnerabilities were fixed.

The above vulnerabilities affects to older than v1.19.4, thus the following packages also will be affected.

  • fluent-package LTS v6.0.4 or earlier
  • fluent-package Standard edition v6.0.0 (NOTE: no patched version planned yet, please consider to use LTS)
  • fluent-package LTS v5.0.9 or earlier (NOTE: v5.0.x already reached EOL, no patched updates anymore)
  • fluent-package Standard edition v5.2.0 or earlier (NOTE: v5.x already reached EOL, no patched updates anymore)
  • All of td-agent (NOTE: td-agent already reached EOL, no patched updates anymore)

We recommend upgrading fluent-package to v6.0.5.

If you can't upgrade it immediately, there is a case that mitigation method is explained in above advisory. Please check each advisory and take care of it.

Fluentd v1.19.4 also contains many bug fixes. See the release announcement of Fluentd v1.19.4 for details.

Updated bundled Ruby to 3.4.11

Ruby 3.4.11 is a maintenance release. Compared to Ruby 3.4.9 which was bundled in the previous version, it includes the following security fixes in bundled gems:

For details, please see the Ruby 3.4.10 and Ruby 3.4.11 release notes.

msi: fixed a broken link to enterprise services on popup window

The link to the enterprise services page on the popup window of the Windows installer was broken. It has been fixed in this release. (#1079)

rpm: keep compatibility with older RHEL 9.x and 10.x

The packages for RHEL 9.x and 10.x were built on the latest minor version of each series. As a result, the built binaries required newer symbols such as GLIBC_2.35 or OPENSSL_3.4.0, and they did not work on older minor versions like RHEL 9.6 or RHEL 10.1.

To keep the ABI compatible in the whole 9.x and 10.x series, the build environment is now pinned to RHEL 9.2 and RHEL 10.0. (#1089, #1090)

This issue was fixed and shipped as 6.0.4-2 on above platforms which had been implemented in advance, has now been officially released.

rpm deb: disable LTO for RHEL 10 and Ubuntu

RPM 4.19 (AlmaLinux 10) and dpkg-buildflags on Ubuntu export LTO (Link Time Optimization) flags (-flto=auto -ffat-lto-objects) into the build process. These flags leaked into jemalloc, Ruby and native gem extensions, and made the build much slower. For example, the total build time on AlmaLinux 10 grew extraordinaly.

Since the bundled Ruby uses its own optimization settings, LTO gives no measurable benefit here. So we removed the LTO flags and the annobin plugin from the build environment. The hardening flags such as stack protection, control flow protection and FORTIFY_SOURCE are kept as before.

This change also means that native extensions which users build with fluent-gem install no longer inherit the LTO overhead. (#1102)

Download

Please visit the download page.

Announcement

About next LTS schedule

We plan to release the next LTS version of fluent-package v6.0.6 at Dec 2026. The content of updates are still TBD.

Follow us on X

We have been posting information about Fluentd in Japanese on @fluentd_jp. We would appreciate it if you followed the X account.

Read More

Scheduled support lifecycle announcement about Fluent Package v7

Hi users!

We had launched fluent-package v6 series last year, recently shipped v6.0.4 in LTS release channel.

In this blog article, we explain the planned next major updates - v7.0.0.

When the next LTS (Long Term Support) version available?

In short, we will ship fluent-package v7 in Aug, 2027.

We keep two release channels as follows:

  • Normal release
  • LTS (Long Term Support)

Here is the difference of these channels.

  • Normal release (7.x series)
    • Recommended for early adopters (eager to try new features of Fluentd)
    • Regular releases are not guaranteed. (planned semi-annually releases, but it may vary. In some cases, the LTS version may actually be newer.)
    • Fluentd will be upgraded occasionally
      • Minor upgrade will be applied. e.g. 1.20 => 1.21 and so on.
      • e.g. v7.0.1 (Fluentd v1.20.1), v7.0.2 (Fluentd v1.20.2), ... v7.1.0 (Fluentd v1.21.0)
    • The only latest version will be supported
  • LTS (Long Term Support, 7.0.x series)
    • Recommended for enterprise services
    • Security and bug fix release only
    • Fluentd will be upgraded only in the teeny version and will stick to 1.20.x series. (T.B.D.)
      • Thus, the version number will be 7.0.x. (7.1 series will not be shipped for LTS channel)
      • e.g. v7.0.1 (Fluentd v1.20.1), v7.0.2 (Fluentd v1.20.2), v7.0.3 (Fluentd v1.20.3) ... v7.0.x (Fluentd v1.20.x) and so on.
    • Next major version will be fluent-package v8.0.0, and will be shipped in 2029 (T.B.D.).

As for fluent-package v7,

  • fluent-package v6 LTS will be supported until Dec, 2027.
    • We expect users upgrade from v6 to v7 during the grace period.
  • Until 7.1.0 is released, normal release channel and LTS channel are the same package.
  • Upgrade from v4 or older version is not supported. Upgrade to v5 or v6 first, then upgrade it to v7.

Current releases and future plans:

Release Version Release Date End of life
v6.0.x (LTS) Aug, 2025 Dec, 2027
v7.0.0 (LTS) Aug, 2027 Dec, 2029 (T.B.D.)
v8.0.0 (LTS) Aug, 2029 (T.B.D.) T.B.D.

Happy logging!

Read More

fluent-package v6.0.4 has been released

Hi users!

We have released fluent-package v6.0.4 on 2026-06-26. Fluent Package is a stable distribution package of Fluentd. (successor of td-agent)

This is a maintenance release of v6.0.x LTS series.

Fluent Package v6.0.4

Fluent Package v6.0.4 includes the following improvements:

  • Updated bundled Fluentd to v1.19.3 which fixes some vulnerabilities.

This article explains the changes in Fluent Package v6.0.4.

Changes

Updated bundled Fluentd to v1.19.3 which fixes some vulnerabilities.

In this release, some critical vulnerabilities were fixed.

The above vulnerabilities affects to older than v1.19.3, thus the following packages also will be affected.

  • fluent-package LTS v6.0.3 or earlier
  • fluent-package Standard edition v6.0.0 (NOTE: no patched version planned yet, please consider to use LTS)
  • fluent-package LTS v5.0.9 or earlier (NOTE: v5.0.x already reached EOL, no patched updates anymore)
  • fluent-package Standard edition v5.2.0 or earlier (NOTE: v5.x already reached EOL, no patched updates anymore)
  • All of td-agent (NOTE: td-agent already reached EOL, no patched updates anymore)

We recommend upgrading fluent-package to v6.0.4.

If you can't upgrade it immediately, there is a case that mitigation method is explained in above advisory. Please check each advisory and take care of it.

Download

Please visit the download page.

Announcement

About next LTS schedule

We plan to release the next LTS version of fluent-package v6.0.5 at Sep 2026. The content of updates are still TBD.

Follow us on X

We have been posting information about Fluentd in Japanese on @fluentd_jp. We would appreciate it if you followed the X account.

Read More


About Fluentd

Fluentd is an open source data collector to simplify log management.

Learn

Want to learn the basics of Fluentd? Check out these pages.

Ask the Community

Couldn't find enough information? Let's ask the community!

Ask the Experts

You need commercial-grade support from Fluentd committers and experts?

Follow Us!