SlackGitHubCommunity MeetingsWebinars

Troubleshooting

Dead letter queue

The Dead Letter Queue (DLQ) feature preserves chunks that fail to be delivered to output destinations. This enables troubleshooting delivery failures without losing data.

Enable dead letter queue

To enable the DLQ, add the following to your Service section:

service:
  storage.path: /var/log/flb-storage/
  storage.keep.rejected: on
  storage.rejected.path: rejected

What gets stored

Chunks are copied to the DLQ when:

  • An output plugin returns an unrecoverable error.

  • A chunk exhausts all configured retry attempts.

  • Retries are disabled (retry_limit: no_retries) and the flush fails.

  • The scheduler fails to schedule a retry.

Examine dead letter queue files

DLQ files are stored in the configured path (for example, /var/log/flb-storage/rejected/) with names that include the tag, status code, and output plugin name. This helps identify which records failed and why.

For example, a file named kube_var_log_containers_test_400_http_0x7f8b4c.flb indicates a chunk with tag kube.var.log.containers.test that failed with status code 400 when sending to the http output.

Dead letter queue management

DLQ files remain on disk until manually removed. Monitor disk usage and implement a cleanup policy.

For more details on DLQ configuration, see Buffering and Storage.

Tap

Tap can be used to generate events or records detailing what messages pass through Fluent Bit, at what time and what filters affect them.

Tap example

Ensure that the container image supports Fluent Bit Tap (available in Fluent Bit 2.0+):

If the --enable-chunk-trace option is present, your Fluent Bit version supports Fluent Bit Tap, but it's disabled by default. Use this option to enable it.

You can start Fluent Bit with tracing activated from the beginning by using the trace-input and trace-output properties:

The following warning indicates the -Z or --enable-chunk-tracing option is missing:

Set properties for the output using the --trace-output-property option:

With that option set, the stdout plugin emits traces in json_lines format:

All three options can also be defined using the more flexible --trace option:

This example defines the Tap pipeline using this configuration: input=dummy.0 output=stdout output.format=json_lines which defines the following:

  • input: dummy.0 listens to the tag or alias dummy.0.

  • output: stdout outputs to a stdout plugin.

  • output.format: json_lines sets the stdout format to json_lines.

Tap support can also be activated and deactivated using the embedded web server:

In another terminal, activate Tap by either using the instance id of the input (dummy.0) or its alias. The alias is more predictable, and is used here:

This response means Tap is active. The terminal with Fluent Bit running should now look like this:

All the records that display are those emitted by the activities of the dummy plugin.

Tap example (complex)

This example takes the same steps but demonstrates how the mechanism works with more complicated configurations.

This example follows a single input, out of many, and which passes through several filters.

To ensure the window isn't cluttered by the records generated by the input plugins, send all of it to null.

Activate with the following curl command:

You should start seeing output similar to the following:

Parameters for the output in Tap

When activating Tap, any plugin parameter can be given. These parameters can be used to modify the output format, the name of the time key, the format of the date, and other details.

The following example uses the parameter "format": "json" to demonstrate how to show stdout in JSON format.

First, run Fluent Bit enabling Tap:

In another terminal, activate Tap including the output (stdout), and the parameters wanted ("format": "json"):

In the first terminal, you should see the output similar to the following:

This parameter shows stdout in JSON format.

See output plugins for additional information.

Analyze a single Tap record

This filter record is an example to explain the details of a Tap record:

  • type: Defines the stage the event is generated:

    • 1: Input record. This is the unadulterated input record.

    • 2: Filtered record. This is a record after it was filtered. One record is generated per filter.

    • 3: Pre-output record. This is the record right before it's sent for output.

    This example is a record generated by the manipulation of a record by a filter so it has the type 2.

  • start_time and end_time: Records the start and end of an event, and is different for each event type:

    • type 1: When the input is received, both the start and end time.

    • type 2: The time when filtering is matched until it has finished processing.

    • type 3: The time when the input is received and when it's finally slated for output.

  • trace_id: A string composed of a prefix and a number which is incremented with each record received by the input during the Tap session.

  • plugin_instance: The plugin instance name as generated by Fluent Bit at runtime.

  • plugin_alias: If an alias is set this field will contain the alias set for a plugin.

  • records: An array of all the records being sent. Fluent Bit handles records in chunks of multiple records and chunks are indivisible, the same is done in the Tap output. Each record consists of its timestamp followed by the actual data which is a composite type of keys and values.

Dump Internals and signal

When the service is running, you can export metrics to see the overall status of the data flow of the service. There are other use cases where you might need to know the current status of the service internals, like the current status of the internal buffers. Dump Internals can help provide this information.

Fluent Bit v1.4 introduced the Dump Internals feature, which can be triggered from the command line triggering the CONT Unix signal.

This feature is only available on Linux and BSD operating systems.

Usage

Run the following kill command to signal Fluent Bit:

The command pidof aims to identify the Process ID of Fluent Bit.

Fluent Bit will dump the following information to the standard output interface (stdout):

Input plugins

The input plugins dump provides insights for every input instance configured.

Status

Overall ingestion status of the plugin.

Entry
Sub-entry
Description

overlimit

If the plugin has been configured with Mem_Buf_Limit, this entry will report if the plugin is over the limit or not at the moment of the dump. Over the limit prints yes, otherwise no.

mem_size

Current memory size in use by the input plugin in-memory.

mem_limit

Limit set by Mem_Buf_Limit.

Tasks

When an input plugin ingests data into the engine, a Chunk is created. A Chunk can contain multiple records. At flush time, the engine creates a Task that contains the routes for the Chunk associated in question.

The Task dump describes the tasks associated to the input plugin:

Entry
Description

total_tasks

Total number of active tasks associated to data generated by the input plugin.

new

Number of tasks not yet assigned to an output plugin. Tasks are in new status for a very short period of time. This value is normally very low or zero.

running

Number of active tasks being processed by output plugins.

size

Amount of memory used by the Chunks being processed (total chunk size).

Chunks

The Chunks dump tells more details about all the chunks that the input plugin has generated and are still being processed.

Depending on the buffering strategy and limits imposed by configuration, some Chunks might be up (in memory) or down (filesystem).

Entry
Sub-entry
Description

total_chunks

Total number of Chunks generated by the input plugin that are still being processed by the engine.

up_chunks

Total number of Chunks loaded in memory.

down_chunks

Total number of Chunks stored in the filesystem but not loaded in memory yet.

busy_chunks

Chunks marked as busy (being flushed) or locked. Busy Chunks are immutable and likely are ready to be or are being processed.

size

Amount of bytes used by the Chunk.

size err

Number of Chunks in an error state where its size couldn't be retrieved.

Storage layer

Fluent Bit relies on a custom storage layer interface designed for hybrid buffering. The Storage Layer entry contains a total summary of Chunks registered by Fluent Bit:

Entry
Sub-Entry
Description

total chunks

Total number of Chunks.

mem chunks

Total number of Chunks memory-based.

fs chunks

Total number of Chunks filesystem based.

up

Total number of filesystem chunks up in memory.

down

Total number of filesystem chunks down (not loaded in memory).

PreviousTLSNextValidate your data and structure

Last updated

Was this helpful?