Config File Syntax

This article describes the basic concepts of Fluentd's configuration file syntax.
Introduction: The Life of a Fluentd Event
Here is a brief overview of the life of a Fluentd event to help you understand the rest of this page:
The configuration file allows the user to control the input and output behavior of Fluentd by (1) selecting input and output plugins and (2) specifying the plugin parameters. The file is required for Fluentd to operate properly.
See also Life of a Fluentd Event article.
Config File Location
RPM, Deb or DMG
If you installed Fluentd using the td-agent packages, the config file is located at /etc/td-agent/td-agent.conf.
1
$ sudo vi /etc/td-agent/td-agent.conf
Copied!
Gem
If you installed Fluentd using the Ruby Gem, you can create the configuration file using the following commands. Sending a SIGHUP signal will reload the config file.
1
$ sudo fluentd --setup /etc/fluent
2
$ sudo vi /etc/fluent/fluent.conf
Copied!
FLUENT_CONF environment variable
You can change default configuration file location via FLUENT_CONF. For example, /etc/td-agent/td-agent.conf is specified via FLUENT_CONF inside td-agent scripts.
-c option
See Command Line Option article.
Character encoding
Fluentd assumes configuration file is UTF-8 or ASCII.
List of Directives
The configuration file consists of the following directives:
1.source directives determine the input sources.
2.match directives determine the output destinations.
3.filter directives determine the event processing pipelines.
4.system directives set system wide configuration.
5.label directives group the output and filter for internal
routing
6.include directives include other files.
Let's actually create a configuration file step by step.
(1) "source": where all the data come from
Fluentd's input sources are enabled by selecting and configuring the desired input plugins using source directives. Fluentd's standard input plugins include http and forward. http turns fluentd into an HTTP endpoint to accept incoming HTTP messages whereas forward turns fluentd into a TCP endpoint to accept TCP packets. Of course, it can be both at the same time (You can add as many sources as you wish)
1
# Receive events from 24224/tcp
2
# This is used by log forwarding and the fluent-cat command
3
<source>
4
  @type forward
5
  port 24224
6
</source>
7
​
8
# http://this.host:9880/myapp.access?json={"event":"data"}
9
<source>
10
  @type http
11
  port 9880
12
</source>
Copied!
Each source directive must include a @type parameter. The @type parameter specifies which input plugin to use.
Interlude: Routing
The source submits events into the Fluentd's routing engine. An event consists of three entities: tag, time and record. The tag is a string separated by '.'s (e.g. myapp.access), and is used as the directions for Fluentd's internal routing engine. The time field is specified by input plugins, and it must be in the Unix time format. The record is a JSON object. Fluentd accepts all non-period characters as a part of a tag. However, since the tag is sometimes used in a different context by output destinations (e.g., table name, database name, key name, etc.), it is strongly recommended that you stick to the lower-case alphabets, digits and underscore, e.g., ^[a-z0-9_]+$.
In the example above, the HTTP input plugin submits the following event:
1
# generated by http://this.host:9880/myapp.access?json={"event":"data"}
2
tag: myapp.access
3
time: (current time)
4
record: {"event":"data"}
Copied!
Didn't find your input source? You can write your own plugin!
You can add new input sources by writing your own plugins. For further information regarding Fluentd's input sources, please refer to the Input Plugin Overview article.
(2) "match": Tell fluentd what to do!
The "match" directive looks for events with matching tags and processes them. The most common use of the match directive is to output events to other systems (for this reason, the plugins that correspond to the match directive are called "output plugins"). Fluentd's standard output plugins include file and forward. Let's add those to our configuration file.
1
# Receive events from 24224/tcp
2
# This is used by log forwarding and the fluent-cat command
3
<source>
4
  @type forward
5
  port 24224
6
</source>
7
​
8
# http://this.host:9880/myapp.access?json={"event":"data"}
9
<source>
10
  @type http
11
  port 9880
12
</source>
13
​
14
# Match events tagged with "myapp.access" and
15
# store them to /var/log/fluent/access.%Y-%m-%d
16
# Of course, you can control how you partition your data
17
# with the time_slice_format option.
18
<match myapp.access>
19
  @type file
20
  path /var/log/fluent/access
21
</match>
Copied!
Each match directive must include a match pattern and a @type parameter. Only events with a tag matching the pattern will be sent to the output destination (in the above example, only the events with the tag "myapp.access" is matched. See the section below for more advanced usage). The @type parameter specifies the output plugin to use.
Just like input sources, you can add new output destinations by writing your own plugins. For further information regarding Fluentd's output destinations, please refer to the Output Plugin Overview article.
(3) "filter": Event processing pipeline
The "filter" directive has same syntax as "match" but "filter" could be chained for processing pipeline. Using filters, event flow is like below:
1
Input -> filter 1 -> ... -> filter N -> Output
Copied!
Let's add standard record_transformer filter to "match" example.
1
# http://this.host:9880/myapp.access?json={"event":"data"}
2
<source>
3
  @type http
4
  port 9880
5
</source>
6
​
7
<filter myapp.access>
8
  @type record_transformer
9
  <record>
10
    host_param "#{Socket.gethostname}"
11
  </record>
12
</filter>
13
​
14
<match myapp.access>
15
  @type file
16
  path /var/log/fluent/access
17
</match>
Copied!
Received event, {"event":"data"}, goes to record_transformer filter first. record_transformer adds "host_param" field to event and filtered event, {"event":"data","host_param":"webserver1"}, goes to file output.
You can also add new filters by writing your own plugins. For further information regarding Fluentd's filter destinations, please refer to the Filter Plugin Overview article.
(4) Set system wide configuration: the "system" directive
Following configurations are set by system directive. You can set same configurations by fluentd options:
log_level
suppress_repeated_stacktrace
emit_error_log_interval
suppress_config_dump
without_source
process_name (only available in system directive. No fluentd
option)
Here is an example:
1
<system>
2
  # equal to -qq option
3
  log_level error
4
  # equal to --without-source option
5
  without_source
6
  # ...
7
</system>
Copied!
process_name
If set this parameter, fluentd's supervisor and worker process names are changed.
1
<system>
2
  process_name fluentd1
3
</system>
Copied!
If we have this configuration, ps command shows the following result:
1
% ps aux | grep fluentd1
2
foo      45673   0.4  0.2  2523252  38620 s001  S+    7:04AM   0:00.44 worker:fluentd1
3
foo      45647   0.0  0.1  2481260  23700 s001  S+    7:04AM   0:00.40 supervisor:fluentd1
Copied!
This feature requires ruby 2.1 or later.
(5) Group filter and output: the "label" directive
The "label" directive groups filter and output for internal routing. "label" reduces the complexity of tag handling.
Here is a configuration example. "label" is built-in plugin parameter so @ prefix is needed.
1
<source>
2
  @type forward
3
</source>
4
​
5
<source>
6
  @type tail
7
  @label @SYSTEM
8
</source>
9
​
10
<filter access.**>
11
  @type record_transformer
12
  <record>
13
    # ...
14
  </record>
15
</filter>
16
<match **>
17
  @type elasticsearch
18
  # ...
19
</match>
20
​
21
<label @SYSTEM>
22
  <filter var.log.middleware.**>
23
    @type grep
24
    # ...
25
  </filter>
26
  <match **>
27
    @type s3
28
    # ...
29
  </match>
30
</label>
Copied!
In this configuration, forward events are routed to record_transformer filter / elasticsearch output and in_tail events are routed to grep filter / s3 output inside @SYSTEM label.
"label" is useful for event flow separation without tag prefix.
ERROR label
@ERROR label is a built-in label used for error record emitted by plugin's emit_error_event API.
If you set <label @ERROR> in the configuration, events are routed to this label when emit related error, e.g. buffer is full or invalid record.
(6) Re-use your config: the "## include" directive
Directives in separate configuration files can be imported using the include directive:
1
# Include config files in the ./config.d directory
2
@include config.d/*.conf
Copied!
The include directive supports regular file path, glob pattern, and http URL conventions:
1
# absolute path
2
@include /path/to/config.conf
3
​
4
# if using a relative path, the directive will use
5
# the dirname of this config file to expand the path
6
@include extra.conf
7
​
8
# glob match pattern
9
@include config.d/*.conf
10
​
11
# http
12
@include http://example.com/fluent.conf
Copied!
Note for glob pattern, files are expanded in the alphabetical order. If you have a.conf and b.conf, fluentd parses a.conf first. But you should not write the configuration depends on this order. It is so error prone. Please separate @include for safety.
1
# If you have a.conf,b.conf,...,z.conf and a.conf / z.conf are important...
2
​
3
# This is bad
4
@include *.conf
5
​
6
# This is good
7
@include a.conf
8
@include config.d/*.conf
9
@include z.conf
Copied!
How match patterns work
As described above, Fluentd allows you to route events based on their tags. Although you can just specify the exact tag to be matched (like <filter app.log>), there are a number of techniques you can use to manage the data flow more efficiently.
Wildcards and Expansions
The following match patterns can be used in <match> and <filter> tags.
* matches a single tag part.
For example, the pattern a.* matches a.b, but does not match
a or a.b.c
** matches zero or more tag parts.
For example, the pattern a.** matches a, a.b and a.b.c
{X,Y,Z} matches X, Y, or Z, where X, Y, and Z are match patterns.
For example, the pattern {a,b} matches a and b, but does not match c
This can be used in combination with the * or ** patterns. Examples include a.{b,c}.* and a.{b,c.**}
When multiple patterns are listed inside a single tag (delimited by one or more whitespaces), it matches any of the listed patterns. For example:
The patterns <match a b> match a and b.
The patterns <match a.** b.*> match a, a.b, a.b.c (from the first pattern) and b.d (from the second pattern).
Note on Match Order
Fluentd tries to match tags in the order that they appear in the config file. So if you have the following configuration:
1
# ** matches all tags. Bad :(
2
<match **>
3
  @type blackhole_plugin
4
</match>
5
​
6
<match myapp.access>
7
  @type file
8
  path /var/log/fluent/access
9
</match>
Copied!
then myapp.access is never matched. Wider match patterns should be defined after tight match patterns.
1
<match myapp.access>
2
  @type file
3
  path /var/log/fluent/access
4
</match>
5
​
6
# Capture all unmatched tags. Good :)
7
<match **>
8
  @type blackhole_plugin
9
</match>
Copied!
Of course, if you use two same patterns, second match is never matched. If you want to send events to multiple outputs, consider out_copy plugin.
The common pitfall is when you put a <filter> block after <match>. It will never work as supposed, since events never go through the filter for the reason explained above.
1
# You should NOT put this <filter> block after the <match> block below.
2
# If you do, Fluentd will just emit events without applying the filter.
3
<filter myapp.access>
4
  @type record_transformer
5
  ...
6
</filter>
7
​
8
<match myapp.access>
9
  @type file
10
  path /var/log/fluent/access
11
</match>
Copied!
Supported Data Types for Values
Each Fluentd plugin has a set of parameters. For example, in_tail has parameters such as rotate_wait and pos_file. Each parameter has a specific type associated with it. They are defined as follows:
Each parameter's type should be documented. If not, please let the plugin author know.
string type: the field is parsed as a string. This is the most
"generic" type, where each plugin decides how to process the string.
string has 3 literals, non-quoted one line string, ' quoted
string and " quoted string.
See "Format tips" section and literal examples.
integer type: the field is parsed as an integer.
float type: the field is parsed as a float.
size type: the field is parsed as the number of bytes. There are
several notational variations:
If the value matches <INTEGER>k or <INTEGER>K, then the
value is the INTEGER number of kilobytes.
If the value matches <INTEGER>m or <INTEGER>M, then the
value is the INTEGER number of megabytes.
If the value matches <INTEGER>g or <INTEGER>G, then the
value is the INTEGER number of gigabytes.
If the value matches <INTEGER>t or <INTEGER>T, then the
value is the INTEGER number of terabytes.
Otherwise, the field is parsed as integer, and that integer is
the number of bytes.
time type: the field is parsed as a time duration.
If the value matches <INTEGER>s, then the value is the INTEGER
seconds.
If the value matches <INTEGER>m, then the value is the INTEGER
minutes.
If the value matches <INTEGER>h, then the value is the INTEGER
hours.
If the value matches <INTEGER>d, then the value is the INTEGER
days.
Otherwise, the field is parsed as float, and that float is the
number of seconds. This option is useful for specifying
sub-second time durations such as "0.1" (=0.1 second = 100ms).
array type: the field is parsed as a JSON array. It also supports
shorthand syntax. These are same values.
normal: ["key1", "key2"]
shorthand: key1,key2
hash type: the field is parsed as a JSON object. It also supports
shorthand syntax. These are same values.
normal: {"key1":"value1", "key2":"value2"}
shorthand: key1:value1,key2:value2
array and hash are JSON because almost all programming languages and infrastructure tools can generate JSON value easily than unusual format.
Common plugin parameter
These parameters are system reserved and it has @ prefix.
@type: Specify plugin type
@id: Specify plugin id. in_monitor_agent uses this value for
plugin_id field
@label: Specify label symbol. See
​label​
section
@log_level: Specify per plugin log level. See Per Plugin Log section
type, id and log_level are supported for backward compatibility.
Check configuration file
You can check your configuration without plugins start by specifying --dry-run option.
1
$ fluentd --dry-run -c fluent.conf
Copied!
Format tips
This section describes useful features in configuration format.
Multi line support for " quoted string, array and hash values
You can write multi line value for " quoted string, array and hash values.
1
str_param "foo  # This line is converted to "foo\nbar". NL is kept in the parameter
2
bar"
3
array_param [
4
  "a", "b"
5
]
6
hash_param {
7
  "k":"v",
8
  "k1":10
9
}
Copied!
Fluentd assumes [ or { is a start of array / hash. So if you want to set [ or { started but non-json parameter, please use ' or ".
Example1: mail plugin:
1
<match **>
2
  @type mail
3
  subject "[CRITICAL] foo's alert system"
4
</match>
Copied!
Example2: map plugin:
1
<match tag>
2
  @type map
3
  map '[["code." + tag, time, { "code" => record["code"].to_i}], ["time." + tag, time, { "time" => record["time"].to_i}]]'
4
  multi true
5
</match>
Copied!
We will remove this restriction with configuration parser improvement.
Embedded Ruby code
You can evaluate the Ruby code with #{} in " quoted string. This is useful for setting machine information like hostname.
1
host_param "#{Socket.gethostname}" # host_param is actual hostname like `webserver1`.
2
env_param "foo-#{ENV["FOO_BAR"]}" # NOTE that foo-"#{ENV["FOO_BAR"]}" doesn't work.
Copied!
config-xxx mixins use "${}", not "#{}". These embedded configurations are two different things.
In double quoted string literal, \ is escape character
\ is interpreted as escape character. You need \ for setting ", \r, \n, \t, \ or several characters in double-quoted string literal.
1
str_param "foo\nbar" # \n is interpreted as actual LF character
Copied!
If this article is incorrect or outdated, or omits critical information, please let us know. Fluentd is a open source project under Cloud Native Computing Foundation (CNCF). All components are available under the Apache 2 License.
Configuration
Routing Examples
Last modified 2yr ago