Exercise 2: A Fleet-Wide p95 Query, and Why by (le) Is Required — Possible Solution
====================================================================

histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket[5m])) by (le))

Explanation:

rate(http_request_duration_seconds_bucket[5m]) converts each bucket's
cumulative count into a per-second rate, per instance. sum(...) by
(le) then combines those rates across every instance into one
fleet-wide set of bucket counts, keeping only the le (less-than-or-
-equal) label -- the bucket boundary itself -- while collapsing away
every other label such as instance. histogram_quantile(0.95, ...)
then computes an approximate 95th-percentile latency from those
combined bucket counts.

-- Why by (le) is required for the result to be meaningful --
--
-- histogram_quantile() works by looking at how many observations fell
-- at or below each bucket boundary and interpolating a quantile from
-- that shape -- which means it fundamentally NEEDS the le label to
-- still be present and distinct in its input, because le is what
-- tells the function which number belongs to which bucket boundary in
-- the first place. If by (le) were replaced with something else, or
-- left out entirely, the aggregation step would collapse every
-- distinct bucket boundary into a single combined number, leaving
-- histogram_quantile() with no buckets to interpolate between at all.
-- The query wouldn't error out -- it would simply return a number
-- that no longer has any real relationship to an actual 95th-
-- percentile latency, exactly the silent-failure gotcha the chapter's
-- own warn-box describes.

WHY THIS WORKS AS AN ANSWER
------------------------------
This builds the correct fleet-wide p95 query using rate() over the
_bucket metric combined with by (le), then explains the le
requirement by tracing exactly what information histogram_quantile()
needs from its input and what's lost if that label is aggregated away
instead of preserved.