Exercise 2: A 45-Second Batch Job and the Pushgateway — Possible Solution
====================================================================

-- Why scraping it directly wouldn't reliably work --
--
-- Prometheus scrapes on a schedule -- commonly every 15 or 30 seconds
-- per this chapter's own example config, but the exact interval
-- doesn't matter here: the core problem is that the job's entire
-- lifetime (45 seconds) is short and, critically, the job EXITS on
-- its own once finished. Even if a scrape happened to land while the
-- job was still running, there's no guarantee a scrape interval lines
-- up neatly with the job's own start and finish -- the job could
-- easily start and finish entirely between two scheduled scrapes, in
-- which case Prometheus would never get a single opportunity to pull
-- its /metrics endpoint at all, since the process (and its endpoint)
-- would no longer exist once the next scrape came around.

-- The correct solution --
--
-- This is exactly the scenario the chapter names the Pushgateway for
-- directly: the batch job pushes its final metrics (e.g. how many
-- records it processed, whether it succeeded, how long it took) to
-- the Pushgateway once, right before it exits. Prometheus then
-- scrapes the Pushgateway itself on its normal schedule, the same way
-- it would scrape any other ordinary target -- the Pushgateway simply
-- holds onto the most recently pushed values until the next push
-- overwrites them, giving Prometheus something stable to actually
-- pull from long after the original short-lived job has already
-- exited.

-- Explicitly NOT the solution --
--
-- This scenario is exactly what the Pushgateway exists for -- but it
-- would be a mistake to conclude from this that every service should
-- push its metrics this way. The chapter's own warn-box is explicit
-- that using Pushgateway for regular, long-running services defeats
-- the pull model's own advantages (a failed scrape stops meaning "the
-- service is down" once metrics arrive through an intermediary
-- instead). It's the right tool specifically because this job is
-- short-lived and exits on its own -- not a general substitute for
-- ordinary scraping.

WHY THIS WORKS AS AN ANSWER
------------------------------
This explains precisely why the pull model structurally can't reach a
process that may finish between two scheduled scrapes, names the
Pushgateway as the chapter's own sanctioned fix, and explicitly flags
why this doesn't generalize to ordinary long-running services,
matching the chapter's own stated boundary around when push is and
isn't appropriate.