Feature / OTLP

Send OTLP Logs from OpenTelemetry Collector to Fluxtail

Create the matching OTLP HTTP or OTLP gRPC receiver, copy its endpoint, and authenticate with its receiver-bound token. Fluxtail accepts OTLP logs over HTTP JSON, HTTP protobuf, or gRPC. These receivers do not accept traces or metrics.

OTLP logs OpenTelemetry Collectors OTLP receiver

Join the waitlist View pricing

Transport path

OTLP logs move OpenTelemetry log records from SDKs, agents, or Collectors into a receiver.

Resource context

Resource attributes such as service.name, environment, host, pod, container, and region should remain usable after ingestion.

Readable result

A log record should still show a clear message, severity, timestamp, service, and trace context after transport.

Mixed sources

OTLP logs can sit beside HTTP, Syslog, GELF, Kubernetes, Fluent Bit, and other collector-fed streams.

Collector configuration

Use the exact endpoint and token from the Fluxtail receiver

Add the matching exporter to an existing OpenTelemetry Collector logs pipeline. Keep its current receivers and processors, then add the Fluxtail exporter to the pipeline.

OTLP/HTTP receiver values

bash

1export FLUXTAIL_OTLP_LOGS_URL='https://ingest.fluxtail.io/v1/receivers/RECEIVER_ID/otlp/v1/logs'
2export FLUXTAIL_TOKEN='RECEIVER_BOUND_TOKEN'

Copy the complete logs endpoint from Fluxtail. Do not append another /v1/logs path.

OTLP/HTTP Collector exporter

yaml

1exporters:
2  otlphttp/fluxtail:
3    logs_endpoint: ${env:FLUXTAIL_OTLP_LOGS_URL}
4    headers:
5      Authorization: "Bearer ${env:FLUXTAIL_TOKEN}"
6 
7service:
8  pipelines:
9    logs:
10      exporters: [otlphttp/fluxtail]

The HTTP body may use OTLP JSON or protobuf. Use application/json for JSON or application/x-protobuf for protobuf.

OTLP/gRPC Collector exporter

yaml

1exporters:
2  otlp/fluxtail:
3    endpoint: ingest.fluxtail.io:443
4    headers:
5      Authorization: "Bearer ${env:FLUXTAIL_TOKEN}"
6 
7service:
8  pipelines:
9    logs:
10      exporters: [otlp/fluxtail]

The gRPC exporter calls the standard OTLP LogsService Export method. No receiver ID metadata is required.

Endpoint choice

Choose the Receiver That Matches the Collector Exporter

OTLP/HTTP and OTLP/gRPC use different endpoint shapes. Create the matching Fluxtail receiver before configuring the Collector.

01

OTLP/HTTP uses the complete logs URL

Set logs_endpoint to the exact URL copied from Fluxtail. Its path already ends in /otlp/v1/logs, so do not append another /v1/logs segment. Authenticate with Authorization: Bearer followed by the token bound to that receiver.

Fluxtail OpenTelemetry setup

02

OTLP/gRPC uses ingest.fluxtail.io:443

Set the gRPC exporter endpoint to ingest.fluxtail.io:443 and send the receiver-bound token as Bearer metadata. The token identifies the receiver; no receiver ID metadata is required.

03

Send logs only

The Fluxtail OTLP receivers accept logs. They do not accept OTLP traces or metrics. Confirm that the Collector service pipeline is named logs and references the matching exporter.

OpenTelemetry Collector configuration

Fields

What Should Survive OTLP Log Ingestion

An OTLP receiver path is useful when resource attributes, log record fields, and event attributes remain available for reading and filtering.

01

Resource attributes

Preserve service.name, service.namespace, service.version, deployment.environment, host.name, k8s.namespace.name, k8s.pod.name, k8s.container.name, cloud.provider, and cloud.region when they are present.

Resource attributes to preserve

text

1service.name
2service.version
3deployment.environment
4host.name
5k8s.namespace.name
6k8s.pod.name
7k8s.container.name

02

Log record fields

Keep timestamp, severity_text, severity_number, body, trace_id, span_id, and attributes. Fluxtail should receive enough structure to show the human-readable message while retaining the machine-readable context around it.

03

Attributes for filtering

Put event details into attributes when they should be searchable later: http.method, http.route, http.status_code, error.type, error.message, tenant.id, job.name, queue.name, or provider names.

Result

How the Log Appears in Fluxtail

A readable ingested row should preserve the message plus searchable context.

01

Keep the row readable

The row should expose timestamp, level, message, service, environment, host, trace_id, span_id, and useful attributes without forcing the full payload into the visible line.

Readable Fluxtail row

output

2026-04-25T14:30:25Z ERROR billing-api prod payment authorization failed trace=7b5f4f2a2c8148e79c8c1f3a6e9d1123 route=/v1/charges status=502 error=ProviderTimeout

The original event should remain available for deeper inspection while the row stays scannable.

Verification

Verify the OTLP Receiver Path

Do not stop at “the collector sent something.” Confirm that the fields needed for reading and filtering survived the receiver path.

01

Send one known log record

Start with one known log record from one service. Confirm that it appears in Fluxtail with the expected timestamp, readable severity, readable body, service identity, and resource attributes.

02

Confirm trace and span identifiers

When the source emits traceId and spanId, verify that those identifiers remain available for filtering and correlation after ingestion.

03

Verify the stored record

Emit one known log from the Collector, open the receiver's stream in Live Tail, and search for its service name or a unique message. Inspect the row to confirm that the readable body, severity, service identity, resource attributes, and trace identifiers supplied by the source survived ingestion.

04

Check a second source shape

Send another log with a different severity or Kubernetes context to confirm the receiver path handles more than one event shape.

Readability

Keep OpenTelemetry Logs Readable After Transport

OTLP can preserve rich structure, but readability depends on what the source emits and how the destination presents it.

01

Use stable field names

Keep service, environment, severity, route, status, trace, pod, and error fields stable across services so the same filters work during real production traffic.

02

Keep message bodies concise

Use the body for the readable event message. Put operational dimensions into attributes instead of packing everything into one long text field.

03

Verify with documented search fields

After ingestion, use Live Tail to confirm arrival. Narrow the stream by time, message text, service, severity, labels, or Kubernetes fields that are present in the stored record.

OTLP logs often appear beside OpenTelemetry field design, log aggregation, Kubernetes logging, and collector setup.

01

OpenTelemetry logging

Use the OpenTelemetry logging page for field context, trace context, severity, and readable OTel log records.

02

Log aggregation

Use the log aggregation page when OTLP logs need to land beside HTTP, Syslog, GELF, Kubernetes, and collector-fed streams.

03

Kubernetes and Fluent Bit

Use the Kubernetes and Fluent Bit pages when pod, namespace, container, and collector context are the main setup concerns.

Learn how OpenTelemetry logging preserves service, resource, trace, and severity context with readable Fluxtail log views.

Learn how log aggregation works across apps, hosts, syslog, containers, Kubernetes, OTLP, GELF, and collectors.

Practical guide to Kubernetes logging: what metadata to keep, how collection paths work, and how Fluxtail keeps cluster logs searchable.

Use Fluent Bit for Kubernetes log collection, forward records to a Fluxtail receiver, and keep namespace, pod, container, service, and severity fields readable.

Watch production logs in real time with a live log viewer for readable streams, live tail, filters, and diagnostics.

Request access to Fluxtail and review availability, plan limits, retention, and pricing with Fluxtail Engineering.

Next step

Plan the first real log source

Choose one real source and join the waitlist to request access.

Choose one real source for Fluxtail.

When access is available, create a receiver, send one source, and inspect the first stream.