Exercise 2: Why Prometheus and Grafana Are Two Separate Tools — Possible Solution
====================================================================

Why they're described as separate tools with distinct jobs:

Per the chapter, "Prometheus stores and queries metrics, but its own
native UI is minimal... Grafana is the dashboarding/visualization
layer commonly paired with it." Each tool solves a genuinely DIFFERENT
problem, and neither one's job substitutes for the other's:

PROMETHEUS's responsibility: COLLECTION and STORAGE of metrics data.
Per the chapter, it works by PULLING (scraping) metrics from
configured targets -- applications exposing a `/metrics` endpoint, or
node-level exporters (often running as DaemonSets, per `k8s2-2`) --
at regular intervals, and storing that time-series data so it can be
queried later. Prometheus's job ends at having the data available and
queryable; it doesn't concern itself with how that data gets
PRESENTED to a human looking at it.

GRAFANA's responsibility: VISUALIZATION and PRESENTATION. It doesn't
collect or store any metrics data of its own at all -- it connects to
a data source (commonly Prometheus, though it supports others) and
turns the raw queried data into dashboards, graphs, and visual
displays that are actually useful for a person to look at and
understand at a glance.

Why this separation matters (rather than being one combined product):

Each tool can be swapped, upgraded, or replaced somewhat independently
-- Grafana can visualize data from data sources OTHER than Prometheus,
and Prometheus's own data can in principle be queried by tools other
than Grafana. Treating them as one combined product would obscure this
genuinely useful separation of concerns: one tool focused entirely on
reliably collecting and storing the data, another tool focused
entirely on making that data legible to a human.

WHY THIS WORKS AS AN ANSWER
------------------------------
This states each tool's SPECIFIC job (collection/storage vs.
visualization/presentation) directly from the chapter, and explains
why keeping them as genuinely separate tools -- rather than one
product -- is a deliberate, useful design rather than an arbitrary
split, addressing the "common point of confusion for newcomers" the
chapter itself names.