Tracing basics on Grafana Labs

What is a trace?

Tue, 04 Aug 2026 18:58:09 -0400

What is a trace?

Following one request across every service it touches, and recording the timing and relationships at each step, is called distributed tracing. The record it produces is a trace: the whole journey of one request as it moves through all the services of a distributed system.

One request, one trace

Take the slow checkout request from the last slide. As it travels its request path, tracing records each step:

A request arrives at the web service.
The web service calls the cart service to read the basket.
The cart service calls the payments service to charge the card.
Finally, the payments service calls the inventory service to reserve stock.

All of these steps belong to the same request, so they’re stitched together into one trace. Every step in that trace shares one trace ID, the identifier that marks them as part of the same request’s journey.

Why it helps

A trace is the one view that follows the request across service boundaries. You see the full path in a single place, instead of piecing it together from separate services’ logs.

What is a span?

Tue, 04 Aug 2026 18:58:09 -0400

What is a span?

Each step in that checkout trace is a span: one unit of work, with an operation name that says what it did and a duration that says how long it took. The web service handling the request is a span. The call to the payments service is a span. A trace is made of one or more spans.

Spans nest into a tree

Spans aren’t a flat list. When one operation triggers another, the second span becomes a child of the first, so the spans form a tree:

The web service span is the parent of the cart span.
The cart span is the parent of the payments span, and the payments span is the parent of the inventory span.

Each call nests inside the one that triggered it. This parent/child nesting is what shows that the payments call happened inside the web service’s handling of the request, not beside it.

Attributes: the details on a span

Each span also carries attributes: key-value details about that step, for example the HTTP method or the status code returned. When you read a trace later, attributes are what tell you what each span actually did.

Read the checkout trace as a tree of spans: the web service, cart service, payments service, and inventory service, each nested inside the call that triggered it, with a duration bar and its attributes.

When to reach for a trace

Tue, 04 Aug 2026 18:58:09 -0400

When to reach for a trace

Understanding why a system behaves the way it does by looking at the data it produces is called observability. That data comes as four signals: metrics, logs, traces, and profiles. Monitoring tells you when a known problem happens; observability helps you understand why, including problems you didn’t predict. Tracing is one of the four signals.

What each signal answers

Signal	What it is	What it answers
Metrics	Numeric measurements over time, for example error rate or latency	Is something wrong?
Logs	Timestamped records of events inside one service	What happened in one place?
Traces	The path of one request across services	Where did the time go across services?
Profiles	Function-level CPU and memory data	Why is the code in a service slow?

The question only a trace answers

Reach for a trace when the question is “where did the time go across services?” That’s the service-to-service timing no other signal reconstructs. A metric tells you checkout is slow, a log tells you one service recorded an error, and a trace tells you which hop in the checkout path lost the time.

Resources

Tue, 04 Aug 2026 18:58:09 -0400

Resources

This section covered what a trace is, how spans compose it, and where tracing fits among the signals. These docs go deeper on each idea.

Documentation

Introduction to tracing: Revisit what traces and spans are.
Trace structure: A closer look at spans, parent and child nesting, and attributes.
Telemetry signals: How metrics, logs, traces, and profiles work together.