What is a Span in Distributed Tracing?

A span is the fundamental building block of distributed tracing: a single named, timed operation within a request — an HTTP handler executing, a SQL query running, a message being published. Every span belongs to a trace, and the spans of a trace form a parent-child tree that mirrors the request’s actual call structure.

Anatomy of a span

Each span (as defined by OpenTelemetry) carries:

• Name — the operation, e.g. GET /api/orders or SELECT orders
• Trace ID — shared by every span in the same request
• Span ID and parent span ID — position in the tree
• Start time and duration — precise timing
• Attributes — key-value context: http.status_code, db.system, net.peer.name
• Events — timestamped moments within the span, such as an exception with its stack trace
• Status — OK or error
• Kind — server, client, producer, consumer, or internal

Spans vs traces

Think of the trace as the story and spans as its sentences. The root span covers the entire request; each downstream call adds a child. Gaps between a parent’s duration and its children’s durations reveal time spent in the service’s own code — often the surprise culprit in latency investigations.

Working with spans effectively

• Name spans by operation pattern (GET /users/:id), never by unique values, or you’ll create unbounded name cardinality
• Follow OpenTelemetry semantic conventions for attribute names so backends can compute service maps and RED metrics automatically
• Record exceptions as span events — it ties stack traces to the exact operation that failed
• At high volume, choose a sampling strategy that always keeps error and slow-path spans

Spans in OpenObserve

OpenObserve ingests OpenTelemetry spans over OTLP, renders them as waterfall trace views in Traces, and lets you query span attributes with SQL — so “all spans where db.statement took >500ms for tenant X” is one query, not an archaeology project.