Exercise 2: Why active_websocket_connections Must Be a Gauge — Possible Solution
====================================================================

Explanation:

"Active websocket connections" needs to go both up (a new client
connects) and down (a client disconnects) at any time, reflecting the
CURRENT state of the system at the moment it's read -- exactly what a
gauge is defined to represent. This is fundamentally different from a
counter's cumulative, only-ever-increasing contract.

If this were implemented as a counter instead, the metric-collection
code would presumably increment it on every new connection but would
have no correct way to represent a connection closing, since counters
are only allowed to go up (or reset to zero entirely on a restart).
Two realistic broken outcomes:

1. The counter is incremented on connect but never decremented on
   disconnect -- the number would only ever grow for the life of the
   process, permanently reporting a wildly inflated "active
   connections" figure that has no relationship to how many
   connections are actually open right now.

2. Someone tries to force it down anyway by decrementing the "counter"
   on disconnect -- but this violates the counter contract Prometheus
   and every PromQL function assumes; rate()/increase() specifically
   expect a counter to only ever increase (aside from a genuine
   process restart), so an artificially decremented "counter" would
   produce nonsensical, misleading rate calculations downstream.

Either way, the actual, currently-true number of open connections --
the thing anyone querying this metric actually wants to know -- would
never be correctly represented. A gauge has no such restriction: it's
simply set to whatever the current count is, correctly reflecting
increases and decreases alike.

WHY THIS WORKS AS AN ANSWER
------------------------------
This confirms the gauge choice by matching the metric's real-world
behavior (goes up and down) against each type's defining contract,
then works through two concrete, realistic ways a counter-based
implementation would break, rather than just stating the conclusion.