Fluxtail
Sign in Start free
Feature / OpenTelemetry

OpenTelemetry Logging for Readable, Trace-Aware Logs

OpenTelemetry logging is most useful when logs keep service identity, environment, severity, body fields, trace_id, and span_id. Fluxtail receives OTel-style telemetry logs, keeps common fields searchable when present, and makes them readable through live tail, filters, facets, histograms, alerts, MCP diagnostics, and AI chat.

OpenTelemetry logging OTel logs Trace context Resource attributes
Start free View pricing
Service context

Fields such as service.name, deployment.environment, service.version, host, pod, and namespace keep log records tied to the source that emitted them.

Trace context

trace_id and span_id let related service logs stay connected when one request crosses API, worker, database, and queue boundaries.

Readable rows

A useful OTel log view keeps the message readable while exposing structured fields for filtering and investigation.

Central streams

OpenTelemetry logs can sit beside HTTP, Syslog, GELF, Kubernetes, and Fluent Bit sources in the same Fluxtail account.

Basics

What OpenTelemetry Logging Actually Adds

OpenTelemetry logs are log records with attached telemetry context. The value is not a new label for application logs; it is consistent service, resource, severity, and trace data attached to the event.

01

Logs become structured telemetry

A useful OpenTelemetry log should answer what happened, which service emitted it, which environment it came from, how severe it was, and which request, job, span, or trace was active.

02

Resource context explains the source

Resource attributes such as service.name, deployment.environment, service.version, host, container, pod, namespace, region, and runtime make the log easier to group and filter.

03

Trace context connects related events

trace_id and span_id turn separate service logs into one request story when an API, worker, database call, or queue job participates in the same failure.

OTel example

Keep trace context visible without hiding the log message

An OpenTelemetry-style log event can carry a human-readable body, severity fields, trace identifiers, resource attributes, and queryable event attributes.

Fluxtail live tail showing active log rows in the product.

OTel-style log event
json
1{
2  "timestamp": "2026-04-25T14:32:18.421Z",
3  "severity_text": "ERROR",
4  "severity_number": 17,
5  "body": "payment authorization failed",
6  "trace_id": "4bf92f3577b34da6a3ce929d0e0e4736",
7  "span_id": "00f067aa0ba902b7",
8  "resource": {
9    "attributes": {
10      "service.name": "checkout-api",
11      "service.version": "1.18.4",
12      "deployment.environment": "production",
13      "cloud.region": "eu-central-1",
14      "k8s.namespace.name": "commerce",
15      "k8s.pod.name": "checkout-api-7d9c8f7d9b-r2qmk"
16    }
17  },
18  "attributes": {
19    "http.method": "POST",
20    "http.route": "/checkout",
21    "http.status_code": 502,
22    "payment.provider": "stripe",
23    "error.type": "ProviderTimeout"
24  }
25}

This is an original OTel-style example for showing field shape, not a copied payload from a vendor doc.

Readable row after ingest
output
14:32:18.421Z ERROR checkout-api production payment authorization failed trace=4bf92f3577b34da6a3ce929d0e0e4736 span=00f067aa0ba902b7 route=POST /checkout status=502 provider=stripe error=ProviderTimeout

The row should stay readable while trace, service, route, status, provider, and error fields remain available for filtering.

Log shape

Practical OpenTelemetry Log Shape

Start with one log event that keeps a readable body, severity fields, trace identifiers, and resource attributes.

01

Use a readable body and structured attributes

Keep the main message in body, then put queryable detail in attributes. That avoids turning the log message into a long sentence full of key-value fragments.

OTel-style log event
json
1{
2  "timestamp": "2026-04-25T14:32:18.421Z",
3  "severity_text": "ERROR",
4  "severity_number": 17,
5  "body": "payment authorization failed",
6  "trace_id": "4bf92f3577b34da6a3ce929d0e0e4736",
7  "span_id": "00f067aa0ba902b7",
8  "resource": {
9    "attributes": {
10      "service.name": "checkout-api",
11      "deployment.environment": "production",
12      "service.version": "1.18.4"
13    }
14  },
15  "attributes": {
16    "http.route": "/checkout",
17    "http.status_code": 502,
18    "error.type": "ProviderTimeout"
19  }
20}
Readable row after ingest
output
14:32:18.421Z ERROR checkout-api production payment authorization failed trace=4bf92f3577b34da6a3ce929d0e0e4736 route=/checkout status=502 error=ProviderTimeout

The readable row does not need every attribute inline. It needs enough context to scan the event and keep the remaining fields available for filtering.

02

Use trace context for multi-service failures

The same trace ID can connect frontend, API, inventory, payment, and worker logs into one request path.

One trace across services
output
trace=4bf92f3577b34da6a3ce929d0e0e4736 service=frontend-web checkout submitted
trace=4bf92f3577b34da6a3ce929d0e0e4736 service=checkout-api validating cart
trace=4bf92f3577b34da6a3ce929d0e0e4736 service=inventory-api reserved inventory
trace=4bf92f3577b34da6a3ce929d0e0e4736 service=checkout-api payment authorization failed

Without trace_id, those rows are separate events. With trace context, they become one failure path.

OTel example

Keep trace context visible without hiding the log message

An OpenTelemetry-style log event can carry a human-readable body, severity fields, trace identifiers, resource attributes, and queryable event attributes.

Fluxtail live tail showing active log rows in the product.

OTel-style log event
json
1{
2  "timestamp": "2026-04-25T14:32:18.421Z",
3  "severity_text": "ERROR",
4  "severity_number": 17,
5  "body": "payment authorization failed",
6  "trace_id": "4bf92f3577b34da6a3ce929d0e0e4736",
7  "span_id": "00f067aa0ba902b7",
8  "resource": {
9    "attributes": {
10      "service.name": "checkout-api",
11      "service.version": "1.18.4",
12      "deployment.environment": "production",
13      "cloud.region": "eu-central-1",
14      "k8s.namespace.name": "commerce",
15      "k8s.pod.name": "checkout-api-7d9c8f7d9b-r2qmk"
16    }
17  },
18  "attributes": {
19    "http.method": "POST",
20    "http.route": "/checkout",
21    "http.status_code": 502,
22    "payment.provider": "stripe",
23    "error.type": "ProviderTimeout"
24  }
25}

This is an original OTel-style example for showing field shape, not a copied payload from a vendor doc.

Readable row after ingest
output
14:32:18.421Z ERROR checkout-api production payment authorization failed trace=4bf92f3577b34da6a3ce929d0e0e4736 span=00f067aa0ba902b7 route=POST /checkout status=502 provider=stripe error=ProviderTimeout

The row should stay readable while trace, service, route, status, provider, and error fields remain available for filtering.

Fields

What To Preserve In OTel Logging

OpenTelemetry logging is easier to use when the same fields appear consistently across services and runtimes.

01

Service and environment

Preserve service.name and deployment.environment on every log record. They separate production from non-production noise and make service-level filtering reliable.

02

Severity and body

Keep severity_text and severity_number consistent, and keep body human-readable. Put queryable details in attributes instead of hiding the event in prose.

03

Trace and span identifiers

Preserve trace_id and span_id when available so logs can be grouped with the request, job, or span that produced them.

04

Runtime and event attributes

Keep pod, namespace, host, version, region, route, status code, provider, retry count, and error type fields when they help narrow a failure.

OTel example

Keep trace context visible without hiding the log message

An OpenTelemetry-style log event can carry a human-readable body, severity fields, trace identifiers, resource attributes, and queryable event attributes.

Fluxtail live tail showing active log rows in the product.

OTel-style log event
json
1{
2  "timestamp": "2026-04-25T14:32:18.421Z",
3  "severity_text": "ERROR",
4  "severity_number": 17,
5  "body": "payment authorization failed",
6  "trace_id": "4bf92f3577b34da6a3ce929d0e0e4736",
7  "span_id": "00f067aa0ba902b7",
8  "resource": {
9    "attributes": {
10      "service.name": "checkout-api",
11      "service.version": "1.18.4",
12      "deployment.environment": "production",
13      "cloud.region": "eu-central-1",
14      "k8s.namespace.name": "commerce",
15      "k8s.pod.name": "checkout-api-7d9c8f7d9b-r2qmk"
16    }
17  },
18  "attributes": {
19    "http.method": "POST",
20    "http.route": "/checkout",
21    "http.status_code": 502,
22    "payment.provider": "stripe",
23    "error.type": "ProviderTimeout"
24  }
25}

This is an original OTel-style example for showing field shape, not a copied payload from a vendor doc.

Readable row after ingest
output
14:32:18.421Z ERROR checkout-api production payment authorization failed trace=4bf92f3577b34da6a3ce929d0e0e4736 span=00f067aa0ba902b7 route=POST /checkout status=502 provider=stripe error=ProviderTimeout

The row should stay readable while trace, service, route, status, provider, and error fields remain available for filtering.

Fluxtail reading

Reading OpenTelemetry Logs In Fluxtail

Fluxtail receives OTel-style telemetry logs and keeps common fields visible and searchable when present.

01

Start with live tail and filters

Watch recent OpenTelemetry logs as they arrive, then filter by service.name, severity, stream, environment, host, trace_id, span_id, or custom attributes.

02

Use facets and histograms for patterns

Facets show which services, routes, providers, error types, or pods dominate a problem. Histograms show whether the failure is a spike, a slow climb, or a one-off event.

03

Use alerts, MCP diagnostics, and AI chat after narrowing the stream

Create alerts around severity, service, message patterns, or structured fields. MCP diagnostics can inspect streams, find exceptions, summarize errors, explain missing logs, and check receiver health. AI chat can summarize dense telemetry windows while the original rows remain available.

OTel example

Keep trace context visible without hiding the log message

An OpenTelemetry-style log event can carry a human-readable body, severity fields, trace identifiers, resource attributes, and queryable event attributes.

Fluxtail live tail showing active log rows in the product.

OTel-style log event
json
1{
2  "timestamp": "2026-04-25T14:32:18.421Z",
3  "severity_text": "ERROR",
4  "severity_number": 17,
5  "body": "payment authorization failed",
6  "trace_id": "4bf92f3577b34da6a3ce929d0e0e4736",
7  "span_id": "00f067aa0ba902b7",
8  "resource": {
9    "attributes": {
10      "service.name": "checkout-api",
11      "service.version": "1.18.4",
12      "deployment.environment": "production",
13      "cloud.region": "eu-central-1",
14      "k8s.namespace.name": "commerce",
15      "k8s.pod.name": "checkout-api-7d9c8f7d9b-r2qmk"
16    }
17  },
18  "attributes": {
19    "http.method": "POST",
20    "http.route": "/checkout",
21    "http.status_code": 502,
22    "payment.provider": "stripe",
23    "error.type": "ProviderTimeout"
24  }
25}

This is an original OTel-style example for showing field shape, not a copied payload from a vendor doc.

Readable row after ingest
output
14:32:18.421Z ERROR checkout-api production payment authorization failed trace=4bf92f3577b34da6a3ce929d0e0e4736 span=00f067aa0ba902b7 route=POST /checkout status=502 provider=stripe error=ProviderTimeout

The row should stay readable while trace, service, route, status, provider, and error fields remain available for filtering.

OTel and OTLP

OpenTelemetry Logging vs OTLP Logs

OpenTelemetry logging and OTLP are related, but they answer different implementation questions.

01

OpenTelemetry logging is about event context

Use this page for the field model: service identity, resource context, severity, body, trace_id, span_id, and readable log records.

02

OTLP logs are about transport and receiver setup

Use the OTLP logs page when collectors or emitters need endpoint, payload, and receiver details for sending logs into Fluxtail.

03

OpenTelemetry can sit beside other sources

OTel logs can land next to HTTP app logs, Syslog, GELF, Kubernetes collectors, and Fluent Bit streams in the same Fluxtail account.

OTel example

Keep trace context visible without hiding the log message

An OpenTelemetry-style log event can carry a human-readable body, severity fields, trace identifiers, resource attributes, and queryable event attributes.

Fluxtail live tail showing active log rows in the product.

OTel-style log event
json
1{
2  "timestamp": "2026-04-25T14:32:18.421Z",
3  "severity_text": "ERROR",
4  "severity_number": 17,
5  "body": "payment authorization failed",
6  "trace_id": "4bf92f3577b34da6a3ce929d0e0e4736",
7  "span_id": "00f067aa0ba902b7",
8  "resource": {
9    "attributes": {
10      "service.name": "checkout-api",
11      "service.version": "1.18.4",
12      "deployment.environment": "production",
13      "cloud.region": "eu-central-1",
14      "k8s.namespace.name": "commerce",
15      "k8s.pod.name": "checkout-api-7d9c8f7d9b-r2qmk"
16    }
17  },
18  "attributes": {
19    "http.method": "POST",
20    "http.route": "/checkout",
21    "http.status_code": 502,
22    "payment.provider": "stripe",
23    "error.type": "ProviderTimeout"
24  }
25}

This is an original OTel-style example for showing field shape, not a copied payload from a vendor doc.

Readable row after ingest
output
14:32:18.421Z ERROR checkout-api production payment authorization failed trace=4bf92f3577b34da6a3ce929d0e0e4736 span=00f067aa0ba902b7 route=POST /checkout status=502 provider=stripe error=ProviderTimeout

The row should stay readable while trace, service, route, status, provider, and error fields remain available for filtering.

Related

Related Log Destinations And Use Cases

OpenTelemetry logging often appears beside broader log management, log aggregation, Kubernetes logging, and AI log analysis needs.

01

Central log management

Use the log management page when structured telemetry logs need to sit beside application, host, and collector logs in one account.

02

Log aggregation

Use the log aggregation page when multiple services, collectors, environments, or protocols need one central log destination.

03

Kubernetes logging

Use the Kubernetes logging page when pod, namespace, node, and collector metadata are part of the OpenTelemetry log context.

OTel example

Keep trace context visible without hiding the log message

An OpenTelemetry-style log event can carry a human-readable body, severity fields, trace identifiers, resource attributes, and queryable event attributes.

Fluxtail live tail showing active log rows in the product.

OTel-style log event
json
1{
2  "timestamp": "2026-04-25T14:32:18.421Z",
3  "severity_text": "ERROR",
4  "severity_number": 17,
5  "body": "payment authorization failed",
6  "trace_id": "4bf92f3577b34da6a3ce929d0e0e4736",
7  "span_id": "00f067aa0ba902b7",
8  "resource": {
9    "attributes": {
10      "service.name": "checkout-api",
11      "service.version": "1.18.4",
12      "deployment.environment": "production",
13      "cloud.region": "eu-central-1",
14      "k8s.namespace.name": "commerce",
15      "k8s.pod.name": "checkout-api-7d9c8f7d9b-r2qmk"
16    }
17  },
18  "attributes": {
19    "http.method": "POST",
20    "http.route": "/checkout",
21    "http.status_code": 502,
22    "payment.provider": "stripe",
23    "error.type": "ProviderTimeout"
24  }
25}

This is an original OTel-style example for showing field shape, not a copied payload from a vendor doc.

Readable row after ingest
output
14:32:18.421Z ERROR checkout-api production payment authorization failed trace=4bf92f3577b34da6a3ce929d0e0e4736 span=00f067aa0ba902b7 route=POST /checkout status=502 provider=stripe error=ProviderTimeout

The row should stay readable while trace, service, route, status, provider, and error fields remain available for filtering.

OTel example

Keep trace context visible without hiding the log message

An OpenTelemetry-style log event can carry a human-readable body, severity fields, trace identifiers, resource attributes, and queryable event attributes.

Fluxtail live tail showing active log rows in the product.

OTel-style log event
json
1{
2  "timestamp": "2026-04-25T14:32:18.421Z",
3  "severity_text": "ERROR",
4  "severity_number": 17,
5  "body": "payment authorization failed",
6  "trace_id": "4bf92f3577b34da6a3ce929d0e0e4736",
7  "span_id": "00f067aa0ba902b7",
8  "resource": {
9    "attributes": {
10      "service.name": "checkout-api",
11      "service.version": "1.18.4",
12      "deployment.environment": "production",
13      "cloud.region": "eu-central-1",
14      "k8s.namespace.name": "commerce",
15      "k8s.pod.name": "checkout-api-7d9c8f7d9b-r2qmk"
16    }
17  },
18  "attributes": {
19    "http.method": "POST",
20    "http.route": "/checkout",
21    "http.status_code": 502,
22    "payment.provider": "stripe",
23    "error.type": "ProviderTimeout"
24  }
25}

This is an original OTel-style example for showing field shape, not a copied payload from a vendor doc.

Readable row after ingest
output
14:32:18.421Z ERROR checkout-api production payment authorization failed trace=4bf92f3577b34da6a3ce929d0e0e4736 span=00f067aa0ba902b7 route=POST /checkout status=502 provider=stripe error=ProviderTimeout

The row should stay readable while trace, service, route, status, provider, and error fields remain available for filtering.

Related

Related pages

Related page
OTLP logs

Send OTLP logs from OpenTelemetry SDKs or Collectors into Fluxtail. Learn what fields to preserve and how to verify ingestion.
Related page
Log management

Centralized log management with readable live tail, clear streams, and straightforward ingest.
Related page
Log aggregation

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

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

Use Fluxtail for AI-assisted log analysis through MCP and built-in AI chat while keeping the raw logs available for verification.
Next step

Send one real source and read the logs

The fastest check is to point one real source at Fluxtail and see whether the resulting stream is easier to read.

Point one real source at Fluxtail.

Create a receiver, send one source, and inspect the first stream.

Start free View pricing