What Is a Trace ID?

Last verified on Nov 8, 2026.

A trace ID is the identifier shared by every span in one distributed trace. Services pass it along with the request, so every operation the request triggers can be found by searching for that one value. Put it in your log lines and a log search becomes a way to pull up the full story of a request.

What a Trace ID Looks Like

The W3C Trace Context standard defines it as a 16-byte array, written as 32 lowercase hexadecimal characters. All zeros is invalid, and a service that receives a traceparent header with an invalid trace ID must ignore the header. Here is a complete header:

traceparent: 00-0af7651916cd43dd8448eb211c80319c-b7ad6b7169203331-01
             |  |                                |                |
             |  trace ID (32 hex)                |                trace flags
             version                             parent ID (16 hex)

The middle field of the header is the 8-byte ID of the calling span, which becomes the parent of the next one. OpenTelemetry's trace documentation shows the same relationship in span data: every span in the trace carries the same trace_id, a child carries its parent's span_id as parent_id, and the root span has no parent.

Trace ID vs Span ID vs Request ID

Not every platform ID is a W3C trace ID. An AWS Application Load Balancer writes X-Amzn-Trace-Id with a Root field made of a version, an 8-digit epoch time, and 24 hex digits, which is a different shape. See correlation ID for how these edge IDs fit with trace IDs.

Getting the Trace ID into Your Logs

OpenTelemetry's log data model has optional TraceId and SpanId fields, and says TraceId SHOULD be set whenever SpanId is. For Node.js, the OpenTelemetry pino instrumentation adds trace_id, span_id, and trace_flags to any record written inside a span. If you manage the logger yourself, a mixin does the same job. This ran against pino and the OpenTelemetry Node tracer:

const pino = require('pino')
const { trace } = require('@opentelemetry/api')

const logger = pino({
  mixin() {
    const span = trace.getActiveSpan()
    if (!span) return {}
    const { traceId, spanId, traceFlags } = span.spanContext()
    return { trace_id: traceId, span_id: spanId, trace_flags: '0' + traceFlags.toString(16) }
  },
})

Inside an active span, logger.info({ order_id: 'o_123' }, 'charging card') writes:

{
  "level": 30,
  "trace_id": "fccb5187901fc3f49018c3f9164bb62c",
  "span_id": "a99b79ab96f7e479",
  "trace_flags": "01",
  "order_id": "o_123",
  "msg": "charging card"
}

Outside a span, the mixin adds nothing, which is the first thing to check when a log line has no trace ID. The Pino logger guide covers the rest of the setup, and the OpenTelemetry Node.js guide covers tracing.

Common Problems

• A new trace starts at every hop. The caller did not send traceparent, a proxy dropped it, or the value was malformed. The spec says to restart the trace when the header cannot be parsed.
• Logs have no trace ID. The log call ran outside an active span, often in a callback that lost context.
• IDs from outside your system. OpenTelemetry advises caution with incoming context, because forged trace headers can pollute your traces. Consider ignoring them at your public edge.
• A trace ID with no spans behind it. The trace flags carry the caller's sampling recommendation, and flag 00 means the caller did not record the trace. The ID still appears in logs. See trace sampling.
• Uppercase hex. The header format is lowercase.

Trace IDs in Sazabi

Sazabi, an AI-native observability and security platform, stores each OpenTelemetry span as a searchable record that carries its trace and span IDs, and its docs say you can search logs by trace ID to pull spans and correlated log lines together. Sazabi ingests OpenTelemetry metrics (Prometheus metrics through an OpenTelemetry Collector) and OTLP traces through the same intake as your logs. It stores each metric data point and each span as a log record that its agent queries alongside your logs, so there is no separate metrics store to run. See sending traces for setup, and use trace IDs to follow up on latency spikes or tail latency.