Distributed tracing for every request, end to end
Follow each request across services, queues and databases with OpenTelemetry-native distributed tracing, and find the slow span or failing dependency in seconds.Why teams use Distributed Tracing in Obseria
Find the slow hop fast
See exactly which service, query or downstream call adds latency to a request instead of guessing from averages.
Keep the traces that matter
Tail-based sampling keeps errors, slow requests and rare paths while dropping repetitive healthy traffic.
No proprietary lock-in
Instrument with standard OpenTelemetry SDKs and export your data via OTLP at any time.
Distributed Tracing in three steps
- Step 1
Instrument with OpenTelemetry
Use existing OTel SDKs or the Obseria Agent for automatic instrumentation; most teams see their first trace within 15 minutes.
- Step 2
Sample and enrich at ingest
Obseria Pipeline applies tail-based sampling, adds Kubernetes and cloud metadata and masks PII before storage.
- Step 3
Analyze and investigate
Query spans with OQL, view waterfalls and service maps, and let Obseria Intelligence trace an anomaly to its root cause.
Capabilities
- Trace waterfall and flame view. Inspect every span with timing, attributes, events and linked logs in a single view.
- Tail-based sampling. Decide what to keep after a trace completes, based on errors, latency or custom attributes.
- Service map from traces. Obseria TopoGraph builds call relationships and dependency health automatically from span data.
- Span analytics with OQL. Aggregate spans by any attribute, such as endpoint, tenant or version, to find patterns across millions of requests.
- Trace-to-log and trace-to-profile. Jump from a span to its correlated logs and to the code-level profile for the same time window.
- Context propagation everywhere. W3C Trace Context across HTTP, gRPC and messaging, including Kafka and other queues.
Distributed Tracing: what you need to know
What is distributed tracing?
Distributed tracing records the path of a single request as it moves through a distributed system. Each unit of work, such as an HTTP handler, a database query or a message publish, becomes a span with a start time, a duration and attributes. Spans share a trace ID and point to their parent, so together they form a tree that shows exactly where time was spent and where an error occurred.
In a monolith, a stack trace or a profiler often tells you everything. In a microservices architecture, one checkout request may touch an API gateway, five services, two databases, a cache and a message queue. Metrics show that latency went up and logs show individual events, but only a trace connects them into a causal story for one specific request.
Why distributed tracing matters for microservices
Modern systems fail in ways that do not show up on a single host. A slow dependency causes retries upstream, a misconfigured connection pool queues requests, a new version adds an N+1 query. Without tracing, engineers jump between dashboards and correlate timestamps by hand, which drives up mean time to resolution.
- Latency attribution: see which span on the critical path contributes most to end-to-end duration.
- Error origin: find the service where an exception was first raised, not just the edge where a 500 was returned.
- Dependency insight: understand real call patterns, fan-out and retries instead of relying on outdated architecture diagrams.
- Release verification: compare traces before and after a deployment to confirm a change behaves as intended.
Key signals to analyze in traces
Traces become most valuable when you aggregate them. Span data naturally maps to the RED method: rate of requests, errors and duration per service and endpoint. Beyond that, useful questions include:
- Which endpoints have the worst p95 and p99 latency, and which spans dominate those slow traces?
- How does latency differ by attribute, for example by tenant, region, client version or feature flag?
- Where do retries, timeouts and circuit breaker events cluster?
- Which database statements or external API calls appear most often in slow traces?
With OQL you can answer these directly on span data, for example fetch spans | filter service == "checkout" and duration > 500ms | summarize count(), by:{span.name}.
How Obseria handles distributed tracing
Obseria is OpenTelemetry-native. You can send OTLP from existing SDKs and collectors, or let the Obseria Agent instrument common runtimes automatically. Traces land in Obseria Lake, an index-free lakehouse with schema-on-read, so every span attribute stays queryable without defining indexes upfront.
Obseria Pipeline runs at ingest: it applies tail-based sampling so that complete traces with errors or high latency are kept, enriches spans with Kubernetes, cloud and deployment metadata, and masks personal data. Obseria TopoGraph uses the same spans to build a live service map, and Obseria Intelligence uses topology plus traces to run agentic root-cause investigations that return a chain of evidence rather than a guess.
Every trace links to correlated logs, metrics and continuous profiles, so you can go from a slow span to the exact function that consumed CPU. Because the data model is open, you can export traces via OTLP at any time.
Distributed tracing best practices
- Start with auto-instrumentation, then add manual spans around business-critical operations such as payment authorization.
- Propagate context everywhere, including asynchronous boundaries like queues and background jobs, so traces do not break.
- Use semantic conventions for attribute names so that dashboards and queries work across teams and languages.
- Add business attributes such as plan, tenant or order type to connect technical performance with impact.
- Sample intelligently. Prefer tail-based sampling over fixed head sampling so rare failures are never dropped.
- Keep secrets out of spans. Mask PII at ingest rather than relying on every developer to remember it.
Frequently asked questions
Logs record individual events from one component. Distributed tracing links the work of many components for a single request into one trace, so you can see causality and timing across services. Obseria correlates both, so every span links to its logs.
No. Obseria accepts OTLP natively, so existing OpenTelemetry SDKs and collectors work as they are. You only point the exporter to Obseria.
Tail-based sampling decides whether to keep a trace after it has completed. That lets Obseria keep all traces with errors or high latency while sampling routine successful requests, which reduces cost without losing important evidence.
Spans are billed per million ingested ($0.060) and per million stored ($0.540), with 30 days of retention. Spans dropped by sampling or filters in Obseria Pipeline only incur ingestion cost.
Yes. OpenTelemetry context propagation works across messaging systems such as Kafka, so producer and consumer spans appear in the same trace or as linked traces.
Ready for observability that delivers answers?
Try every feature free for 14 days, no credit card and no proprietary agents.