Grafana's Explore has a split view that can hold panes querying different data sources at once. Walk through using it to investigate a latency spike across a metrics, a logs and a trace backend, and say what has to line up for that workflow to hold together.
answer
- Explore = ad-hoc, no dashboard, query history
- Split = one data source per pane, sync the time range
- Enter from a panel: query + range travel with you
- Follow exemplar → trace → trace-to-logs
- Correlations = data-source-agnostic generalisation of the jumps
basics
~20 sStart in Explore with the metric, split the view to open a second pane, keep the time ranges synced, then follow links between panes: metric exemplar or manual query to a trace, span back to logs. It holds together only if the time ranges match, the identifiers are shared, and the user can query every data source involved.
solid answer
~1 minExplore is Grafana's ad-hoc query surface: one query, one pane, no dashboard, full query history. **Split** opens additional panes side by side, each bound to its own data source, so a metrics pane can sit next to a logs pane and a trace pane. A typical run: start from a dashboard panel showing the spike and use *Explore* from the panel menu — the query and time range come with you. Narrow the range to the spike. Split, put logs in the second pane for the same service and window. Then use the links the platform already provides: an exemplar dot on the metric jumps into a trace pane, and from a span, trace-to-logs jumps back to the logs. Finally, promote what you found into a dashboard panel. What has to line up: the **time range** (Explore can sync ranges across panes — without it you are comparing different minutes), the **identifiers** shared between signals, **query permission on every data source** involved, and stable **data source UIDs** if you want the same links to work in another environment. **Correlations** generalise this: a data-source-agnostic rule mapping a field in one source's results to a query in another, so the jumps are not limited to the built-in signal pairs.
go deeper
Know Explore is the ad-hoc query view, that split shows more than one data source at once, and that the time ranges should be synced.
Narrate a full run — enter from a panel, narrow, split to logs, follow an exemplar or trace-id link, return to logs from a span — and name the time/identity/permission prerequisites.
Discuss what makes the workflow reliable in production: pinned UIDs, consistent service identity, ingest-time skew, and when to promote a query into a provisioned dashboard.
Position Explore as the payoff surface for upstream telemetry conventions, and Correlations as the reviewable, central place to encode cross-signal navigation instead of scattering it per data source.
## What Explore is for A dashboard answers a question you already knew you would ask. **Explore** is for the question you did not: one query box, one result pane, no layout, no saving, plus query history. It is the tool you reach for during an investigation and abandon afterwards — or, when the query turns out to be worth keeping, you push it into a dashboard panel from Explore. ## Split view Split opens more than one pane, each with **its own data source and its own query**. That is what makes it a cross-signal tool: metrics on the left, logs on the right, a trace below or in a third pane in newer versions where the split is not limited to two. Panes can share a time range so that narrowing one narrows the others — the single most important setting in the whole workflow, because comparing signals at different minutes produces confident nonsense. ## A concrete run 1. **Enter from the symptom.** From the dashboard panel showing elevated p99, use the panel menu's Explore action. The query and the time range travel with you, so you start from the exact thing you were looking at rather than retyping it. 2. **Narrow.** Zoom to the spike. Every subsequent pane inherits this window if range sync is on. 3. **Split to logs.** Second pane, log data source, filtered to the same service and window. You are looking for a change in shape — a new error, a burst of retries, a restart. 4. **Get to an individual request.** Two paths. If exemplars are wired, click the dot on the metric — it carries a trace id and opens a trace pane. If not, use the log line's trace-id link, if the log data source has a derived field for it. 5. **Go back the other way.** From a span, trace-to-logs returns you to the logs for that exact request rather than the whole service. 6. **Keep the finding.** Add the useful query to a dashboard, or write it up. Explore state is transient by design, though the URL is shareable and query history is retained. ## What has to line up - **Time.** Sync the ranges; be aware of the browser time zone versus the dashboard time zone, and of ingest-time versus event-time skew in the log pipeline. Two panes an hour apart is the classic wasted investigation. - **Identity.** The service must be identifiable the same way in each store — the label that means "this service" in the log store, the attribute that means it on a span, the label on the metric. Where they differ, someone has to translate, and that translation is configuration you own. - **Correlation identifiers.** Trace id present in logs and on exemplars, in the same encoding. - **Permissions.** A user who can read metrics but not traces sees links that error. Cross-signal navigation is only as good as the least-permitted data source in the chain. - **Stable UIDs.** Every internal link stores a data source **UID**. Investigations that rely on links only survive across environments if the UIDs are pinned by provisioning. ## Correlations The built-in jumps cover the well-known signal pairs. **Correlations** generalise them: you define a rule with a **source data source and field**, a **target data source and query**, and variables carrying the field's value. That lets you link anything to anything — an order id in a log line to a business dashboard, a pod name to a Kubernetes-focused query — without waiting for a built-in feature for that pair. They are managed centrally rather than per data source, which also makes them reviewable. ## The honest limitation Explore does not correlate anything by itself. It is a workbench that places panes side by side and follows links that the telemetry and configuration already make possible. If the three signals disagree about service identity, carry no shared request id, and are retained for wildly different windows, split view just lets you be confused in three panes at once. The engineering work is upstream; Explore is where it pays off.
- When would you stop using Explore and build a dashboard instead?When the same query is being retyped by the same people for the same class of incident, it has stopped being exploration and become a known question — that belongs in a dashboard, provisioned as code so it is reviewed and identical across environments. Explore stays the right tool for the first time you ask something, and for one-off investigations whose queries have no reuse value.
- What does the Correlations feature add over derived fields and trace-to-logs?Derived fields and trace-to-logs are per-data-source settings for specific signal pairs. Correlations are defined centrally as source field to target query with variables, for any pair of data sources, including ones with no built-in relationship — a business id in a log line to a SQL data source, for example. They are managed in one place, which makes the set of cross-signal jumps reviewable rather than scattered across each data source's configuration.
saying these in an interview costs you the question
- Investigating with unsynced time ranges across panes and drawing conclusions from the mismatch
- Expecting Explore to correlate signals on its own without shared identifiers in the telemetry
- Saving investigation state in Explore as though it were a dashboard
- Forgetting that internal links resolve by data source UID, so they break in another instance
- Ignoring that a user lacking permission on the target data source sees the link fail