The APM and Distributed Tracing Glossary: 35 Terms Every Backend Engineer Should Know

Two years into running backend services, I thought I understood tracing. Spans go in, traces come out, service maps show where stuff breaks. Then someone asked me to explain the difference between B3 and W3C trace context propagation — and I realized I'd been nodding along in meetings without actually knowing what half the vocabulary meant.

APM and distributed tracing have their own dialect. Baggage, exemplars, sampling strategies, instrumentation modes — most of it gets learned through osmosis during incidents when you're already stressed.

(My first head-based vs tail-based sampling conversation ended with me pretending my video froze. Still cringe about it.)

This is the glossary I wish existed when I started. 35 terms, plain English, focused on tracing-specific vocabulary. For broader observability definitions — SLIs, SLOs, cardinality, golden signals — check our 50-term observability glossary.

The Fundamentals (1-8)

1. Span

The atomic unit of a distributed trace. One span = one operation: an HTTP handler, database query, function call, or message queue publish. Spans have start time, duration, name, span ID, parent span ID, status, attributes, and events. Think of them as stack frames, but distributed across services.

2. Trace

A tree of spans representing one request's journey through your system. A checkout might generate 15 spans across 6 services — all connected by parent-child relationships, all sharing one trace ID. Traces show causality: why things happened in what order.

3. Trace ID

The unique identifier shared by every span in a trace. Most systems use 128-bit hex: 0af7651916cd43dd8448eb211c80319c. Without trace IDs, you can't correlate spans across services.

4. Span ID

Unique identifier for a single span. Typically 64-bit hex: b7ad6b7169203331. Combined with trace ID and parent span ID, you can reconstruct the entire span tree.

5. Parent Span ID

Links a span to its caller. If Span B was triggered by Span A, Span B's parent ID is Span A's span ID. Root spans have no parent.

6. Root Span

The first span in a trace, created at your system's entry point. Sets the trace ID. Everything else descends from it.

7. Child Span

Any span that isn't the root. The parent-child relationship shows that the slow database query inside the payment service was caused by the checkout API call.

8. Span Attributes

Key-value metadata attached to spans. Standard attributes: http.method, http.status_code, db.system, db.statement. Custom: user.id, order.id. Attributes make spans queryable: "Show spans where db.system=postgresql AND duration > 500ms."

Sampling and Volume Control (9-16)

9. Sampling

Keeping only a percentage of traces. At 10,000 requests per second, storing every trace is prohibitively expensive. Sample rates vary: 1% for high-traffic endpoints, 100% for critical paths. The tradeoff is cost vs completeness — something we dig into in our observability pricing breakdown.

Honestly, I hate sampling. Every time I'm debugging production and the relevant trace was discarded, I die a little inside.

10. Head-Based Sampling

Making the sampling decision at trace start. Before the first span completes, flip a coin. The decision propagates downstream via headers. Simple, but you might discard traces that turn out interesting.

11. Tail-Based Sampling

Making the decision after the trace completes. Buffer spans, evaluate the full trace (errors? high latency?), then decide. Smarter retention — keep 100% of errors — but requires more infrastructure.

12. Probabilistic Sampling

Keeping traces based on random probability. "10% of all traces" = 0.1 rate. Usually deterministic via trace ID hashing so the same trace gets the same decision across services. Otherwise you'd get partial traces everywhere. Ask me how I know.

13. Rate Limiting

Capping traces per time period. "Max 100 traces/second." Guarantees cost caps but produces inconsistent effective sample rates.

14. Priority Sampling

Assigning priority levels to traces. Debug traces get dropped aggressively; critical-path traces get kept always. Services can upgrade priority mid-trace if they hit an error.

15. Adaptive Sampling

Automatically adjusting sample rates based on traffic, errors, or budget. Fancier than static probabilistic sampling but requires feedback loops.

16. Exemplar

A specific trace linked to a metric data point. When P99 shows 843ms, an exemplar lets you click that point and jump to an actual trace taking 843ms. Prometheus added support in 2022. I don't know why more teams don't use them — it changes debugging completely.

Context Propagation (17-22)

17. Context Propagation

How trace context travels across service boundaries. When Service A calls Service B, trace ID and span ID travel in headers. Without context propagation, your traces break at service boundaries.

18. W3C Trace Context

The modern standard. Two headers: traceparent (trace ID, span ID, sampling flag) and tracestate (vendor-specific data). OpenTelemetry uses it by default. If you're starting fresh, use W3C.

19. B3 Propagation

Zipkin's original format using X-B3-TraceId, X-B3-SpanId, X-B3-ParentSpanId, X-B3-Sampled. Also supports single-header format. Still common in legacy systems.

20. Baggage

Application-level key-value pairs propagated with trace context. Carries business data: user ID, tenant ID, feature flags. Every service in the trace path can read/write baggage. Use sparingly — it travels with every request. I've seen teams dump entire user objects in baggage. Don't be that team.

21. Trace State

The tracestate header for vendor-specific tracing metadata (sampling decisions, vendor flags). Different from baggage, which is for application data.

22. Injection and Extraction

The two context propagation operations. Injection writes trace context into carriers (HTTP headers). Extraction reads it out. OpenTelemetry SDKs handle this automatically for standard protocols.

Instrumentation (23-28)

23. Instrumentation

Adding observability code to create spans. No instrumentation, no spans, no data. Everything starts here.

24. Auto-Instrumentation

Agents attach to your runtime and create spans for HTTP handlers, database drivers, framework code — without code changes. Covers basics but not business logic.

JustAnalytics uses auto-instrumentation for its under-5KB script, capturing page loads, errors, and network requests automatically. For backend tracing, OpenTelemetry SDKs integrate with most frameworks.

25. Manual Instrumentation

Explicitly creating spans with SDK calls. You control where spans start, end, and what attributes attach. More work, but captures exactly what matters to your business.

26. Instrumentation Library

Pre-packaged instrumentation for frameworks. opentelemetry-instrumentation-flask, opentelemetry-instrumentation-psycopg2. Good libraries follow semantic conventions and handle edge cases you didn't even know existed. I tried rolling my own once. Once.

27. Semantic Conventions

Standardized attribute names from OpenTelemetry. Everyone uses http.response.status_code instead of inventing their own. Enables querying across services. See our guide to replacing your 5-tool stack for more on consistent conventions.

28. Span Processor

Components handling spans after creation. Batch processors send spans in groups for efficiency. Simple processors send immediately. Custom processors can filter, modify, or route.

Backend and Visualization (29-35)

29. Trace Backend

The system storing and querying trace data: Jaeger, Zipkin, Tempo, Datadog, Honeycomb, JustAnalytics. Backends receive spans, store them, and provide query APIs.

30. Service Map

Visualization of service dependencies from trace data. Nodes = services. Edges = which services call which, with latency and error rates. Answers "what depends on this service?" before breaking changes.

JustAnalytics generates service maps from traces automatically. Nice-to-have until you're debugging 30 microservices with no documentation.

31. Span Timeline / Gantt Chart

Horizontal bars showing when spans ran. Time on X-axis, spans stacked on Y-axis. Wide bars = slow spans. The first thing you look at when debugging latency — see our guide to finding P99 latency sources for practical examples.

32. Flame Graph

Visualization of time across function calls. Wide bands = more time. Stacked bands = call hierarchy. Typically for profiling, but some tools adapt it for distributed traces.

33. Trace Correlation

Linking traces with logs, metrics, errors, session replays. When a span errors, jump to logs from that operation. When P99 spikes, use an exemplar to find a real trace.

JustAnalytics shares session IDs across errors, traces, and replay — click from APM trace to exact session replay. ClickzProtect uses similar correlation for fraud detection.

34. Span Events

Point-in-time occurrences within a span. Exceptions, log messages. Events have timestamps but no duration — useful for marking moments without creating nested spans. For error handling specifically, see our session replay debugging guide.

35. Span Links

Connections between spans that aren't parent-child. Batch processors linking to processed messages. Async jobs linking to the queuing span. Links create non-hierarchical relationships for fire-and-forget workflows.

Honorable Mentions

TraceQL — Grafana Tempo's query language. { span.http.status_code >= 500 } finds error spans. Honestly? The syntax is cleaner than I expected from Grafana. VeloCalls uses similar trace queries for call quality debugging.

OTLP — OpenTelemetry Protocol. The wire format for telemetry. OTLP/gRPC and OTLP/HTTP variants. More in our observability glossary.

Span Metrics — Metrics derived from span data. Generate them from trace aggregates instead of instrumenting separately.

Quick Verdict

You don't need all 35 terms memorized.

One thing to learn: spans, traces, context propagation. That's the mental model.

Two things: add sampling. Head-based vs tail-based decisions drive your tracing budget.

Three things: semantic conventions. The difference between "everyone uses http.status_code" and "seven different attribute names" is queryable data vs chaos.

For how error tracking, logging, and APM fit together, see our Error Tracking vs Logging vs APM breakdown.

Frequently Asked Questions

What is the difference between a span and a trace in distributed tracing?

A span is a single unit of work — one function call, database query, or HTTP request with a start time, duration, and metadata. A trace is the full tree of spans showing how a request moved through your entire system. If a user request hits your API, queries a database, and calls a payment service, that's one trace with three spans linked by parent-child relationships.

What is the difference between head-based and tail-based sampling?

Head-based sampling decides at trace start whether to keep it — flip a coin before the first span completes. Tail-based sampling buffers all spans, evaluates the complete trace (was it slow? did it error?), and then decides. Head-based is simpler and cheaper; tail-based gives you smarter retention but requires more infrastructure.

What does context propagation mean in distributed tracing?

Context propagation is how trace identifiers travel across service boundaries. When Service A calls Service B over HTTP, trace context (trace ID, span ID, sampling flags) gets injected into headers so Service B can attach its spans to the same trace. Without context propagation, your traces break at service boundaries — you end up with disconnected orphan spans.

What is an exemplar in observability?

An exemplar links a metric data point to a specific trace. When your P99 latency spikes to 800ms, an exemplar lets you click that data point and jump directly to a real trace that took 800ms — bridging aggregate metrics to individual request details. Prometheus added exemplar support in 2022, but most teams still underuse them.

Try JustAnalytics

All-in-one observability in one under-5KB script: cookieless analytics + error tracking + APM + session replay + uptime + structured logs. Replaces GA4 + Sentry + Datadog + Pingdom + LogRocket. Free tier (100K events/mo), Pro $49/month ($39 annual).

Start free → · AI Command Center MCP