Skip to content

Build dashboards

Dashboards in LeanSignal are Perses dashboards with one crucial twist: building one is also an act of collection. Every panel query you save implies the timeseries needed to render it, and those join the demand set your agents enforce.

Go to Dashboards → Add Dashboard (editor or admin role) and set:

  • Name and optional Description.
  • Demand — the demand this dashboard belongs to. Its queries contribute to that demand’s metric set and cost estimates. Every dashboard requires a demand, so create one first if none exists yet.

The new dashboard opens empty — press Edit in the toolbar to start adding panels.

This is the part that makes demand-driven dashboarding practical. The editor switches data sources depending on mode:

  • Edit mode queries the agent’s local, full-fidelity store — every metric your systems emit for the last day, whether demanded or not. You can chart anything that exists, preview it against real data, and iterate freely.
  • View mode queries your central dataplane — the demanded subset, with long-term history.

So the workflow is: enter edit mode, explore what’s available, build panels on real data, then save. On save the demand set recomputes and agents start forwarding the newly demanded timeseries — within seconds the view mode has live data too (history accumulates from that moment; the edge buffer isn’t backfilled).

Dashboards carry all three signals. Alongside the PromQL time-series panels:

  • Logs Table panels query the Loki datasource with LogQL. A saved log panel demands its stream selectors.
  • Trace Table and Scatter Chart panels query the Tempo datasource with TraceQL search; a Tracing Gantt Chart panel renders a single trace’s span timeline. A saved trace panel demands the services its query names.

The mode switch works the same way as for metrics: edit-mode previews are answered from the gateway’s local Loki and Tempo — the same data as the Explore pages’ Available source — and view mode reads central storage. Saving the dashboard adds the panels’ stream selectors and trace services to the demand set. See Logs and Traces for what each selector demands.

Every save creates a new immutable version — the Version column shows the current one (v1, v2, …), and a version dropdown appears on the dashboard once more than one exists. Metadata edits (name, description) also create a version; saves that change nothing are skipped. There is no rollback action — versions are an append-only history, and the latest is always what renders.

The dashboard title bar shows what the dashboard costs to keep: stored timeseries (a count), Est. $/mo, and ~samples/mo — the same figures as the demands ledger, scoped to this dashboard. They update as the background register recomputes (every few seconds), so you can see the price of a panel while you design it. Deleting a panel — or the whole dashboard — releases any metrics nothing else consumes.

The integration dashboards follow conventions worth copying into your own:

  • An Instance variable filtering every query, so one dashboard covers all instances or one — nobody runs a single instance.
  • Queries grouped by the instance label with instance-first legends, so a fleet view never mixes hosts or replicas.
  • Table legends with last/mean/max, so the outlier instance stands out.
  • Real units (requests/sec, bytes/sec, percentages bounded 0–100%), so panels read correctly at a glance.

Importing an integration and editing its copy is often faster than starting from an empty grid — imported dashboards are ordinary, fully editable Perses dashboards.

Was this page helpful?