# What is a Span in Distributed Tracing?

> A span is the basic unit of a distributed trace - one named, timed operation with attributes, events, and a parent - and a trace is the tree of spans a single request produces.

Source: https://openobserve.ai/glossary/what-is-a-span/
Published: 2026-07-08
Term: Span
Category: Tracing & APM
Related terms: what-is-distributed-tracing, what-is-otlp, what-is-opentelemetry-collector

---

A **span** is the fundamental building block of [distributed tracing](/glossary/what-is-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](/blog/head-and-tail-based-sampling/) that always keeps error and slow-path spans

## Spans in OpenObserve

OpenObserve ingests OpenTelemetry spans over [OTLP](/glossary/what-is-otlp/), renders them as waterfall trace views in [Traces](/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.