What are traces?

Distributed traces record the complete journey of a request as it travels across services, APIs, databases and queues. They give engineering teams end to end visibility into latency, dependencies and failures across distributed architectures.

Talk to an expert

Following requests across distributed systems

Modern applications rarely run inside a single server or process. A single user checkout might pass through a web gateway, an authentication service, a payment API and a database before returning a response.

When that request slows down or fails, looking at individual services in isolation only shows part of the picture. Distributed tracing connects every step of the journey into one continuous timeline. Teams can immediately see where time is spent and where errors begin.

What does a trace actually contain?

A distributed trace is built from connected units of work called spans, linked together by shared context:

Trace ID

A unique identifier assigned when a user request enters your system and passed across every service it touches.

Spans

Individual operations inside the trace, such as an HTTP call, a database query or a message queue write.

Parent and child links

Relationships showing which upstream service called which downstream dependency, forming a clear execution tree.

Timing and status

Start times, durations and outcome codes that reveal exactly how long each operation took and whether it succeeded.

Attributes and events

Structured metadata like service name, endpoint, region or error details attached to each individual span for fast filtering.

Example trace flow:

Trace ID: 9f8e7d6c | Checkout API (540ms) -> Auth Service (45ms) -> Payment API (470ms) -> Database Query (430ms, Timeout)

This shows that the checkout slowdown happened inside a single database query called by the payment service. To inspect the exact query error or host resource pressure behind that timeout, you pivot directly from this trace to logs and metrics.

Different layers. Different spans.

Edge and gateway spans

Where requests enter

Capture incoming traffic at load balancers, API gateways and proxies to measure total user facing latency.

Service and API spans

How microservices interact

Track internal HTTP and RPC calls between applications to expose cascading delays and retry loops.

Database and cache spans

How data stores respond

Measure query execution times, cache misses and lock contention across relational and NoSQL databases.

Asynchronous and queue spans

How background jobs flow

Follow events across message brokers and worker queues where requests decouple from immediate responses.

External dependency spans

How third party APIs behave

Isolate latency and failures caused by payment gateways, identity providers and external cloud services.

Why raw traces become hard to manage

As request traffic and microservice depth grow, capturing every span creates practical trade offs. Without clear governance, teams run into familiar obstacles:

High ingestion and storage costs

Recording every trace during high traffic overwhelms storage budgets fast.

Broken context propagation

Missing trace headers across queues split single journeys into fragments.

Sampling blind spots

Random sampling often drops rare errors before engineers can inspect them.

Instrumentation gaps

Uninstrumented proxies and external APIs leave unexplained timing gaps.

Overloaded span attributes

Attaching large payloads or high cardinality tags slows down collectors.

From raw spans to reliable answers

Propagate context everywhere

Pass trace headers consistently across HTTP services, queues and workers.

Use smart tail sampling

Keep traces with errors or high latency while sampling routine traffic.

Standardise with OpenTelemetry

Apply shared semantic conventions so spans carry consistent service names.

Focus on critical user journeys

Prioritise deep instrumentation on checkout, login and core workflow paths.

Link traces to logs and metrics

Inject trace IDs into logs so teams jump from slow spans to root causes.

How traces work with metrics, logs and OpenTelemetry

Traces are one of the three core signals of observability:

Metrics show that checkout response times have spiked.
Traces pinpoint the delay inside the payment service.
Logs reveal a database connection timeout inside that service.

With OpenTelemetry, applications automatically propagate trace context through language SDKs and route spans through the OpenTelemetry Collector. Teams can apply tail sampling, scrub sensitive attributes and export clean trace data to platforms like Elastic without vendor lock.

Traces map the journey. Context reveals the bottleneck.

Observata helps your team instrument distributed services, configure smart sampling and connect traces across Elastic and OpenTelemetry. We turn complex request flows into clear operational insight.

Explore our approach

What is OpenTelemetry?

Open standards for collecting metrics, logs and traces. Discover how OpenTelemetry connects telemetry without vendor lock.

What are metrics?

Numerical measurements of latency, throughput and resource usage. Discover how metrics spot performance shifts before users feel them.

What are logs?

Timestamped event records that detail application activity, errors and system state. Learn how structured logs turn raw data into reliable answers.