Upgrade Plugin from v0.12
This guide is for plugin authors to show how to update input/output/filter plugins written for Fluentd v0.12 or earlier.
There are some things to be considered (see "Updating Plugins Overview" section for details):
Plugins using v0.12 API will be supported in Fluentd v1. This compatibility
guarantee will no longer be applicable with v2.
Users may use the new features of Fluentd v1 only with the plugins using new
API.
Plugins using the new API will not work with Fluentd v0.12.x.
It is strongly recommended to use v1 API to write your plugins stable, consistent and easy to test.
Updating Plugins Overview
Following are the steps to update your plugins safely:
Release a Latest Version for Fluentd v0.12.x
Update Dependency
Update Code and Tests
Update CI Environments
Release the Newer Version for Fluentd v1 and Later
1. Release a Latest Version
At first, you should make a git branch named as v0.12
(if you are using git for that plugin), and release the latest patch version from that branch without any changes, except fixing dependency of Fluentd ~> 0.12.0
. This makes it possible to fix bugs and release newer versions for Fluentd v0.12 users without breaking anything.
make a branch for Fluentd v0.12 versions
fix dependency of
Fluentd
to~> 0.12.0
(or later:~> 0.12.26
)bump the gem version up to next patch version (e.g.
0.4.1
to0.4.2
)release it to RubyGems.org
2. Update Dependency
The following updates are on the master
branch. You should update the dependency in gemspec
first for Fluentd v1.
fix dependency of
Fluentd
to[">= 1", "< 2"]
execute
bundle install
Recommended dependency in gemspec
:
3. Update Code and Tests
There are many differences between plugin types on updating code and tests. See "Updating Plugin Code" section below for each type of plugin.
update code and tests
run
bundle exec rake test
4. Update CI Environments
If you have CI configurations like .travis.yml
and appvayor.yml
, these should be updated to support Fluentd v1. Fluentd v1 supports Ruby 2.4 or later. CI environments should not include Ruby 2.3 or earlier.
remove Ruby 2.3 or earlier from CI environments
add Ruby 2.4 (or other latest version) to CI environments
5. Add Requirements Section
Add a Requirements section to README.md
like this:
Requirements
| Fluentd | Ruby |
>= 1.0.0 | >= v1 | >= 2.4 |
< 1.0.0 | >= v0.12.0 | >= 2.1 |
This helps that plugin users can understand plugin requirements.
6. Release New Version
This is the last step. The new version should bump the major or minor version, not the patch version. If the current major version of your gem is >= 1, you should bump the major version (e.g. from 1 to 2). If the current major version is 0, you should bump the minor version (e.g. from 0.4.2
to 0.5.0
). Then, you can publish the new release with Fluentd v1.
bump the version up
release it to RubyGems.org
Updating Plugin Code
For all types of plugins, take care about these things:
require files with definitions of classes/modules referred in your plugin code
call
super
in#initialize
,#configure
,#start
and#shutdown
use
router.emit
to emit events into Fluentd instead ofEngine.emit
About updating tests, see the "Test Code" section for all plugin types.
Input Plugins
For input plugins, the points to be fixed are:
require
'fluent/plugin/input'
instead of'fluent/input'
fix superclass from
Fluent::Input
toFluent::Plugin::Input
use
compat_parameters
plugin helper for compatibility with v0.12 config styleuse
Fluent::Engine.now
orFluent::EventTime.now
to create current timeobject instead of
Time.now.to_i
update test code
Plugins will work fine once the above changes are incorporated.
Moreover, most input plugins create threads, timers, network servers and/or parsers. It is better to use plugin helpers to simplify code and to make tests stable.
For more details, see Plugin Helper Overview.
Filter Plugins
For filter plugins, the points to be fixed are:
require
'fluent/plugin/filter'
instead of'fluent/filter'
fix superclass from
Fluent::Filter
toFluent::Plugin::Filter
use
compat_parameters
plugin helper for compatibility with v0.12 config styleupdate test code
Plugins will work fine once the above changes are incorporated. But if your plugin implements #filter_stream
, remove it if possible. Overriding #filter_stream
makes it impossible to optimize filters' performance.
Moreover, many filter plugins use parsers or formatters. It is better to use plugin helpers for them to simplify the code and make the configuration easier to understand.
Non-Buffered Output Plugins
For output plugins, the points to be fixed are:
require
'fluent/plugin/output'
instead of'fluent/output'
fix superclass from
Fluent::Output
toFluent::Plugin::Output
use
compat_parameters
plugin helper for compatibility with v0.12 config styleremove
#emit
method and implement#process(tag, es)
methodupdate test code
If your output plugin emits events into Fluentd, follow these points too:
use
event_emitter
plugin helper to introduce a routeruse
Fluent::Engine.now
orFluent::EventTime.now
to create current timeobject instead of
Time.now.to_i
It is recommended to use plugin helpers if your plugin creates any one of thread, timer, socket, child process, and/or parsers/formatters. Using plugin helpers simplifies the code and makes the tests stable.
For more details, see Plugin Helper Overview.
Before:
After:
Buffered Output Plugins
For buffered output plugins (subclass of Fluent::BufferedOutput
), the points to be fixed are:
require
'fluent/plugin/output'
instead of'fluent/output'
fix superclass from
Fluent::BufferedOutput
toFluent::Plugin::Output
use
compat_parameters
plugin helper for compatibility with v0.12 config styleimplement
#compat_parameters_default_chunk_key
to return an empty string toshow chunk key is not specified
fix
config_set_default
and its parameter names to override parameters in<buffer>
sectionremove
#format_stream
method if it is implemented in your plugin (it is notsupported)
update test code
It is recommended to use plugin helpers if your plugin creates any one of thread, timer, socket, child process, and/or parsers/formatters. Using plugin helpers simplifies the code and makes the tests stable.
For more details, see Plugin Helper Overview.
Before:
After:
For more details, see Writing Buffered Output Plugins.
ObjectBuffered
Output Plugins
ObjectBuffered
Output PluginsFor object buffered output plugins (subclass of Fluent::ObjectBufferedOutput
), the points to be fixed are:
require
'fluent/plugin/output'
instead of'fluent/output'
fix superclass from
Fluent::ObjectBufferedOutput
toFluent::Plugin::Output
use
compat_parameters
plugin helper for compatibility with v0.12 config styleimplement
#compat_parameters_default_chunk_key
to return"tag"
to showchunk key is tag (or something else if your plugin overwrites
#emit
tochange
key
)fix
config_set_default
and its parameter names to override parameters in<buffer>
sectionfix
#write
method code not to usechunk.key
, to usechunk.metadata.tag
and
#extract_placeholders
update test code
It is recommended to use plugin helpers if your plugin creates any one of thread, timer, socket, child process, and/or parsers/formatters. Using plugin helpers simplifies the code and makes the tests stable.
For more details, see Plugin Helper Overview.
Before:
After: Same as the buffered output.
For more details, see Writing Buffered Output Plugins.
TimeSliced Output Plugins
For the time-sliced output plugins (sub-class of Fluent::TimeSlicedOutput
), the points to be fixed are:
require
'fluent/plugin/output'
instead of'fluent/output'
fix superclass from
Fluent::TimeSlicedOutput
toFluent::Plugin::Output
use
compat_parameters
plugin helper for compatibility with v0.12 config styleimplement
#compat_parameters_default_chunk_key
to return"time"
to showchunk key is time
set default value of
timekey
in<buffer>
section if your plugin specifiesdefault
time_slice_format
fix
config_set_default
and its parameter names to override parameters in<buffer>
sectionfix
#write
method code not to usechunk.key
, to usechunk.metadata.timekey
and#extract_placeholders
update test code
It is recommended to use plugin helpers if your plugin creates any one of thread, timer, socket, child process and/or parsers/formatters. It is better to use plugin helpers to simplify code and to make tests stable.
For more details, see Plugin Helper Overview.
Before (code):
Before (configuration):
After (code): Same as the buffered output.
For more details, see Writing Buffered Output Plugins.
After (configuration):
Use <buffer>
section to customize chunking.
For more details, see Understanding Chunking and Metadata.
Multi Output Plugins
For the multi-output plugins (sub-class of Fluent::MultiOutput
), there are many points to be considered.
If the plugin uses <store>
sections and instantiates plugins per each store section, use Fluent::Plugin::MultiOutput
. See code to know how to use it: lib/fluent/plugin/multi_output.rb
or some built-in plugins such asout_copy
and out_roundrobin
.
Otherwise, your plugin does something curious for Fluentd. Read code of lib/fluent/plugin/output.rb
and lib/fluent/plugin/bare_output.rb
, and consider which is better for your plugin. But, it is advised against using Fluent::Plugin::BareOutput
for most use cases.
Output Plugins using Mixins
Fluent::HandleTagAndTimeMixin
, Fluent::SetTagKeyMixin
, Fluent::SetTimeKeyMixin
Fluent::HandleTagAndTimeMixin
, Fluent::SetTagKeyMixin
, Fluent::SetTimeKeyMixin
Use inject
and compat_parameters
plugin helper in the plugin code.
The old configuration will be converted to the new style configuration automatically if the plugin code uses the proper plugin helpers. So, plugin users will not need to rewrite the configuration immediately.
Fluentd shows the converted new style configuration in the startup log if the user provides an old-style configuration. The user may then rewrite the configuration dumped in the log.
Before:
After:
Fluent::HandleTagNameMixin
Fluent::HandleTagNameMixin
Related configurations:
remove_tag_prefix
remove_tag_suffix
add_tag_prefix
add_tag_suffix
Use extract_placeholders(template, chunk)
in plugin code.
Use placeholders ${tag}, ${tag[0]}, ${tag[1]}
in configuration.
Before:
After:
Parser Plugins
require
'fluent/plugin/parser'
instead of'fluent/parser'
fix superclass from
Fluent::Parser
toFluent::Plugin::Parser
use
compat_parameters
plugin helper for compatibility with v0.12 config styleupdate test code
Formatter Plugins
require
'fluent/plugin/formatter'
instead of'fluent/formatter'
fix superclass from
Fluent::Formatter
toFluent::Plugin::Formatter
use
compat_parameters
plugin helper for compatibility with v0.12 config styleupdate test code
Test Code
organize
test_helper.rb
require
'fluent/test/driver/output'
and'fluent/test'
replace test driver from
Fluent::Test::OutputTestDrive
toFluent::Test::Driver::Output
use new test driver API
For example, here is an output plugin's test code.
For more details, see Writing Plugin Test Code.
Before:
test/test_helper.rb
test/plugin/test_some_output.rb
After:
test_helper.rb
test/plugin/test_some_output.rb
If this article is incorrect or outdated, or omits critical information, please let us know. Fluentd is an open-source project under Cloud Native Computing Foundation (CNCF). All components are available under the Apache 2 License.
Last updated