a5b1d10a39
The relay's operator's surface (the loopback listener and the Unix socket of its own user) answers a connection that opens with an HTTP/1 request line as HTTP, once, after the same check of its peer as every control request: GET /metrics (HEAD without the text) gives its counters in the text exposition format through wai/wai-metrics: sessions open and opened, tracks held and the downstream subscriptions across them, what its schedulers hold, objects in, fetches by source, the door's refusals and drops, requests refused by why, upstream requests by outcome, ratings held, going away, the unmetered energy marker, and the surface's own requests by op and refusals by why. Another path, or a request through a front, is 404; another method 405. Every other connection keeps the JSON-lines protocol. Relay::fan_out gives the tracks and subscriptions. The quantum service answers GET /metrics in its outermost layer, before the API key and the client's limits, outside its OpenAPI document and MCP endpoint: requests by route pattern, method and status, jobs held by status, the memory running jobs hold, what the store held at start, and the unmetered energy marker; through a front it is 404. Each has a test that reads its answer strictly, moves its series with real sessions or a real job, refuses each front field and finds no label value naming a party; the relay's socket test holds a peer stated as another user to the refusal before /metrics is answered. The locks that build the relay by path, and the service's, gain wai-metrics; the workflows that build either run on a change to wai/wai-metrics. Co-Authored-By: Claude Opus 5.5 <[email protected]>
23 lines
1.9 KiB
Markdown
23 lines
1.9 KiB
Markdown
### The relay and the quantum service answer GET /metrics
|
|
|
|
- **`wai-relay`** answers `GET /metrics` on its control listener, the operator's surface (a TCP
|
|
address on loopback, or a Unix socket of its own user), after the same check of its peer as
|
|
every control request: a connection that opens with an HTTP/1 request line is answered as HTTP,
|
|
once, and closed, and every other connection keeps the control surface's JSON lines. The
|
|
counters, in the text exposition format (`wai/wai-metrics`): sessions open and opened, the
|
|
tracks held and the downstream subscriptions across them (its fan-out), what its schedulers
|
|
hold, the objects counted in, FETCHes and fills by where they came from, what the receipts door
|
|
refused and dropped, requests refused by why, requests sent upstream by outcome, the rating
|
|
claims held, whether it is going away, `wai_relay_energy_unmetered` (1 when no meter samples its
|
|
own energy, so every record it signs carries the unmetered marker), and the control surface's
|
|
own requests by `op` and refusals by why. `HEAD` is answered as `GET` without the text, another
|
|
method `405`, and another path or a request carrying a field a front sets `404`.
|
|
- **`wai-quantum-service`** answers `GET /metrics` before the API key and the client's limits,
|
|
outside its OpenAPI document and its MCP endpoint: its requests by route, method and status
|
|
(the route a path matched, never the path), the jobs it holds by status, the memory its running
|
|
jobs hold, what its store held when it started, and `wai_quantum_energy_unmetered`. A request
|
|
through a front is answered `404`, as a path the service does not have.
|
|
- **No party is a label**: every label value of either is fixed in its code, so no room, track,
|
|
job, principal, token, key or address appears. Each one's test reads its answer strictly with
|
|
wai-metrics' reader, moves its series with real sessions or a real job, and finds no label value
|
|
that names a party.
|