Visualising Metrics with Grafana Dashboards
Turn PromQL into panels, rows, and dashboards your whole team can read at a glance.
Prometheus stores the numbers; Grafana makes them make sense. In this lesson you’ll connect Grafana to Prometheus, build panels from PromQL, and learn what separates a useful dashboard from a wall of noise.
🎯 Learning Objectives
- Add Prometheus as a Grafana data source
- Build a panel from a PromQL query
- Use variables to make dashboards reusable
- Apply dashboard design best practices
Step 1 — Add the Data Source
Grafana talks to many backends. To read Prometheus, add it as a data source — in the UI under Connections → Data sources, or as config-as-code:
# grafana/provisioning/datasources/prometheus.yml
apiVersion: 1
datasources:
- name: Prometheus
type: prometheus
access: proxy
url: http://prometheus:9090
isDefault: true💡 Provision, don't click
Clicking through the UI is fine to learn, but in real setups you provision data sources and dashboards from files (as above) so they’re version-controlled and reproducible — the same GitOps mindset you use everywhere else.
Step 2 — Build a Panel
A panel is a single visualization driven by one or more queries. Create a panel, pick the Prometheus data source, and enter a PromQL query. For a request-rate graph:
sum(rate(http_requests_total[5m])) by (status)Grafana draws one line per status label. Choose a visualization type to match the data:
| Visualization | Best for |
|---|---|
| Time series | Rates and values over time (the default) |
| Stat | A single big number (e.g. current error rate) |
| Gauge | A value against a threshold (e.g. CPU %) |
| Bar gauge / Table | Comparing many labelled values at once |
Step 3 — Make it Reusable with Variables
Hard-coding a service name into every panel means one dashboard per service. Instead, define a template variable and let users pick from a dropdown.
Create a variable named service whose values come from a query, then reference it in panels with the $service syntax:
sum(rate(http_requests_total{service="$service"}[5m])) by (status)Now one dashboard covers every service — the dropdown at the top swaps $service for whatever the viewer selects.
⚠ Panels are only as good as the query
If a panel looks wrong, 90% of the time it’s the PromQL, not Grafana. Test the query in the Prometheus UI first, then paste it into the panel.
Dashboard Design That People Actually Use
A dashboard is a communication tool. Good ones follow a few rules:
- Top-left is prime real estate — put the most important health signals there (the “is it up and healthy?” numbers).
- Follow the RED method for services: Rate, Errors, Duration — the three lines that tell you almost everything.
- Use USE for resources: Utilization, Saturation, Errors for hosts and disks.
- Set units and thresholds so a value turns red when it’s actually bad.
- Fewer panels, clearer story — 8 focused panels beat 40 you never look at.
┌─────────────┬─────────────┬─────────────┐
│ Req Rate │ Error % │ p95 Latency│ ← at-a-glance health
├─────────────┴─────────────┴─────────────┤
│ Requests/sec by status │ ← trends
├─────────────────────────────────────────┤
│ Latency percentiles over time │
└─────────────────────────────────────────┘🧪 Hands-on Lab
Design a Service Dashboard
Sketch the queries for a RED dashboard for a service called checkout. Write PromQL for:
- Request rate
- Error ratio (5xx as a fraction of all requests)
- Duration — p95 latency (assume a histogram
http_request_duration_seconds_bucket)
🧠 Knowledge Check
What does the RED method recommend tracking for a service?
Why use a template variable like $service in a dashboard?
💼 Interview Preparation
How do you decide what to put on a monitoring dashboard?
Summary
You can now connect Grafana to Prometheus, build panels from PromQL, parameterise dashboards with variables, and design views around RED/USE. The final piece of monitoring is being told when something breaks — so next we set up alerting.