Use case / OpenTelemetry

OpenTelemetry Application Logs With Trace Context

OpenTelemetry application logs are most useful when service name, environment, severity, trace ID, span ID, and resource attributes survive collection. Fluxtail receives OTLP logs into streams so application events stay readable with live tail, filters, facets, histograms, alerts, MCP diagnostics, and AI chat.

OpenTelemetry application logs OTLP logs Trace context Service context

Start free View pricing

Keep service context attached

Preserve service.name, service.version, deployment.environment, severity, and resource attributes.

Connect logs to traces

Trace IDs and span IDs can be preserved and filtered when logs are created inside traced requests.

Use OTLP beside other sources

OTLP logs can sit next to HTTP, Syslog, GELF, Docker, Kubernetes, and Fluent Bit sources.

Analyze structured fields

Filters, facets, histograms, alerts, MCP diagnostics, and AI chat work best when telemetry fields remain structured.

Source

When this source should be centralized

Use this path when the source already emits logs and central reading, filtering, or alerting is the next need.

01

Services already emit OpenTelemetry logs

Use this path when application logs already carry service names, resource attributes, severity, trace IDs, span IDs, or deployment context.

02

Logs need request context

Trace IDs, span IDs, service names, routes, and error codes make one request easier to follow across services.

03

OTLP logs should sit beside other sources

OpenTelemetry logs can share an account with HTTP app logs, Syslog, GELF, Docker, Kubernetes, and Fluent Bit sources.

Shape

Example OTLP log record

The exact payload can vary by SDK and collector. The useful result keeps service, severity, resource, trace, span, and application fields attached to the same event.

OTLP-style application log

json

1{
2  "time_unix_nano": "1777126350421000000",
3  "severity_text": "ERROR",
4  "body": "payment authorization timed out",
5  "resource": {
6    "service.name": "checkout-api",
7    "service.version": "2026.04.25",
8    "deployment.environment": "production"
9  },
10  "attributes": {
11    "http.route": "POST /api/checkout",
12    "order_id": "ord_4921",
13    "error_code": "PAYMENT_GATEWAY_TIMEOUT"
14  },
15  "trace_id": "4bf92f3577b34da6a3ce929d0e0e4736",
16  "span_id": "00f067aa0ba902b7"
17}

OTLP log collection path

text

1application SDK
2  -> OpenTelemetry Collector
3  -> OTLP logs export
4  -> Fluxtail receiver
5  -> stream with live tail, filters, facets, histograms, and alerts

Readable telemetry row

output

2026-04-25T14:12:30Z ERROR checkout-api production trace=4bf92f3577b34da6a3ce929d0e0e4736 payment authorization timed out

Fields

Fields OpenTelemetry Logs Should Preserve

OpenTelemetry logs are easier to read when the fields used for service and request context survive ingestion.

01

Resource fields

Keep service.name, service.version, deployment.environment, cloud or Kubernetes resource attributes, and any source labels that explain where the event came from.

02

Log fields

Keep severity_text, body or message, timestamp, trace_id, span_id, route, error_code, and application fields used for filtering.

03

Good OTLP filters

Start with service.name, deployment.environment, severity_text, trace_id, span_id, http.route, and error_code.

Useful OTLP filters

text

1service.name = checkout-api
2deployment.environment = production
3severity_text = ERROR
4trace_id = 4bf92f3577b34da6a3ce929d0e0e4736
5error_code = PAYMENT_GATEWAY_TIMEOUT

Reading

Reading OpenTelemetry Logs in Fluxtail

After OTLP logs arrive, use live tail for fresh events, filters for one service or trace, facets for top error codes and services, histograms for spikes, alerts for repeated failures, and MCP diagnostics or AI chat after the stream is narrowed.

01

Use streams for service boundaries

Route telemetry logs into streams that match services, environments, product areas, or clusters.

02

Use facets and histograms before summaries

Facets show which services, severities, routes, and error codes dominate a window. Histograms show when the spike started and whether it is still active.

Setup

How logs move into Fluxtail

Keep the sender configuration explicit, then confirm the resulting stream keeps the fields needed for reading and filtering.

01

Emit structured application logs

Send logs from the application or SDK with severity, message, service name, resource attributes, trace ID, and span ID when available.

02

Forward through OTLP

Use OpenTelemetry Collector or another OTLP-capable path to send logs to a Fluxtail receiver.

03

Preserve context as fields

Keep service.name, deployment.environment, severity_text, trace_id, span_id, route, and error_code available for filtering.

04

Read the resulting stream

Use live tail, filters, facets, histograms, alerts, MCP diagnostics, and AI chat after the OTLP logs arrive.

Shape

Example OTLP log record

The exact payload can vary by SDK and collector. The useful result keeps service, severity, resource, trace, span, and application fields attached to the same event.

OTLP-style application log

json

1{
2  "time_unix_nano": "1777126350421000000",
3  "severity_text": "ERROR",
4  "body": "payment authorization timed out",
5  "resource": {
6    "service.name": "checkout-api",
7    "service.version": "2026.04.25",
8    "deployment.environment": "production"
9  },
10  "attributes": {
11    "http.route": "POST /api/checkout",
12    "order_id": "ord_4921",
13    "error_code": "PAYMENT_GATEWAY_TIMEOUT"
14  },
15  "trace_id": "4bf92f3577b34da6a3ce929d0e0e4736",
16  "span_id": "00f067aa0ba902b7"
17}

OTLP log collection path

text

1application SDK
2  -> OpenTelemetry Collector
3  -> OTLP logs export
4  -> Fluxtail receiver
5  -> stream with live tail, filters, facets, histograms, and alerts

Readable telemetry row

output

2026-04-25T14:12:30Z ERROR checkout-api production trace=4bf92f3577b34da6a3ce929d0e0e4736 payment authorization timed out

Verification

What to check before relying on it

Collection is useful only when the resulting rows still carry enough context to search, filter, and alert on.

01

Confirm a test OTLP log appears

Send one known application log and confirm it appears in the expected stream with service.name, deployment.environment, severity_text, message, and resource fields.

02

Filter by service and trace

Confirm service.name, trace_id, span_id, route, and error_code filters work when those fields are present.

03

Check severity and analysis

Facets should show services, severities, routes, and error codes. Histograms should show log volume and error spikes over time. Alerts can target service, severity, route, or error_code.

Shape

Example OTLP log record

The exact payload can vary by SDK and collector. The useful result keeps service, severity, resource, trace, span, and application fields attached to the same event.

OTLP-style application log

json

1{
2  "time_unix_nano": "1777126350421000000",
3  "severity_text": "ERROR",
4  "body": "payment authorization timed out",
5  "resource": {
6    "service.name": "checkout-api",
7    "service.version": "2026.04.25",
8    "deployment.environment": "production"
9  },
10  "attributes": {
11    "http.route": "POST /api/checkout",
12    "order_id": "ord_4921",
13    "error_code": "PAYMENT_GATEWAY_TIMEOUT"
14  },
15  "trace_id": "4bf92f3577b34da6a3ce929d0e0e4736",
16  "span_id": "00f067aa0ba902b7"
17}

OTLP log collection path

text

1application SDK
2  -> OpenTelemetry Collector
3  -> OTLP logs export
4  -> Fluxtail receiver
5  -> stream with live tail, filters, facets, histograms, and alerts

Readable telemetry row

output

2026-04-25T14:12:30Z ERROR checkout-api production trace=4bf92f3577b34da6a3ce929d0e0e4736 payment authorization timed out

Shape

Example OTLP log record

The exact payload can vary by SDK and collector. The useful result keeps service, severity, resource, trace, span, and application fields attached to the same event.

OTLP-style application log

json

1{
2  "time_unix_nano": "1777126350421000000",
3  "severity_text": "ERROR",
4  "body": "payment authorization timed out",
5  "resource": {
6    "service.name": "checkout-api",
7    "service.version": "2026.04.25",
8    "deployment.environment": "production"
9  },
10  "attributes": {
11    "http.route": "POST /api/checkout",
12    "order_id": "ord_4921",
13    "error_code": "PAYMENT_GATEWAY_TIMEOUT"
14  },
15  "trace_id": "4bf92f3577b34da6a3ce929d0e0e4736",
16  "span_id": "00f067aa0ba902b7"
17}

OTLP log collection path

text

1application SDK
2  -> OpenTelemetry Collector
3  -> OTLP logs export
4  -> Fluxtail receiver
5  -> stream with live tail, filters, facets, histograms, and alerts

Readable telemetry row

output

2026-04-25T14:12:30Z ERROR checkout-api production trace=4bf92f3577b34da6a3ce929d0e0e4736 payment authorization timed out

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

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

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

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

Centralized log management with readable live tail, clear streams, and straightforward ingest.

Use AI log diagnostics with Fluxtail MCP tools and AI chat to summarize errors, find exceptions, check receiver health, and explain missing logs.

Python logging best practices for readable production logs, cleaner incident triage, and a smoother path into centralized logging.

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

OpenTelemetry Application Logs With Trace Context

When this source should be centralized

Services already emit OpenTelemetry logs

Logs need request context

OTLP logs should sit beside other sources

Example OTLP log record

Fields OpenTelemetry Logs Should Preserve

Resource fields

Log fields

Good OTLP filters

Reading OpenTelemetry Logs in Fluxtail

Use streams for service boundaries

Use facets and histograms before summaries

How logs move into Fluxtail

Emit structured application logs

Forward through OTLP

Preserve context as fields

Read the resulting stream

Example OTLP log record

What to check before relying on it

Confirm a test OTLP log appears

Filter by service and trace

Check severity and analysis

Example OTLP log record

Example OTLP log record

Related pages

Send one real source and read the logs