Forward logs from Fluentd to Osuite

Overview

If you already run Fluentd, route its output to Osuite through an OpenTelemetry Collector. The cleanest path uses Fluentd’s built-in forward output into the Collector’s fluent_forward receiver; the Collector then exports to Osuite with the otlp/osuite exporter.

Prerequisites

• A running Fluentd instance with sources already configured.
• An OpenTelemetry Collector reachable from Fluentd.
• Your Osuite ingest endpoint and token.

Forward into the Collector

Fluentd’s forward output speaks the same protocol the Collector’s fluent_forward receiver expects.

Fluentd (fluent.conf):

<match **>
  @type forward
  <server>
    host <your-collector-host>
    port 8006
  </server>
</match>

Collector:

receivers:
  fluent_forward:
    endpoint: 0.0.0.0:8006

processors:
  batch:

exporters:
  otlp/osuite:
    endpoint: ingest.<region>.osuite.io:443
    tls:
      insecure: false
    headers:
      x-osuite-ingest-token: <your-ingest-token>

service:
  pipelines:
    logs:
      receivers: [fluent_forward]
      processors: [batch]
      exporters: [otlp/osuite]

The fluent_forward receiver maps each Fluentd event to a log record: the Fluentd tag becomes the fluent.tag attribute, the message populates the body, and the remaining fields become attributes.

Alternative: the OpenTelemetry output plugin

The community fluent-plugin-opentelemetry plugin adds an opentelemetry output that speaks OTLP. Its <http> section does not set custom request headers, so it cannot carry the Osuite ingest token to the ingest endpoint directly — point it at a local Collector that attaches the token instead.

Install and configure the plugin:

fluent-gem install fluent-plugin-opentelemetry

<match **>
  @type opentelemetry
  <http>
    endpoint http://127.0.0.1:4318
  </http>
</match>

Then run a Collector whose otlp receiver accepts that traffic and forwards it to Osuite:

receivers:
  otlp:
    protocols:
      http:
        endpoint: 0.0.0.0:4318

processors:
  batch:

exporters:
  otlp/osuite:
    endpoint: ingest.<region>.osuite.io:443
    tls:
      insecure: false
    headers:
      x-osuite-ingest-token: <your-ingest-token>

service:
  pipelines:
    logs:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlp/osuite]

Note

Both paths route through a Collector because Fluentd’s OTLP output cannot attach the ingest token itself. The forward path needs no extra plugin, so prefer it unless you already depend on the OpenTelemetry plugin.

Verify in Osuite

What you should see

Fluentd events appear in the Logs Explorer within a minute, carrying the fluent.tag attribute on the forward path. Filtering by tag isolates a given source.

Troubleshooting

If nothing arrives, confirm Fluentd reaches the Collector (port 8006 for forward, 4318 for OTLP/HTTP) and that the matching receiver is wired into the logs pipeline. A 413 Payload Too Large from the OTLP plugin means a chunk exceeds the ingest body limit — lower Fluentd’s chunk_limit_size. Check the Collector logs for OTLP export errors to Osuite.

No data in Osuite after a few minutes? Work through these checks.

• Endpoint — confirm the exporter targets exactly ingest.<region>.osuite.io:443 for your region, over TLS.
• Token — confirm the ingest header carries a valid <your-ingest-token> and has not been rotated.
• Pipeline — confirm the signal you expect (traces, logs, or metrics) is wired into an active pipeline with the otlp/osuite exporter attached.
• Export errors — check the application or Collector logs for OTLP export failures (auth, DNS, TLS, connection refused).
• Network — confirm the host has outbound access to the ingest endpoint on port 443.
• Timing — allow up to a minute for the first data to appear before assuming a failure.

Still stuck? Ask the Investigation Agent or contact support.

Next steps

• Collect logs from any source — other sources and forwarders.
• Log pipelines — redact, filter, and route logs before storage.