Dashboards & Grafana
A dashboard is only useful if it drives action. Learn panel types, template variables, data sources, annotations and provisioning, and how to design dashboards that an on-call engineer can read in one glance.
What is this?
Grafana is a visualization platform that connects to data sources — Prometheus, Loki, Elasticsearch, Tempo — and renders queries into panels. A dashboard is a layout of panels that answers a question. Template variables let one dashboard serve many services, annotations overlay events like deploys on time series, and provisioning keeps dashboards in git as code. Good dashboard design starts from the question an engineer must answer, not from available data.
Why do you need it?
- A well-designed dashboard cuts mean-time-to-respond by showing the right signal at the top of the screen.
- Template variables turn one dashboard into a hundred views, one per service or region.
- Annotations correlate deploys and incidents to metric changes in the same chart.
- Grafana unifies metrics, logs and traces behind one pane of glass instead of five tools.
- Actionable dashboards drive decisions; decorative ones waste the attention of everyone who opens them.
Mental model
An airplane cockpit
A good dashboard
An airplane cockpit clusters instruments by the task at hand: one cluster for engine state, one for navigation, one for warnings. It has no Christmas tree of blinking lights. Every gauge exists because a pilot must decide something from it. A dashboard full of unrelated pretty charts is the Christmas tree — it glows, and it teaches everyone to ignore it.
How it works
- A data source defines how Grafana talks to a backend, for example a Prometheus instance using its HTTP query API.
- Each panel runs one or more queries and renders the result as a time series, stat, table, gauge or log view.
- Template variables like $service are substituted into panel queries at render time, so one panel serves every value.
- Annotations read events from a data source or the API and draw vertical markers on time-series panels.
- Dashboards are versioned JSON; provisioning folders let teams ship them from git with datasources and alerting config.
How a Grafana panel turns a query into an answer.
Key commands
curl -s -u admin:admin 'http://localhost:3000/api/search?type=dash-db'List dashboards through the Grafana HTTP API.
curl -s 'http://localhost:9090/api/v1/query?query=up'Verify the Prometheus data source backend is reachable.
kubectl get pods -l app=grafanaLocate the Grafana deployment in a cluster.
docker ps --filter name=grafanaFind the Grafana container and its port mapping.
grafana-cli plugins install grafana-piechart-panelInstall an optional visualization plugin.
Examples
A panel query and the provisioning file behind it
// Stat panel: p99 latency for the selected servicehistogram_quantile(0.99, sum by (le) (rate(http_request_duration_seconds_bucket{service="$service"}[5m]))) // Time series panel: 5xx error rate per instancesum by (instance) ( rate(http_requests_total{service="$service", status=~"5.."}[5m]))The same dashboards JSON, provisioned from git, works for every service because $service is a template variable: the dropdown feeds a value into the query at render time. The first query computes a latency percentile; the second breaks error rate down by instance. Both stay cheap because they aggregate with sum.
In production
- A golden-signals dashboard is the default landing page for every service: latency, traffic, errors and saturation at the top.
- Per-service dashboards use template variables, so one JSON drives all services and new services get dashboards for free.
- Deploy annotations on the latency panel explain a latency drop immediately after a release during incident review.
- Grafana alerting evaluates latency-based SLO burn rules that would otherwise need a second tool.
- Provisioning keeps dashboards in git, reviewed like code, with datasources configured per environment.
Best practices
- Put one primary metric per panel; cluster related series with intent, not everything into one chart.
- Use template variables for service, instance and region instead of hardcoding values in queries.
- Keep a dashboard to a single screen height so it can be scanned in one glance.
- Annotate deploys, releases and config changes on the time-series panels that matter.
- Design every dashboard to answer a question or drive a decision; delete the ones that answer nothing.
Common mistakes
- Building a forty-panel 'everything' dashboard that takes ten minutes to parse during an incident.
- Hardcoding service names in queries, forcing a duplicate dashboard per service.
- Omitting units and thresholds so the numbers are meaningless at a glance.
- Overlapping series with no legend, thresholds or clear naming.
- Making dashboards that look nice but nobody is empowered to act on.
Common issues
A panel shows No dataThe query selector matches nothing, or the panel uses the wrong data source.
Run the query in Explore, inspect the real label values, and confirm the panel's data source is the one with the data.
The template variable dropdown is emptyThe variable's query returns no values, often because it queries the wrong data source or format.
Edit the variable, check its query and data source, and test the same query in Explore.
Deploy annotations do not appear on the chartThe annotation query filters on tags that the deploy events do not carry.
Verify the annotation data source and tags match the events, or query annotations without filters to confirm data exists.
Debugging tips
- Iterate on a query in Grafana Explore before committing it to a panel.
- When a panel shows No data, check its data source and query selector — the data may exist under different labels.
- Verify template variables have defaults; an empty dropdown usually comes from a variable query with the wrong data source.
- Check the dashboard's time range and refresh rate for stat panels; a stale 'no change' can be a refresh problem.
- Inspect the Panel JSON when a provisioned dashboard behaves differently from one built in the UI.
Interview checkpoint
Hands-on lab
- Write provisioning YAML for a datasource and a dashboard provider
- Run Prometheus and node-exporter for live data
- Provision a dashboard as JSON with a PromQL stat panel
- Verify provisioning through the Grafana API
Provision a Grafana Dashboard with a Prometheus Data Source
30 min · advanced
Quick quiz
Which feature lets one dashboard serve many services?
Which Grafana feature overlays events such as deploys on a time series?
A dashboard should be designed to answer a specific question or drive a decision.
Cheat sheet
time series panelMain panel for metrics over timestat panelSingle number with threshold coloringhistogram_quantile(0.99, ...)p99 latency in a stat or graphlogs panelLive log stream inside a dashboard$service variableTemplate variable per serviceGET /api/search?type=dash-dbList dashboards via the APIprovisioning/dashboards/Ship dashboards from git as JSONdatasource: prometheusPoint panels at the metrics backendannotationsDeploy and incident markers on timegrafana-cli pluginsInstall extra visualizations