vinzenz/hyperhive
vinzenz/hyperhive
Watch
0
0
Fork
You've already forked hyperhive
 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions 2

grafana dashboards: shorten panel descriptions

Browse source 
Cut every panel/board description down to a short statement of what the
number is. Drops the design-reasoning prose, edge-case notes, and
operator-attributed quotes that had accumulated in an earlier pass —
useful context while building the boards, wrong shape for a tooltip an
operator glances at mid-incident.
This commit is contained in:
iris 2026-09-20 14:07:53 +02:00 • committed by mara
commit 8b8a322369
8 changed files with 94 additions and 94 deletions
Download patch file Download diff file Expand all files Collapse all files

38
nix/host-modules/swarm-grafana/dashboards/agents.json
View file

@ -6,7 +6,7 @@
},
"spec": {
"title": "hyperhive · agents",
"description": "Per-agent view: resource usage from hive-c0re's container sampler, activity from Claude Code's own export. Renamed from 'overview' — every producer we have today is per-agent, so a genuine swarm overview has nothing cross-cutting to summarise yet and should be built last, not first. Metric names are the OTLP DOTTED form, so every query uses the {__name__=\"...\"} selector — the underscore spelling matches nothing in this store. Cost/token totals use increase(), which is correct here: the claude_code.* counters are cumulative (forced in nix/agent-modules/otel.nix) but reset once per turn, since each turn is a new claude process.",
"description": "Per-agent resource usage and Claude Code activity.",
"editable": true,
"cursorSync": "Off",
"liveNow": false,
@ -129,7 +129,7 @@
"spec": {
"id": 1,
"title": "Agents reporting",
"description": "Distinct agents whose container metrics reached the store in the selected range. This counts what hive-c0re observes, not what the topology declares — a gap between the two is the interesting case.",
"description": "Distinct agents with container metrics in the selected range.",
"links": [],
"data": {
"kind": "QueryGroup",
@ -196,7 +196,7 @@
"spec": {
"id": 10,
"title": "Cost rate by agent",
"description": "USD per hour, from rate() over the cumulative counter — reset-safe. A flat line at zero is an idle agent, not a broken exporter; check the CPU panel to tell them apart.\n\nThe 10m minimum step is load-bearing, not a style choice: agents export every 60s, and measured against this store a rate window of 1m or 2m resolves ONE agent instead of five. Any shorter and the panel quietly under-reports.",
"description": "USD per hour spent by each agent.",
"links": [],
"data": {
"kind": "QueryGroup",
@ -272,7 +272,7 @@
"spec": {
"id": 11,
"title": "Container CPU by agent",
"description": "hyperhive.container.cpu.percent, sampled by hive-c0re. Percent of one core.",
"description": "Percent of one CPU core used by each agent's container.",
"links": [],
"data": {
"kind": "QueryGroup",
@ -346,7 +346,7 @@
"spec": {
"id": 2,
"title": "Cost",
"description": "sum(increase(claude_code.cost.usage)). Agent-reported, so it covers claude's own token spend only — nothing else in the swarm reports cost.",
"description": "Total USD spent on Claude Code usage.",
"links": [],
"data": {
"kind": "QueryGroup",
@ -485,7 +485,7 @@
"spec": {
"id": 21,
"title": "Tokens by model (excl. cache reads)",
"description": "Split by model rather than by agent on purpose — 'which model is the spend on' is the question this answers. Excludes type=cacheRead for the same reason as the tile above: at ~99% of volume it flattens every model into one line shaped like its cache. 10m minimum step for the same reason as the cost-rate panel.",
"description": "Tokens consumed per model, excluding cache reads.",
"links": [],
"data": {
"kind": "QueryGroup",
@ -561,7 +561,7 @@
"spec": {
"id": 3,
"title": "Tokens (excl. cache reads)",
"description": "Excludes type=cacheRead, which would otherwise BE this number: measured over 6h on this store, cacheRead was 273.5M of 275.8M total — 99.2%. Counting it makes the tile a cache-hit-rate readout wearing a token label, and it drowns the input/output volume that actually tracks work done. Remaining types: input, output, cacheCreation.",
"description": "Total tokens consumed, excluding cache reads.",
"links": [],
"data": {
"kind": "QueryGroup",
@ -627,7 +627,7 @@
"spec": {
"id": 30,
"title": "Container storage by agent",
"description": "Magnitude comparison, so a bar rather than seven lines. One fixed colour on purpose: the agents are nominal categories, and colouring them by size would encode the bar length twice.",
"description": "Disk usage per agent's container.",
"links": [],
"data": {
"kind": "QueryGroup",
@ -702,7 +702,7 @@
"spec": {
"id": 31,
"title": "Lines of code changed",
"description": "claude_code.lines_of_code.count carries a `type` label (added / removed). 10m minimum step for the same reason as the cost-rate panel.",
"description": "Lines of code added and removed by Claude Code.",
"links": [],
"data": {
"kind": "QueryGroup",
@ -778,7 +778,7 @@
"spec": {
"id": 32,
"title": "Active time by agent",
"description": "claude_code.active_time.total — seconds an agent was actually working, not wall-clock uptime.",
"description": "Seconds each agent spent actively working.",
"links": [],
"data": {
"kind": "QueryGroup",
@ -854,7 +854,7 @@
"spec": {
"id": 33,
"title": "CLAUDE.md size by agent",
"description": "hyperhive.agent.claude_md.lines over time — mara: \"i want to see it over time\" (a bargauge snapshot in an earlier round of this panel only showed the current count). A continuously-live gauge, not a per-turn counter, so this is the raw value plotted across the range, same treatment as the CPU/memory-by-agent panels above rather than a rate()/increase(). The harness itself raises a loose-ends todo past 500 lines suggesting a trim, not a hard limit — this panel is visibility, not an alarm.",
"description": "Lines in each agent's CLAUDE.md file over time.",
"links": [],
"data": {
"kind": "QueryGroup",
@ -928,7 +928,7 @@
"spec": {
"id": 4,
"title": "CLI sessions started",
"description": "claude_code.session.count counts CLI STARTS, and the harness starts one claude process per turn — so this reads as turns, not as long-lived sessions. Named for what it measures rather than what the metric is called.",
"description": "Claude CLI turns started, one per session count.",
"links": [],
"data": {
"kind": "QueryGroup",
@ -994,7 +994,7 @@
"spec": {
"id": 40,
"title": "Subagent cost",
"description": "sum(increase(claude_code.cost.usage{subagent!=\"\"})). `hive-subagent-mcp` stamps a `subagent=<name>` resource attribute (alongside the parent's own `agent=<name>`) on every claude_code.* sample a spawned subagent turn emits — this label already existed, it just wasn't plotted anywhere.",
"description": "USD spent by subagent turns.",
"links": [],
"data": {
"kind": "QueryGroup",
@ -1060,7 +1060,7 @@
"spec": {
"id": 41,
"title": "Subagent turns",
"description": "claude_code.session.count where subagent!=\"\" — a proxy for subagent turns, same PROXY caveat as the plain 'CLI sessions started' tile above.",
"description": "Number of subagent turns run.",
"links": [],
"data": {
"kind": "QueryGroup",
@ -1126,7 +1126,7 @@
"spec": {
"id": 42,
"title": "Subagent cost share",
"description": "Subagent cost as a fraction of all cost in the selected range — 'basically free' is a claim this tile can actually check.",
"description": "Subagent cost as a fraction of total cost.",
"links": [],
"data": {
"kind": "QueryGroup",
@ -1192,7 +1192,7 @@
"spec": {
"id": 43,
"title": "Cost by subagent name",
"description": "claude_code.cost.usage summed over the selected range, split by the caller-chosen `subagent` name (e.g. an exploration/relabeling task's session name) rather than which agent spawned it.",
"description": "USD spent, split by subagent name.",
"links": [],
"data": {
"kind": "QueryGroup",
@ -1268,7 +1268,7 @@
"spec": {
"id": 44,
"title": "Subagent cost by parent agent",
"description": "Same claude_code.cost.usage{subagent!=\"\"}, grouped by the spawning agent's own `agent` label instead — which agent's subagent habit is actually costing something.",
"description": "USD spent on subagents, split by parent agent.",
"links": [],
"data": {
"kind": "QueryGroup",
@ -1344,7 +1344,7 @@
"spec": {
"id": 45,
"title": "Distinct subagents (range)",
"description": "How many differently-named subagents ran at all in the selected range, not how many turns they took — 'Subagent turns' above already covers volume, this answers a different question (mara: \"show subagent count in time range\"). Counts subagent label values with at least one turn (increase(...) > 0) rather than every label value claude_code.session.count has ever carried, so a stale series with no turns in-range doesn't inflate the count.",
"description": "Number of differently-named subagents that ran.",
"links": [],
"data": {
"kind": "QueryGroup",
@ -1410,7 +1410,7 @@
"spec": {
"id": 46,
"title": "Distinct subagents by agent, over time",
"description": "mara: \"the subagent should already stamp the agent on the metric. so i want to see count of distinct subagent names per agent name over time\" — it does (claude_code.session.count carries both agent and subagent labels on a subagent's own turns). One line per parent agent: at each point, how many differently-named subagents had at least one turn in the trailing $__rate_interval window. This is a ROLLING distinct count, not a running total — it can go back down once a batch of subagents stops running, same shape as any other rate()-style panel on this board. A true concurrent-right-now count (subagents open at this exact instant, able to rise and fall between scrapes) would need hive-subagent-mcp to publish its own gauge on start/stop; nothing does today, and that's a different, harder ask than this one.",
"description": "Distinct subagent names active per agent, over time.",
"links": [],
"data": {
"kind": "QueryGroup",