Lexicon
Trace
What a trace is: the end to end record of one request built from spans, how trace IDs connect services, and why sampling and propagation decide quality.
Definition
A 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. It captures which services participated, in what order, for how long, and with what outcome.
What it means in observability
Traces are the narrative signal. Metrics tell you error rates rose and logs tell you what individual services said, but a trace tells the story of one specific request from edge to database and back. That makes traces the natural starting point for debugging distributed systems, where the interesting failures live in the interactions between services rather than inside any single one. Trace IDs also act as the join key of observability, connecting logs, spans, and user reports to the same underlying event.
How it works in practice
A trace begins when the first instrumented component creates a root span and a new trace ID. Context propagation carries that ID across every subsequent hop, and each service adds its own spans beneath the appropriate parent. The backend reassembles the tree and renders it as a waterfall or flame graph, where width is duration and depth is call structure. Search works across trace attributes, so you can pull up traces by service, endpoint, duration, status, or any attribute your instrumentation records.
Where it gets hard
Trace quality is only as good as its weakest hop: one service that fails to propagate context splits the story into fragments. Sampling is the other quiet threat, because the traces most worth reading, the rare failures and outliers, are statistically the ones a sampler is most likely to have discarded before you went looking. Long running and queue spanning workflows also stretch the model, since a trace that takes hours to complete tests buffering assumptions throughout the pipeline.
Where Tsuga fits
Tsuga offers full trace search and span level analytics, flame graph rendering, and automatic log to trace correlation when logs carry trace identifiers. Traces arrive over OTLP and keep their OpenTelemetry structure end to end.
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.
- Distributed tracingDistributed tracing is the technique of following a request across service boundaries by recording a connected span for each operation it touches.
- MTTRMTTR is mean time to resolution, the average elapsed time from a failure occurring to service being restored.
- 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.
- Tail samplingTail sampling is a sampling strategy that makes the keep or discard decision after a trace completes, when its outcome is known.
- TelemetryTelemetry is the data software and infrastructure emit about their own behavior.