stt/infra-observability
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Drop the traces dashboard, keep the datasource wiring

Browse Source 
The dashboard reimplemented, less well, what Explore already does: its search
panel had no TraceQL query builder and no autocompletion, and its service
dependency table replaced an interactive node graph with a list. Searching and
exploring traces belongs in Explore.

The datasource correlations this work also fixed are kept — they are what was
actually missing, and they apply in Explore exactly as they would in a
dashboard.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
Stéphane Tailland
2026-08-26 07:55:17 +02:00
parent 367ebd1da5
commit d3abde1040
3 changed files with 16 additions and 963 deletions
Download Patch File Download Diff File Expand all files Collapse all files
README.md
+16 -20
View File
@@ -215,25 +215,13 @@ indicators, HTTP traffic, a runtime section specific to the stack in use, and a
### Distributed tracing
`obs-traces` searches traces with TraceQL, assembled from a service selector, a
minimum duration, a status, and a free-text field for conditions the selectors
do not cover. The status and free-text variables hold TraceQL *fragments* rather
than values, so an empty one contributes nothing and the surrounding query stays
valid — "no filter" is the default rather than a special case.
Traces are searched and explored in **Explore**, on the Tempo datasource, not
from a dashboard. Explore's TraceQL query builder, autocompletion, trace view
and interactive service graph have no dashboard equivalent worth maintaining —
a dashboard search panel is a worse copy of a tool that already exists.
Opening a trace gives the waterfall, every span's attributes and events, and
from a span its logs and its RED metrics. The rest of the dashboard is the
aggregate view: rate, errors and latency percentiles from the span metrics
Tempo's own `metrics_generator` derives from the traces, the slowest and most
failing operations by span name, and the service-to-service edges Tempo infers.
Span name rather than endpoint is the unit worth looking at: a slow database
statement surfaces next to a slow HTTP handler, which is what tracing buys over
plain HTTP metrics.
The interactive node graph stays in Explore — `serviceMap` is a query type
Grafana's frontend assembles and it returns nothing through the dashboard query
API, so the dashboard shows the same edges as a table instead.
What the repository does own is the datasource wiring, which applies in Explore
exactly as it would in a dashboard.
#### Span-to-logs correlation
@@ -254,10 +242,18 @@ Coverage today, each verified by taking a trace id and searching for it:
| classic-models-api | yes | inbound `traceparent` in the gunicorn access line |
| LibreChat | no | would need the upstream image patched |
`tracesToMetrics` likewise had no queries defined and rendered a bare datasource
link; it now carries rate, error-rate and p95 queries against the span metrics,
#### Span-to-metrics correlation
`tracesToMetrics` had no queries defined and rendered a bare datasource link. It
now carries rate, error-rate and p95 queries against `traces_spanmetrics_*`,
scoped to the span's own service.
Those span metrics are worth knowing about independently: Tempo's
`metrics_generator` derives them from the traces and remote-writes them to
Prometheus, keyed by `service` and `span_name`. They measure the *span*, so a
slow database statement appears next to a slow HTTP handler — a granularity the
gateway and per-application dashboards, which measure HTTP, do not have.
### Log dashboards, split by kind
Logs are searched from three dashboards rather than one, because the three