Traces
Traces show how a single request travelled through your services. Owlpane ingests OpenTelemetry spans, derives request rate, error rate, and duration from them, and lays the result out as a searchable request list, a span search, and a topology map — all under /observability/traces, with a per-request detail page at /observability/requests/:traceId.
What it is
A trace is a tree of spans: one root operation, its child calls, and their children, each with a start time, a duration, and attributes. Where metrics tell you that latency rose and logs tell you what a service printed, traces tell you where in the call path the time went — which hop, on which service, for which request.
Owlpane derives request-level RED signals from spans as they arrive, so the Requests view and the Service map stay populated without a separate aggregation job.
Key capabilities
- Requests list — HTTP and RPC spans for API services, each row summarising latency, status, route, and service.
- Span waterfall — open a request to see parent and child spans on a timing axis, so the slow hop is obvious.
- Services graph — upstream and downstream calls for the selected trace, and the log lines that share its trace ID when log-trace correlation is enabled.
- Spans search — broader span search when you already hold a trace or span ID rather than a request row.
- Service map — a topology of service-to-service edges across many requests, with edge colour reflecting error rate and latency between nodes.
Where it lives
| Surface | Console route | What it does |
|---|---|---|
| Traces hub | /observability/traces | Opens onto the Requests, Spans, and Service map views. |
| Requests | /observability/traces/requests | HTTP and RPC request list with per-request waterfalls. |
| Spans | /observability/traces/spans | Broader span search by trace or span ID. |
| Service map | /observability/traces/service-map | Service dependency graph with error and latency signals. |
| Request detail | /observability/requests/:traceId | Waterfall, service graph, and correlated logs for one request. |
How data gets in
Traces arrive as OTLP spans at POST /v1/traces, from an Owlpane SDK or standard OpenTelemetry instrumentation. Include service.name and the HTTP semantic conventions so Requests and the Service map line up.
- Distributed trace ingestion — span ingest and derived RED metrics.
- OTLP ingest reference — endpoints and content types.
- SDKs — Node.js, Python, and OpenTelemetry-native instrumentation.
- Kubernetes Helm agent — cluster-wide span collection and auto-instrumentation.
- Integration library — trace-forwarding collector configurations.
- OTLP contract — span and resource attributes.
Concepts
| Term | Meaning |
|---|---|
| Trace | The full tree of spans produced by one request. |
| Span | A single timed operation within a trace. |
| Waterfall | A trace's spans drawn against a time axis. |
| RED metrics | Request rate, error rate, and duration derived from spans. |
| Service map | The aggregate topology of service-to-service edges. |
Scope and time range
Traces follow the same scope as the rest of the console: filter by Service to match the card you clicked, and note that Environment and time range use the same URL parameters as Logs, so a request view and a log view can be opened at the same coordinates.
Starting from an ID
When you already hold a trace or span ID — from a log line, an error report, or a link in a ticket — go straight to the Spans view rather than scanning the Requests list. The request detail page opens the same waterfall under /observability/requests/:traceId.
Related
- Logs — correlate lines with a trace ID.
- Metrics — derived RED signals and latency histograms.
- Dashboards — install a Traces starter pack from the library.
- Traces and requests task guide — walkthrough of the request waterfall and service graph.
- Alerts and on-call — alert on latency and error-rate thresholds.
Last updated