Tracing

Tracing follows a single request as it travels across your services, so you can see where time is spent and where errors begin. It reads distributed traces from your connected tracing backend and presents them as a service overview, a searchable trace list, and a detailed span waterfall.

Service overview

The overview lists every instrumented service for the selected time window, with the numbers that matter at a glance: request count, error count and error rate, and latency percentiles of p50, p95, and p99 alongside the average. Sort by any column to find the slowest or most error-prone service, then click a row to drill into its traces.

Searching for traces

Within a service you can search the traces it took part in. Narrow the list by operation, by minimum duration to surface the slow ones, or by errors only. Each result summarises the trace, including its root service and operation, when it started, how long it took, how many spans it covers, and how many of those carried an error.

Reading a trace

Open a trace to see its spans laid out as a waterfall. Each span is positioned and sized by when it ran and how long it took, and coloured by service, so the shape of the request is immediately visible, with serial work stacking into a staircase and parallel work sitting side by side. Spans that carried an error are marked, which makes the origin of a failure easy to trace back through the call tree.

Select any span to open its detail: its service and operation, exact start time and duration, the full set of tags, and any logs recorded against it. Where a span has a parent, a link takes you straight to it, so you can walk up the chain from a symptom to its cause.

Related

• Logging to read the log lines a service emitted during a request.
• Monitoring & Metrics Explorer for the aggregate latency and error trends behind these traces.