Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Way to unregister "MetricFamily" from registry #204

Closed
tyrone-wu opened this issue Jun 25, 2024 · 2 comments
Closed

Way to unregister "MetricFamily" from registry #204

tyrone-wu opened this issue Jun 25, 2024 · 2 comments

Comments

@tyrone-wu
Copy link
Contributor

tyrone-wu commented Jun 25, 2024

Hello! 👋

I have a usecase that can be split into 2 separate issues (let me know and I can split it 👍), but I'll have them here for now to describe my overall usecase.

I'm creating a library with sub-systems that each manage their own registry, and are logically grouped together to form a root registry. For each sub-system, they hold some state that is used to register/unregister metric families.

For the first part of my usecase, I've tried using sub_registry_with_prefix() and the Collector trait, however, they both have these limitations:

  • For sub_registry_with_prefix(), since it returns a reference, I can only operate on the sub_registry within the same scope when it's first created.
  • For the Collector trait, the collector struct can't be modified after it's registered.

If possible, I'd like for my sub-systems to either "own" their sub_registry so that they can individually manage their own metrics. Perhaps something similar to Family, so Vec<Rc<RwLock<Registry>>> or Vec<Rc<RefCell<Registry>>> for sub_registries?

For the second part of my usecase, this is simply adding a way to unregister metric families, something like Registry::unregister(&mut self, name: &str, unit: Option<Unit>)?

If these changes make sense to be apart of the library, I'd be happy to open a PR for these. 🐱
And sorry if what I described above is messy, I can elaborate if need be.

@tyrone-wu
Copy link
Contributor Author

tyrone-wu commented Jun 25, 2024

Actually #154 solves the first part of my usecase since I can just stitch together the registries of my sub-systems. 👍

The only part left is just a way to unregister a metric family.

@tyrone-wu tyrone-wu changed the title Retrieve sub_registry with prefix. and unregister "MetricFamily" from registry ~Retrieve sub_registry with prefix. and~ unregister "MetricFamily" from registry Jun 25, 2024
@tyrone-wu tyrone-wu changed the title ~Retrieve sub_registry with prefix. and~ unregister "MetricFamily" from registry Way to unregister "MetricFamily" from registry Jun 25, 2024
tyrone-wu added a commit to tyrone-wu/client_rust that referenced this issue Jun 27, 2024
All credits on the initial idea, implementation, and testing belong to
@amunra, who is the original author of this PR prometheus#154.

From the original PR description:

Adds new `encode_registry` and `encode_eof` functions to allow encoding
of parts of the response.

This is useful when there are multiple registries at play, or when
composing metrics for a process that embeds Rust as part of its logic
whilst serving metrics to Prometheus outside of Rust.

Fixes: prometheus#153
Refs: prometheus#154, prometheus#204

Co-authored-by: Adam Cimarosti <amunra@users.noreply.github.com>
Signed-off-by: Tyrone Wu <wudevelops@gmail.com>
tyrone-wu added a commit to tyrone-wu/client_rust that referenced this issue Jun 27, 2024
All credits on the initial idea, implementation, and testing belong to
@amunra, who is the original author of this PR prometheus#154.

From the original PR description:

Adds new `encode_registry` and `encode_eof` functions to allow encoding
of parts of the response.

This is useful when there are multiple registries at play, or when
composing metrics for a process that embeds Rust as part of its logic
whilst serving metrics to Prometheus outside of Rust.

Fixes: prometheus#153
Refs: prometheus#154, prometheus#204

Co-authored-by: amunra <amunra@users.noreply.github.com>
Signed-off-by: tyrone-wu <wudevelops@gmail.com>
tyrone-wu added a commit to tyrone-wu/client_rust that referenced this issue Jun 27, 2024
All credits on the initial idea, implementation, and testing belong to
@amunra, who is the original author of this PR prometheus#154.

From the original PR description:

Adds new `encode_registry` and `encode_eof` functions to allow encoding
of parts of the response.

This is useful when there are multiple registries at play, or when
composing metrics for a process that embeds Rust as part of its logic
whilst serving metrics to Prometheus outside of Rust.

Fixes: prometheus#153
Refs: prometheus#154, prometheus#204

Co-authored-by: amunra <cimarosti@gmail.com>
Signed-off-by: tyrone-wu <wudevelops@gmail.com>
tyrone-wu added a commit to tyrone-wu/client_rust that referenced this issue Jun 29, 2024
Adds function `unregister` that remove a metric family from the registry
from the family's name and unit (if present).

Fixes: prometheus#204

Signed-off-by: tyrone-wu <wudevelops@gmail.com>
tyrone-wu added a commit to tyrone-wu/client_rust that referenced this issue Jun 29, 2024
Adds function `unregister` that remove a metric family from the registry
from the family's name and unit (if present).

Fixes: prometheus#204

Signed-off-by: tyrone-wu <wudevelops@gmail.com>
@tyrone-wu
Copy link
Contributor Author

Alright, so I have sort of a working progress. Removing it from metrics list is pretty straightforward, however, there's the issue how to approach cleaning up leftover Arc references to Family.

My initial idea was to have priv_register() return a Weak<dyn Metric>, however I'm learning that adding a Clone trait bound to Metric doesn't make it object-safe. I won't lie, I'm not rusty enough to completely understand all the ins and outs of these internal things. 😵

tyrone-wu added a commit to tyrone-wu/client_rust that referenced this issue Jul 3, 2024
All credits on the initial idea, implementation, and testing belong to
@amunra, who is the original author of this PR prometheus#154.

From the original PR description:

Adds new `encode_registry` and `encode_eof` functions to allow encoding
of parts of the response.

This is useful when there are multiple registries at play, or when
composing metrics for a process that embeds Rust as part of its logic
whilst serving metrics to Prometheus outside of Rust.

Fixes: prometheus#153
Refs: prometheus#154, prometheus#204

Co-authored-by: amunra <cimarosti@gmail.com>
Signed-off-by: tyrone-wu <wudevelops@gmail.com>
mxinden pushed a commit that referenced this issue Jul 7, 2024
#205)

All credits on the initial idea, implementation, and testing belong to
@amunra, who is the original author of this PR #154.

From the original PR description:

Adds new `encode_registry` and `encode_eof` functions to allow encoding
of parts of the response.

This is useful when there are multiple registries at play, or when
composing metrics for a process that embeds Rust as part of its logic
whilst serving metrics to Prometheus outside of Rust.

Fixes: #153
Refs: #154, #204

Co-authored-by: amunra <cimarosti@gmail.com>
Signed-off-by: tyrone-wu <wudevelops@gmail.com>
Signed-off-by: Max Inden <mail@max-inden.de>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant