Grafana vs Prometheus

Prometheus is a time-series database with a built-in collector. It scrapes metrics from HTTP endpoints your services expose, on a schedule it controls (the pull model), and stores them with timestamps and labels. You query that data with PromQL, its query language, which is powerful for slicing metrics by label and computing rates over time.

Prometheus also does alerting. You write alert rules in PromQL, and when a condition holds, Prometheus fires to Alertmanager, which handles grouping, silencing, and routing to email, Slack, or a pager. So Prometheus is collection, storage, and alert evaluation in one. What it is not is a dashboarding tool. Its built-in UI is a bare expression browser for ad-hoc queries, not something you put on a wall.

Grafana is the dashboard layer. It does not collect or store metrics itself. You point it at one or more data sources and build panels and dashboards that query them live. Its strength is breadth: a single Grafana dashboard can pull from Prometheus for metrics, Loki for logs, and a SQL database for business data, side by side.

Because Grafana is source-agnostic, it is the visualization front end for many different backends, not just Prometheus. That is the whole point of keeping it separate. It also has its own unified alerting now, which overlaps with Alertmanager, and a wider observability stack of its own (Loki for logs, Tempo for traces, Mimir for long-term metrics) if you go all-in on Grafana Labs tooling.

Two overlaps cause the confusion. First, alerting: both can do it. Prometheus evaluates PromQL alert rules and routes through Alertmanager; Grafana can define alerts on its panels. Pick one path so you are not maintaining alerts in two places. Many homelabs use Grafana alerting for simplicity because it lives next to the dashboards.

Second, the question of who stores the data. Grafana storing dashboards makes people assume it stores metrics too. It does not. If you uninstall Prometheus, your Grafana dashboards go blank, because the data lived in Prometheus. That dependency is the key mental model: Prometheus is the source of truth, Grafana is the window onto it.

Prometheus without Grafana is reasonable if you only need alerting and the occasional ad-hoc PromQL query, and you do not care about pretty dashboards. Plenty of infrastructure runs Prometheus plus Alertmanager and never installs Grafana, because the job is paging on problems, not staring at graphs.

Grafana without Prometheus is common too, but only because the metrics live somewhere else. If your data is already in InfluxDB, a cloud monitoring service, or a SQL database, Grafana visualizes that directly and you never touch Prometheus. So the real choice is never Grafana versus Prometheus. It is which data source feeds your metrics, and whether you want dashboards on top.

For monitoring a homelab, the well-worn path is Prometheus plus Grafana plus a set of exporters. Node Exporter reports host metrics (CPU, memory, disk), cAdvisor reports per-container metrics, and Prometheus scrapes them on a schedule. Grafana sits on top with community dashboards you can import in minutes for exactly these exporters.

If you would rather not assemble that yourself, all-in-one options exist. Netdata gives you per-second metrics and dashboards out of the box with almost no setup. Zabbix is a heavier, integrated monitoring system with its own database and UI, which the Prometheus vs Zabbix comparison covers. But if you want the flexible, label-driven model that scales from one node to a cluster, Prometheus collecting and Grafana visualizing is the combination to learn.