feat(monitoring): expose per-channel share work to Prometheus

[gimballock]

sv2_client_channel_hashrate reports nominal_hashrate — the value a miner declared when opening the channel, not what it produced. A dashboard built on it shows nameplate for a throttled or dead miner.

That number has been wrong in three separate ways already (#242 — not updated on SetTarget; #262 — stale when enable_vardiff = false; #670 — idle downstreams inflating the aggregate). And #248 was resolved by deleting sv2_client_channel_shares_per_minute, which likewise reported a configuration value as a measurement.

Change

Expose sv2_client_channel_share_work_total from the share_work_sum each channel already accumulates. rate() over it gives measured work per second, alongside the declared figure rather than replacing it — the divergence between the two is itself useful.

Labels mirror sv2_client_channel_hashrate exactly, so the existing stale-label bookkeeping removes both together when a channel goes away. No new label dimension, so the per-channel series count goes from 10 to 11 rather than multiplying.

The value is cumulative per channel. A per-channel series ending when that miner disconnects is the intended behaviour for a per-miner view, so no process-level accounting is needed here — unlike #802, which fixes a total that must outlive the channel that produced it.

On adding a series

This does add one series per channel, which is worth stating plainly given cardinality is under discussion elsewhere. Two things bound it: it introduces no new label dimension, and the far larger per-channel cost is the eight pre-seeded shares_rejected codes, which are a total rather than a per-channel quantity and could move to process scope. I'd like to propose that separately. Net, the direction is a reduction; this is the one addition I think earns its place, because the alternative is a hashrate panel that cannot distinguish a throttled miner from a healthy one.

Scope

Client-side only. The server-side structs carry acknowledged_work_sum and validated_work_sum rather than share_work_sum. Choosing between them — or exposing their divergence, which is arguably the more interesting signal, because it is work we validated that upstream did not acknowledge — is a separate question I'd rather not answer incidentally here.

Label hygiene is also out of scope. client_id churns on every reconnect and fragments a miner's history, which affects every per-channel metric equally. Worth addressing across all of them at once rather than diverging one.

Naming

_total because the value is cumulative, matching the convention already used for sv2_client_shares_accepted_total (also a cumulative Gauge). It also keeps rate() and increase() free of the PossibleNonCounterInfo annotation, which is a name-suffix heuristic. Counter-reset correction is applied by value rather than by declared type, so a monotonic gauge rates correctly, including across the resets that occur when a channel's accounting is reset.

Verified

stratum-apps 109/109 with monitoring and 119/119 with asic-rs-telemetry; clippy and fmt clean; pool and miner-apps unaffected; openapi.json byte-identical, because this touches no API type.

The test uses deliberately distinct nominal_hashrate and share_work_sum values, and I confirmed it fails when the wrong field is wired — [100.0, 100.0] instead of [4242.0, 7.5] — because silently reporting the declared value is exactly the failure mode #248 was about.

🤖 Generated with Claude Code