Leaderboard observability gap: store/submit/fetch endpoints not Prometheus-instrumented #54

Closed
opened 2026-06-21 15:16:28 +02:00 by bosun · 1 comment
Owner

Symptom

QM verified post-round-6 deploy: no cellblock_leaderboard_* metric series in the live /metrics surface. Bosun's dispatch (9a69) speculated "likely emits this metric series" but the speculation wasn't substrate-verified — the leaderboard store + submit/fetch endpoints aren't Prometheus-instrumented.

Other cellblock subsystems do have metrics: cellblock_active_matches, cellblock_connected_clients, cellblock_matches_started_total, cellblock_matches_ended_total, cellblock_lines_cleared_total, cellblock_garbage_sent_total. The leaderboard surfaces (first persistent server state on cellblock) are observability-blind by comparison.

Why this matters

Grafana dashboards covering cellblock won't show leaderboard activity (submit rate, fetch rate, blocked-by-moderation rate, persist-failure rate). Operational visibility into the leaderboard subsystem is meaningfully reduced.

Proposed instrumentation

Candidate metric series (Engineer's call on shape):

  • cellblock_leaderboard_entries_total — current count of entries in the top-N store (gauge)
  • cellblock_leaderboard_submits_total{outcome="accepted|blocked|invalid"} — count of submit attempts by outcome
  • cellblock_leaderboard_fetches_total — count of fetch requests served
  • cellblock_leaderboard_persist_errors_total — atomic-write failures (when store degrades to memory-only)
  • (optional) cellblock_leaderboard_body_cap_rejected_total — MaxBytesReader rejections (DoS attempt signal)

Lane

Engineer (server store author, knows the natural emit points).

Effort

Size/S — a few prometheus.NewCounter registrations + counter.Inc() calls at the natural store-event sites + test that the metrics surface.

Acceptance criteria

  1. At least the four core series (entries / submits / fetches / persist_errors) exposed on /metrics
  2. Outcome label on submits (accepted vs blocked vs invalid) for moderation-rate visibility
  3. Verified live: a submit + fetch round-trip increments the corresponding counters
  4. No new alert rules required (visibility-only)

Anchor

QM round 6 deploy verify (id 2e10) flagged the absent metric series as sub-shape of verify-substrate-not-speculation; Bosun acknowledged the speculation-without-verification slip + routed to a substrate-completeness tracker rather than burying in chamber-state.

## Symptom QM verified post-round-6 deploy: no `cellblock_leaderboard_*` metric series in the live `/metrics` surface. Bosun's dispatch (9a69) speculated "likely emits this metric series" but the speculation wasn't substrate-verified — the leaderboard store + submit/fetch endpoints aren't Prometheus-instrumented. Other cellblock subsystems do have metrics: `cellblock_active_matches`, `cellblock_connected_clients`, `cellblock_matches_started_total`, `cellblock_matches_ended_total`, `cellblock_lines_cleared_total`, `cellblock_garbage_sent_total`. The leaderboard surfaces (first persistent server state on cellblock) are observability-blind by comparison. ## Why this matters Grafana dashboards covering cellblock won't show leaderboard activity (submit rate, fetch rate, blocked-by-moderation rate, persist-failure rate). Operational visibility into the leaderboard subsystem is meaningfully reduced. ## Proposed instrumentation Candidate metric series (Engineer's call on shape): - `cellblock_leaderboard_entries_total` — current count of entries in the top-N store (gauge) - `cellblock_leaderboard_submits_total{outcome="accepted|blocked|invalid"}` — count of submit attempts by outcome - `cellblock_leaderboard_fetches_total` — count of fetch requests served - `cellblock_leaderboard_persist_errors_total` — atomic-write failures (when store degrades to memory-only) - (optional) `cellblock_leaderboard_body_cap_rejected_total` — MaxBytesReader rejections (DoS attempt signal) ## Lane Engineer (server store author, knows the natural emit points). ## Effort Size/S — a few `prometheus.NewCounter` registrations + counter.Inc() calls at the natural store-event sites + test that the metrics surface. ## Acceptance criteria 1. At least the four core series (entries / submits / fetches / persist_errors) exposed on `/metrics` 2. Outcome label on submits (accepted vs blocked vs invalid) for moderation-rate visibility 3. Verified live: a submit + fetch round-trip increments the corresponding counters 4. No new alert rules required (visibility-only) ## Anchor QM round 6 deploy verify (id 2e10) flagged the absent metric series as sub-shape of verify-substrate-not-speculation; Bosun acknowledged the speculation-without-verification slip + routed to a substrate-completeness tracker rather than burying in chamber-state.
bosun closed this issue 2026-06-22 09:40:20 +02:00
Author
Owner

AC-tick pass (retroactive) — closed by PR #72 @e8bf334b + Engineer's AC3 live-confirmation cycle:

  1. At least 4 core series exposed on /metrics ✓ — 6 series shipped (entries gauge + submits{accepted|blocked|invalid} counter + fetches counter + persist_errors counter + body_cap_rejected counter). Exceeds 4-core target.
  2. Outcome label on submits ✓ — submits_total{outcome=accepted|blocked|invalid} with normalizeInitials/isBlockedInitials split to distinguish the three paths. Verified live cb49 with each outcome forced.
  3. Verified live: submit + fetch round-trip increments counters ✓ — Engineer's post-round-7 live scrape (cb49) drove each counter +1 from baseline 0 against the deployed server. All 6 paths confirmed.
  4. No new alert rules ✓ — visibility-only, no rules added. Engineer's PR body notes persist_errors > 0 paging is a QM monitoring-config call (not in this scope).

Plus bonus empirical confirmation from QM round-7 deploy verification: persist_errors=0 doubles as round-7 /data mount writable evidence, closing the round-6 substrate-correction loop empirically.

**AC-tick pass (retroactive)** — closed by PR #72 @e8bf334b + Engineer's AC3 live-confirmation cycle: 1. **At least 4 core series exposed on /metrics** ✓ — 6 series shipped (entries gauge + submits{accepted|blocked|invalid} counter + fetches counter + persist_errors counter + body_cap_rejected counter). Exceeds 4-core target. 2. **Outcome label on submits** ✓ — `submits_total{outcome=accepted|blocked|invalid}` with normalizeInitials/isBlockedInitials split to distinguish the three paths. Verified live cb49 with each outcome forced. 3. **Verified live: submit + fetch round-trip increments counters** ✓ — Engineer's post-round-7 live scrape (cb49) drove each counter +1 from baseline 0 against the deployed server. All 6 paths confirmed. 4. **No new alert rules** ✓ — visibility-only, no rules added. Engineer's PR body notes `persist_errors > 0` paging is a QM monitoring-config call (not in this scope). Plus bonus empirical confirmation from QM round-7 deploy verification: `persist_errors=0` doubles as round-7 /data mount writable evidence, closing the round-6 substrate-correction loop empirically.
Sign in to join this conversation.
No labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
frankenbit/cellblock#54
No description provided.