every /metrics scrape clones the whole signal store

Closed
  • Is something wrong?
#313 1 comment 0 reactions 1 assignee View on GitHub

Maintainers usually reply within 1 day

@valeriiashapoval is already working on this.

Since Oct 24, 2026.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
54/100
Issue type
Refactor
Clarity
Mostly clear
Activity status
Active
Tech stack
rust
Domain
observability, performance

Research direction

Start by locating SignalStore::current, the Observation type, and the metrics collector that exports PROVIDER_SIGNALS; trace how the seen key is built. Implement the borrowing visitor and static-name key described in the issue, then run the project’s relevant tests and compare scrape allocations with the current behavior. Done when unrelated observations are not cloned during collection and existing metrics remain correct.

Written by the indexing model from the issue text.

Description

area/observability enhancement priority/medium triage/accepted

SignalStore::current clones every Observation from every target, including the metric name and the full labels map, and the collector then discards most of them: only the PROVIDER_SIGNALS names are exported, so unrelated EPP gauges are cloned and dropped. The seen key then clones the metric, site and provider strings again.

With many providers and peers, each /metrics scrape allocates in proportion to the whole store.

Fix: add a borrowing visitor on SignalStore, for example for_each_current(&self, f: impl FnMut(&Observation)), run under the read lock, and key seen on the gauge's static name rather than a clone of the sample's.

Worth measuring together with the exposition-size question in the body-cap issue, since the configurations where this is hot are the ones where the exposition is large.

Dominant language
Rust
Stars
10
Forks
24
Avg merge
1d 14h
Merged PRs (30d)
143

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from praxis-proxy/grid

All issues in praxis-proxy/grid

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.