Prometheus stores and queries metrics; it isn’t meant to be the place you look at them day to day. Grafana is the dashboarding layer most commonly paired with it. This guide connects the two, builds one panel by hand to understand what’s happening underneath, and then imports a community dashboard instead of building everything from scratch, which is how most real Grafana usage actually works.

Add Prometheus as a data source

# docker-compose.yml (add to the stack from the previous guide)
  grafana:
    image: grafana/grafana:latest
    container_name: grafana
    ports:
      - "3000:3000"
    volumes:
      - grafana-data:/var/lib/grafana

After docker compose up -d, open http://localhost:3000 and log in with the default admin / admin (you’ll be prompted to change it). Add a data source under Connections → Data sources → Add new data source, choose Prometheus, and point its URL at http://prometheus:9090, the Compose service name from the previous guide, since Grafana and Prometheus share the same Docker network. Save and test; a successful connection confirms Grafana can reach Prometheus before you build anything on top of it.

Build one panel by hand

Create a new dashboard, add a visualization, and select the Prometheus data source. Rather than typing PromQL directly, Grafana’s query builder lets you construct a query field by field, which is a reasonable way to learn what a query is actually doing:

1. Metric: select node_cpu_seconds_total.
2. Label filters: add mode != "idle", since CPU time in the idle mode isn’t the part you care about visualizing. If you only have one instance of node_exporter, the job and instance labels won’t distinguish anything and can be left off; they matter once you’re monitoring more than one host.
3. Grafana will prompt that a counter like this needs a rate function applied. Switch it to rate() (or irate(), though as covered in the PromQL guide, rate() is the steadier default) over a window like 1m.
4. Under Options, change the legend from Auto to a custom format, {{mode}}, so the resulting lines are labeled system, user, iowait, and so on, instead of the full, repetitive label set.

Save the panel with a name and add it to a dashboard. Underneath the builder, a Code view shows the actual PromQL Grafana constructed, worth checking once so you can eventually skip the builder and write queries directly.

A second panel: disk usage from an expression

Not every panel comes from a single metric; some come from combining a few:

node_filesystem_size_bytes{mountpoint="/"} - node_filesystem_free_bytes{mountpoint="/"}

This computes bytes actually used on the root filesystem by subtracting free bytes from total size, filtered to the root mountpoint so temporary and virtual filesystems don’t clutter the result. Paste this directly into the panel’s Code view rather than trying to build it field by field; anything involving arithmetic between two metrics is usually faster to write than to click through a builder.

Import a community dashboard instead of building from scratch

Building every panel by hand doesn’t scale once you have dozens of metrics worth tracking, and for common exporters, someone else has almost certainly already built and published a comprehensive dashboard. Grafana’s dashboard library is searchable by exporter name, and each dashboard has a numeric ID:

1. Search the library for the exporter you’re using (node exporter, cadvisor), and pick one with good reviews and a recent update.
2. Copy its dashboard ID.
3. In Grafana, go to Dashboards → New → Import, paste the ID, and load it.
4. Select your Prometheus data source when prompted, and import.

This gets you a complete, pre-built set of panels, CPU, memory, swap, disk I/O, network errors, uptime, and more, without hand-building each one. It’s also a genuinely useful way to learn PromQL: open an imported panel’s editor and read the queries it uses for a metric you understand well, which is often clearer than reading documentation in isolation.

Customize from there

An imported dashboard is a starting point, not a final answer. Every panel remains fully editable: adjust label filters, change visualization types, tweak thresholds and colors, or delete panels you don’t need. Treat the import as scaffolding you build outward from, rather than something you either use unmodified or avoid entirely.