Multiline Parsing
Last updated
Was this helpful?
Last updated
Was this helpful?
In an ideal world, applications might log their messages within a single line, but in reality applications generate multiple log messages that sometimes belong to the same context. Processing this information can be complex, like in application stack traces, which always have multiple log lines.
Fluent Bit v1.8 implemented a unified Multiline core capability to solve corner cases.
The Multiline parser engine exposes two ways to configure and use the feature:
Built-in multiline parser
Configurable multiline parser
Fluent Bit exposes certain pre-configured parsers (built-in) to solve specific multiline parser cases. For example:
docker
Process a log entry generated by a Docker container engine. This parser supports the concatenation of log entries split by Docker.
cri
Process a log entry generated by CRI-O container engine. Like the docker parser, it supports concatenation of log entries
go
Process log entries generated by a Go based language application and perform concatenation if multiline messages are detected.
python
Process log entries generated by a Python based language application and perform concatenation if multiline messages are detected.
java
Process log entries generated by a Google Cloud Java language application and perform concatenation if multiline messages are detected.
You can define your own Multiline parsers with their own rules, using a configuration file.
A multiline parser is defined in a parsers configuration file by using a[MULTILINE_PARSER] section definition. The multiline parser must have a unique name
and a type, plus other configured properties associated with each type.
To understand which multiline parser type is required for your use case you have to know the conditions in the content that determine the beginning of a multiline message, and the continuation of subsequent lines. Fluent Bit provides a regular expression-based configuration that supports states to handle from the most cases.
name
Specify a unique name for the multiline parser definition. A good practice is to prefix the name with the word multiline_ to avoid confusion with normal parser definitions.
none
type
Set the multiline mode. Fluent Bit supports the type regex.
none
parser
Name of a pre-defined parser that must be applied to the incoming content before applying the regular expression rule. If no parser is defined, it's assumed that's a raw text and not a structured message.
When a parser is applied to a raw text, the regular expression is applied against a specific key of the structured message by using the key_content configuration property.
none
key_content
For an incoming structured message, specify the key that contains the data that should be processed by the regular expression and possibly concatenated.
none
flush_timeout
Timeout in milliseconds to flush a non-terminated multiline buffer.
5s
rule
none
Before configuring your parser you need to know the answer to the following questions:
What's the regular expression (regex) that matches the first line of a multiline message?
What are the regular expressions (regex) that match the continuation lines of a multiline message?
When matching a regular expression, you must to define states. Some states define the start of a multiline message while others are states for the continuation of multiline messages. You can have multiple continuation states definitions to solve complex cases.
The first regular expression that matches the start of a multiline message is calledstart_state. Other regular expression continuation lines can have different state names.
A rule specifies how to match a multiline pattern and perform the concatenation. A rule is defined by 3 specific components:
state name
regular expression pattern
next state
A rule might be defined as follows (comments added to simplify the definition):
This example defines two rules. Each rule has its own state name, regex patterns, and the next state name. Every field that composes a rule must be inside double quotes.
The first rule of a state name must be start_state. The regex pattern must match the first line of a multiline message, and a next state must be set to specify what the possible continuation lines look like.
The following example provides a full Fluent Bit configuration file for multiline parsing by using the definition explained previously.
Example files content:
This is the primary Fluent Bit configuration file. It includes the parsers_multiline.conf and tails the file test.log by applying the multiline parser multiline-regex-test. Then it sends the processing to the standard output.
By running Fluent Bit with the given configuration file you will obtain:
The lines that didn't match a pattern aren't considered as part of the multiline message, while the ones that matched the rules were concatenated properly.
The multiline parser is a very powerful feature, but it has some limitations that you should be aware of:
The multiline parser isn't affected by the buffer_max_size configuration option, allowing the composed log record to grow beyond this size. The skip_long_lines option won't be applied to multiline messages.
It's not possible to get the time key from the body of the multiline message. However, it can be extracted and set as a new key by using a filter.
Fluent-bit supports the /pat/m option. It allows . matches a new line, which can be used to parse multiline logs.
The following example retrieves date and message from concatenated logs.
Example files content:
This is the primary Fluent Bit configuration file. It includes the parsers_multiline.conf and tails the file test.log by applying the multiline parser multiline-regex-test. It also parses concatenated log by applying parser named-capture-test. Then it sends the processing to the standard output.
By running Fluent Bit with the given configuration file you will obtain:
Configure a rule to match a multiline pattern. The rule has a . Multiple rules can be defined.
To simplify the configuration of regular expressions, you can use the web site. This link uses the regex described in the previous example, plus a log line that matches the pattern:
The following example files can be located .
