What's the relationship between distributed traces and structured logs — should trace IDs actually be injected into log lines, and why?

Yes — injecting the active trace ID (and span ID) into every log line a service emits is one of the highest-value, lowest-cost observability practices, because it directly links two signals that are each individually incomplete: a trace shows the timeline and structure of a request across services but typically carries limited detail per span; logs carry rich, detailed information but, without a trace ID, are hard to correlate across services for a single request. Injecting the trace ID means you can start from either signal and jump directly to the other for the exact same request.

Traces and logs solve different, complementary problems, as covered in the base logs-vs-metrics-vs-traces comparison — a trace shows where in a distributed system a request spent its time and where it failed, structured as a timeline across services; logs show rich detail about what happened at a specific point, but are normally scoped per-service, with no inherent way to know which log lines across different services all belong to the same originating request.

Injecting the current trace ID into every log line a service emits (typically as a structured field, trace_id: <id>, alongside whatever else the log line already carries) closes that gap directly: starting from a trace that shows a slow or failed span in some specific service, you can search that service's logs for the exact trace ID and immediately find the detailed log output specific to that exact request — no need to guess at timestamps or manually correlate based on approximate timing, which is error-prone and slow, especially under concurrent load where many similar requests might be happening within the same narrow time window. The reverse direction also works: starting from an alarming log line (an error, an exception), the trace ID it carries lets you jump directly to the full distributed trace for that exact request, seeing the complete cross-service context around where and why that log line was emitted.

This is a genuinely cheap practice to implement relative to its value — most structured logging libraries support adding a field easily, and most tracing libraries (including OpenTelemetry) expose the current active trace/span ID via context that can be read and injected at the logging call site, often via automatic integration between the logging and tracing libraries rather than requiring manual plumbing at every single log call. Given the cost is low and the correlation value is high, this is widely considered close to a default best practice once both structured logging and tracing exist in a system, rather than an optional nice-to-have — the alternative (logs and traces existing as two disconnected signals) leaves real debugging value on the table for very little reason.

• Trace IDs injected into log lines directly link two individually-incomplete signals — a trace's cross-service timeline and logs' rich per-event detail.
• This lets you jump from a specific trace span directly to the exact log lines for that request, or from an alarming log line directly to its full distributed trace.
• Most structured logging and tracing libraries support this integration with low implementation effort, often via automatic context propagation rather than manual plumbing.
• Given the low cost and high correlation value, this is close to a default best practice once both structured logging and tracing exist in a system.

• OpenTelemetry: Correlating traces and logs
• OpenTelemetry: Logs