> ## Documentation Index
> Fetch the complete documentation index at: https://otel.fyi/llms.txt
> Use this file to discover all available pages before exploring further.

# Fluentforward

> OpenTelemetry receiver for Fluentforward

# Fluentforward Receiver

![Status](https://img.shields.io/badge/status-beta-yellow)

**Available in:** `contrib`, `k8s`

**Maintainers:** [@dmitryax](https://github.com/dmitryax)

**Source:** [opentelemetry-collector-contrib](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/receiver/fluentforwardreceiver)

## Supported Telemetry

![Logs](https://img.shields.io/badge/logs-beta-blue)

## Overview

> **Note:** The receiver type has been renamed from `fluentforward` to `fluent_forward` to follow the
> snake\_case naming convention. The old name `fluentforward` is preserved as a deprecated alias and
> will continue to work, but a deprecation warning will be logged at startup. Please update your
> configuration to use `fluent_forward:`.

This receiver:

* Does **not** support TLS or the handshake portion of the Forward protocol.
* Does support acknowledgments of events that have the `chunk` option, as per the spec.
* Supports all three event types (message, forward, packed forward, including
  compressed packed forward)
* Supports listening on a Unix domain socket by making the `listenAddress`
  option of the form `unix://<path to socket>`.
* If using TCP, it will start a UDP server on the same port to deliver
  heartbeat echos, as per the spec.

Here is a basic example config that makes the receiver listen on all interfaces
on port 8006:

```yaml theme={null}
receivers:
  fluent_forward:
    endpoint: 0.0.0.0:8006
```

## Data Conversion

The receiver converts Fluentd events to OpenTelemetry logs. Each Fluentd event
is converted to a single OpenTelemetry log record and packets are stored as LogRecordSlice.
The FluentD `tag` is stored as an attribute with key `fluentd.tag`.
The FluentD event timestamp is used as the log record timestamp.
The record `message` or `log` field is stored as the body of the log record. If both are present,
it just takes the field that comes last in the message stream.

Any other fields in the event are stored as attributes on the log record following these rules:

* `bool` values are stored as boolean attributes
* `string` values are stored as string attributes
* `uint64` values are stored as int64 attributes (if value exceeds max int64, stored as string instead)
* `int64` values are stored as int64 attributes
* `[]byte` values are converted to strings
* `map[string]any` values are stored as nested map attributes
* `[]any` values are stored as array attributes
* `float32` and `float64` values are stored as double attributes
* `nil` values are left as empty attributes using `plog.LogRecord.Attributes().PutEmpty(key)`
* All other types are converted to string representation using `fmt.Sprintf("%v", val)` which includes complex types

## Development

If you are working on this receiver and need to regenerate any of the message
pack autogenerated code, just run `go generate` on this package and its
subpackages.  You can get the `msgp` binary by just running `go get -u -t
github.com/tinylib/msgp`, and make sure the Go binary path is on your shell's
PATH.

## Configuration

### Example Configuration

```yaml theme={null}
fluent_forward:
```

***

*Last generated: 2026-07-06*