Exercise 1: Why a Failed Scrape Beats Push-Based Silence — Possible Solution
====================================================================

Explanation:

In the pull model, Prometheus actively initiates every scrape on its
own schedule and knows immediately, definitively, whether that
specific attempt succeeded or failed -- a connection refused, a
timeout, a non-200 response are all directly observable events, right
at the moment they happen. This failure is recorded as its own
signal: the built-in up metric flips to 0 for that target, an
unambiguous, timestamped fact ("this target could not be reached at
this specific time").

A push-based system has no equivalent certainty. If an application
simply stops pushing metrics, the monitoring system only sees an
absence of new data -- and an absence, by itself, is genuinely
ambiguous. It could mean the application crashed. It could mean the
network between the app and the collector is down. It could mean the
application is alive and healthy but has nothing new to report right
now, or its own push interval just hasn't come around yet. There's no
single, immediate event marking the moment something went wrong --
only a growing gap that has to be inferred, usually only after enough
time has passed to become suspicious, and even then without a clear
answer for WHY the data stopped arriving.

Pull turns "did this specific scrape succeed" into a single,
immediately observable fact. Push turns "is something wrong" into an
inference made from an absence, with several equally plausible
explanations.

WHY THIS WORKS AS AN ANSWER
------------------------------
This traces the difference back to WHO initiates each check and WHEN
a failure becomes observable, showing that pull produces a concrete,
timestamped failure signal while push only produces an ambiguous
absence of data, directly matching the chapter's own stated advantage.