Lexicon
Distributed tracing
Distributed tracing follows requests across service boundaries using connected spans. How it works, what it reveals, and where tracing rollouts fall down.
Definition
Distributed tracing is the technique of following a request across service boundaries by recording a connected span for each operation it touches. The result is a trace: one coherent record of a request's path, timing, and outcome across an entire system.
What it means in observability
Microservices dissolved the single process where debugging used to happen. A request that once lived in one application now crosses ten services, three queues, and someone else's API, and no single log file tells its story. Distributed tracing restores the storyline. It answers where latency actually accumulates, which downstream dependency is failing, and how services really call each other, as opposed to how the architecture diagram claims they do. Service maps, dependency views, and endpoint analytics are all derived from trace data.
How it works in practice
Instrumentation creates spans around meaningful operations, and context propagation carries the trace identity across every network hop, most commonly in W3C traceparent headers. Each service contributes its spans, the backend reassembles the tree, and flame graph views make duration visually obvious: wide means slow, deep means layered. Beyond reading individual traces, span level analytics aggregate across millions of them to surface patterns such as which endpoints degrade under load or which tenant's requests run slow.
Where it gets hard
Tracing rollouts fail at the edges: the one un-instrumented service that splits every trace crossing it, the queue that drops context, the vendor SDK that speaks a different propagation format. Sampling undermines the payoff from the other side, discarding the rare failing traces that were the reason for adopting tracing at all. And granularity takes judgment, since spans that are too coarse hide the problem while spans that are too fine bury it.
Where Tsuga fits
Tsuga ingests traces over OTLP with full span search, flame graphs, and log to trace correlation built in. OpenTelemetry native ingestion means traces keep their exact instrumented shape from SDK to query.
Related terms
- APMAPM, application performance monitoring, is the practice and product category focused on the health of applications in production: request rates, error rates, latency, and the transaction level detail needed to explain them.
- Context propagationContext propagation is the OpenTelemetry mechanism that carries trace identifiers and baggage across process boundaries, so that spans created in different services join into a single trace.
- ObservabilityObservability is the ability to understand what is happening inside a system from the data it emits: its logs, metrics, and traces.
- Real user monitoring (RUM)Real user monitoring, RUM, captures what actual users experience in their browsers and mobile apps: page load performance, interaction responsiveness, errors, and the shape of whole sessions.
- SamplingSampling is the practice of keeping only a subset of telemetry, usually traces, so that volume and cost stay manageable.
- SpanA span is a single timed operation inside a trace: an HTTP request, a database call, a queue publish, or an internal step worth measuring.
- TraceA trace is the end to end record of one request or workflow as it moves through a system, composed of all the spans that share a single trace ID.