Searching traces

The trace list #

The trace explorer lists requests, one row each, newest first. A row carries the service, the endpoint, the status, the duration and the host.

Filters #

The same search language as logs applies:

• service:checkout — requests to one service.
• status:error — only failed requests.
• http.status_code:[500 TO 599] — server errors by status.
• duration>1000 — requests slower than a second.
• resource:/checkout/:id — one route pattern.
• method:POST — by HTTP method.

Facets #

The facet rail counts, and filters by:

• status
• service
• resource
• env
• http.status_code
• method

The latency histogram #

Above the list, a histogram shows when the requests in your window happened and how their latencies were spread, split into successful and failed. It is the fastest way to see whether a spike was volume or latency.

Sorting #

Sort by:

• timestamp
• duration
• service
• status
• http.status_code
• host

A sort key that is not in the list falls back to newest first.

Opening a trace #

Open a row to read the whole request as a tree: each span's duration, its position in the trace, and the attributes it carried.

• Width is duration relative to the whole trace.
• Depth is nesting: a child sits under its caller.
• Self time is the span's own work, excluding its children.
• Colours separate successful requests from failed ones.

Errors stand out #

A failed span is marked, and a trace containing a failure is marked on its row. Filtering to errors gives you the requests that are worth reading.

Limits #

• The list returns up to 500 rows at a time.
• A single trace holds up to 20,000 spans.

Onward #

Once you have the request, Services and latency gives it context, Error tracking groups repeated failures, and Logs searches the lines the request emitted.