How Grafana Relates to Prometheus

Scenario: A stakeholder asks "why do we need both Prometheus and Grafana - isn't that the same thing twice?" and nobody on the team can give a crisp answer.

New words, in plain English

• Grafana - an open-source tool for building dashboards - visual, interactive views of data pulled from other systems.
• Visualization - turning raw numbers into something a human can read at a glance - a line graph, a bar chart, a single big number with a color.
• Query - a question sent to a data source asking for specific data back - in this track, a PromQL query sent to Prometheus.

Prometheus and Grafana solve two genuinely different problems, and that is exactly why teams run both rather than picking one.

Prometheus's job stops at collecting and storing metrics, and answering PromQL queries about them through its HTTP API. It has a basic built-in web UI for running one query at a time, but it was never designed to be the polished, shareable, multi-panel dashboard a whole team looks at during an incident.

Grafana's job is exactly that: it is a visualization tool with no metric storage of its own. Grafana does not collect anything by itself - it connects to a data source (most commonly Prometheus, but also databases, logging systems and others), sends it queries, and renders the results as graphs, tables, gauges and alerts arranged on a dashboard.

In short: Prometheus is where the data lives and is queried; Grafana is how a human looks at it. Neither one replaces the other - Prometheus without Grafana still works (you can query it directly), and Grafana without a data source has nothing to show at all.

Analogy: Prometheus is a library's archive room - a vast, meticulously organized collection of records, with a librarian at a desk who can look up exactly the record you ask for by reference number. Grafana is the reading room upstairs, where those same records get laid out on a big table, highlighted, color-coded and arranged into a story a visitor can actually understand at a glance - without the reading room itself owning or storing a single book.

A worked example

# The relationship, end to end, for one graph on a screen:
#
#   Prometheus                          Grafana
#   -----------                         -------
#   scrapes targets
#   stores time series in TSDB
#   answers PromQL over HTTP    <----   sends a PromQL query
#                                --->   receives JSON results back
#                                       draws a line graph panel from it
#
# Grafana never touches the raw scraped metrics text and stores none of
# the underlying time series itself - it only ever asks Prometheus for
# results and draws what comes back.

This separation is also what makes Grafana genuinely tool-agnostic: the exact same dashboard-building skills (panels, variables, alerts) work whether the data source underneath happens to be Prometheus, a SQL database, or a logging backend. Learning Grafana is learning "how to visualize data sources" in general, not "how to visualize Prometheus" specifically - Prometheus just happens to be by far its most common one in this kind of infrastructure monitoring.

Tip: When something looks wrong on a Grafana dashboard, always ask first: "is this a Prometheus problem (bad data, wrong query, missing scrape) or a Grafana problem (wrong datasource selected, panel misconfigured)?" - they fail independently, and mixing them up wastes real debugging time.

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