Trace correlation for logs

Overview

A log line is far more useful when you know which request produced it. Osuite correlates logs with traces automatically whenever a record carries a trace_id and span_id. No manual timestamp matching, and no separate correlation step.

How it works

When your application emits a log inside a traced request, the active trace_id and span_id are attached to the log record. Osuite indexes both fields, which lets you move between the two signals in either direction:

• In the Logs Explorer, filter by trace_id to see every log emitted during a single request, in order.
• In the Trace view, open the “Related logs” panel on any span to read the logs that span emitted, in context with its timing.

Getting trace context onto your logs

Correlation depends on the trace_id being present on the record. There are two reliable ways to get it there:

• OpenTelemetry SDK bridge — bridge your existing logger to the OpenTelemetry SDK. The SDK reads the active span from context and stamps every record with its trace_id and span_id. Your logger.info(...) calls do not change. This is the recommended path — see Collect application logs and the per-language guides under Instrumentation.
• Structured log fields parsed by the Collector — if your application already writes trace_id and span_id into its structured log lines, parse them out in the Collector and promote them to the record’s trace fields. This works for file-based logs but requires the application to inject the IDs itself.

Requirements

• The service must be instrumented for tracing, so there is an active span to read the context from. See APM & Tracing.
• The logger must run through the OpenTelemetry SDK bridge, or the log lines must already contain the trace and span IDs for the Collector to parse.

Logs collected from infrastructure — a bare filelog tail, Docker stdout, syslog — carry no trace context unless the application wrote the IDs into the log body. Application-level instrumentation is what makes correlation work end to end.