Datasources, Dashboards and Panels

Scenario: A brand-new Grafana instance is opened for the first time and shows an empty screen with no graphs anywhere - not because anything is broken, but because two setup steps have not happened yet.

New words, in plain English

• Datasource - a connection Grafana has configured to an external system it can query - a URL, credentials, and a type (Prometheus, MySQL, etc.).
• Dashboard - a saved collection of panels arranged on one screen, usually focused on one system or concern - "Checkout Service Overview".
• Panel - one single visual element on a dashboard - one graph, one table, one big number - each backed by its own query.
• Panel type - the visual style a panel renders as - Time series (a line graph), Stat (one big number), Gauge, Table, and others.

An empty Grafana has nothing to show because it needs two things configured before a single graph can appear.

First, a datasource: Grafana has to be told where Prometheus actually lives (its URL) and, once told, Grafana can send it PromQL queries. Without a datasource configured, there is nothing for any dashboard to query at all - this is the single most common reason a fresh Grafana install shows nothing.

Second, a dashboard made of panels. A dashboard is just a named, saved arrangement of panels - think of it as a folder-level container. Each individual panel inside it is independent: it has its own query (written in PromQL, since the datasource is Prometheus), its own panel type deciding how the result is drawn (a line graph over time, a single big number, a gauge, a table of rows), and its own title and formatting.

A dashboard for one service typically has several panels side by side - request rate, error rate, memory usage, response time - each a separate query against the same underlying Prometheus datasource, so a viewer can see the whole health picture of that service at once.

Analogy: The datasource is Grafana's phone line to the archive room downstairs - without it connected, there is simply nobody to call. A dashboard is one page in a report binder, and each panel on it is one individual chart pasted onto that page - a bar chart here, a single number in a box there - each one separately asking the archive room its own specific question and drawing whatever answer comes back.

A worked example

# Conceptual shape of a small dashboard - NOT literal Grafana JSON,
# just the mental model of what's connected to what.

Datasource: "Prometheus" -> http://prometheus:9090

Dashboard: "Checkout Service Overview"
  Panel 1: "Request Rate"      (Time series)
    query: rate(http_requests_total{job="checkout-service"}[5m])
  Panel 2: "Error Rate"        (Time series)
    query: rate(http_requests_total{job="checkout-service", status="500"}[5m])
  Panel 3: "Current Memory"    (Stat - one big number)
    query: process_resident_memory_bytes{job="checkout-service"}

Grafana also supports importing a ready-made dashboard - a JSON file (or a numeric ID from Grafana's public dashboard library) that already defines a full set of panels for a common tool. This is extremely common in practice: rather than hand-building a dashboard for, say, a standard database exporter, most teams import a well-maintained community dashboard and adjust it, rather than starting from a blank screen.

Tip: If a brand-new dashboard shows "No data" on every panel, check the datasource connection first (is Prometheus actually reachable at the configured URL?) before assuming every single PromQL query is wrong - one broken datasource explains an entire dashboard failing at once.

Goal: Put this to work in the promgraf-import-default-dashboard lab. Open /labs/prometheus-grafana, pick promgraf-import-default-dashboard, and fix the real broken monitoring stack - a genuine Prometheus server scraping real targets, and a genuine Grafana instance querying it.