Tail

The plugin reads every matched file in the Path pattern and for every new line found (separated by a \n), it generates a new record. Optionally a database file can be used so the plugin can have a history of tracked files and a state of offsets, this is very useful to resume a state if the service is restarted.

The plugin supports the following configuration parameters:

Note that if the database parameter DB is not specified, by default the plugin will start reading each target file from the beginning. This also might cause some unwanted behaviour, for example when a line is bigger that Buffer_Chunk_Size and Skip_Long_Lines is not turned on, the file will be read from the beginning each Refresh_Interval until the file is rotated.

Additionally the following options exists to configure the handling of multi-lines files:

" class="reference-link">Docker Mode Configuration Parameters

Docker mode exists to recombine JSON log lines split by the Docker daemon due to its line length limit. To use this feature, configure the tail plugin with the corresponding parser and then enable Docker mode:

In order to tail text or log files, you can run the plugin from the command line or through the configuration file:

From the command line you can let Fluent Bit parse text files with the following options:

Configuration File

  1. [INPUT]
  2.     Name        tail
  3.     Path        /var/log/syslog
  5. [OUTPUT]
  6.     Name   stdout
  7.     Match  *

When using multi-line configuration you need to first specify Multiline On in the configuration and use the Parser_Firstline and additional parser parameters Parser_N if needed. If we are trying to read the following Java Stacktrace as a single event

  1. Dec 14 06:41:08 Exception in thread "main" java.lang.RuntimeException: Something has gone wrong, aborting!
  2.     at com.myproject.module.MyProject.oneMoreMethod(MyProject.java:18)
  3.     at com.myproject.module.MyProject.anotherMethod(MyProject.java:14)
  5.     at com.myproject.module.MyProject.main(MyProject.java:6)

We need to specify a Parser_Firstline parameter that matches the first line of a multi-line event. Once a match is made Fluent Bit will read all future lines until another match with Parser_Firstline is made .

In the case above we can use the following parser, that extracts the Time as time and the remaining portion of the multiline as log

If we want to further parse the entire event we can add additional parsers with Parser_N where N is an integer. The final Fluent Bit configuration looks like the following:

  1. # Note this is generally added to parsers.conf and referenced in [SERVICE]
  2. [PARSER]
  3.     Name multiline
  4.     Format regex
  5.     Regex /(?<time>Dec \d+ \d+\:\d+\:\d+)(?<message>.*)/
  6.     Time_Key  time
  7.     Time_Format %b %d %H:%M:%S
  9. [INPUT]
  10.     Name             tail
  11.     Multiline        On
  12.     Parser_Firstline multiline
  13.     Path             /var/log/java.log
  15. [OUTPUT]
  16.     Name             stdout

Our output will be as follows.

  1. [0] tail.0: [1607928428.466041977, {"message"=>"Exception in thread "main" java.lang.RuntimeException: Something has gone wrong, aborting!
  2.     at com.myproject.module.MyProject.badMethod(MyProject.java:22)
  3.     at com.myproject.module.MyProject.oneMoreMethod(MyProject.java:18)
  4.     at com.myproject.module.MyProject.anotherMethod(MyProject.java:14)

The tail input plugin a feature to save the state of the tracked files, is strongly suggested you enabled this. For this purpose the db property is available, e.g:

  1. $ sqlite3 tail.db
  2. -- Loading resources from /home/edsiper/.sqliterc
  4. SQLite version 3.14.1 2016-08-11 18:53:32
  5. Enter ".help" for usage hints.
  6. sqlite> SELECT * FROM in_tail_files;
  7. id     name                              offset        inode         created
  8. -----  --------------------------------  ------------  ------------  ----------
  9. 1      /var/log/syslog                   73453145      23462108      1480371857
  10. sqlite>

Formatting SQLite

By default SQLite client tool do not format the columns in a human read-way, so to explore in_tail_files table you can create a config file in ~/.sqliterc with the following content:

  1. .headers on
  2. .mode column
  3. .width 5 32 12 12 10

Fluent Bit keep the state or checkpoint of each file through using a SQLite database file, so if the service is restarted, it can continue consuming files from it last checkpoint position (offset). The default options set are enabled for high performance and corruption-safe.

The SQLite journaling mode enabled is Write Ahead Log or WAL. This allows to improve performance of read and write operations to disk. When enabled, you will see in your file system additional files being created, consider the following configuration statement:

The above configuration enables a database file called test.db and in the same path for that file SQLite will create two additional files:

  • test.db-shm
  • test.db-wal

Those two files aims to support the WAL mechanism that helps to improve performance and reduce the number system calls required. The -wal file refers to the file that stores the new changes to be committed, at some point the WAL file transactions are moved back to the real database file. The -shm file is a shared-memory type to allow concurrent-users to the WAL file.

WAL and Memory Usage

The WAL mechanism give us higher performance but also might increase the memory usage by Fluent Bit. Most of this usage comes from the memory mapped and cached pages. In some cases you might see that memory usage keeps a bit high giving the impression of a memory leak, but actually is not relevant unless you want your memory metrics back to normal. Starting from Fluent Bit v1.7.3 we introduced the new option db.journal_mode mode that sets the journal mode for databases, by default it will be WAL (Write-Ahead Logging), currently allowed configurations for db.journal_mode are DELETE | TRUNCATE | PERSIST | MEMORY | WAL | OFF .

Note that the Path patterns cannot match the rotated files. Otherwise, the rotated file would be read again and lead to duplicate records.