# Read where the time went

A trace is one request laid out end to end. Maple keeps every span the SDK sent, with its attributes, its parent, and its exact millisecond offset — so a slow request stops being a guess.

## One request, 18 spans, one screen

Select any span and its full attribute set opens beside the waterfall — the SQL it ran, the status it returned, the pod it ran on. Nothing is summarised away.

- **signal**: traces
- **transport**: OTLP/gRPC · OTLP/HTTP
- **views**: waterfall · flamegraph · flow
- **attributes**: db.statement · http.status_code · exception.type
- **joins.on**: trace_id · span_id
- **sampling**: head · tail

## Four ways to read the same spans

### /traces — Waterfall

Spans nested by parent, bars scaled to the trace's own duration. A 1.24 s request with a 480 ms child reads as a shape before you read a number.

### flamegraph — Flamegraph

The same spans stacked by depth instead of time. Fifty sibling db.query spans at one level is an N+1, and it is visible as a wall rather than a list.

### flow view — Service flow

The trace collapsed to the services it crossed and the calls between them. Use it when the question is which boundary, not which line.

### db.statement — Attributes

Every key the SDK sent, stored as sent. db.statement, http.status_code, exception.type and your own custom keys are all queryable, not just displayable.

### trace_id — Jump to logs

Spans and logs carry the same trace id, so any span opens the log lines written while it was running. No timestamp arithmetic across two tools.

## Related

- [Service Catalog & Map](https://maple.dev/features/service-catalog.md)
- [Log Management](https://maple.dev/features/log-management.md)
- [Error Tracking](https://maple.dev/features/error-tracking.md)
- [Microservices Debugging](https://maple.dev/use-cases/microservices-debugging.md)