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

Removal API or more granular idle_timeout #243

Open
thedodd opened this issue Nov 14, 2021 · 1 comment
Open

Removal API or more granular idle_timeout #243

thedodd opened this issue Nov 14, 2021 · 1 comment
Labels
C-exporter Component: exporters such as Prometheus, TCP, etc. E-complex Effort: complex. S-future-work Status: valid as a potential future work item, but not currently prioritized T-enhancement Type: enhancement.

Comments

@thedodd
Copy link

thedodd commented Nov 14, 2021

  • It would be great to have an API exposed where users could remove registered metrics by name + labels.
  • Additionally, if there were a more granular idle_timeout config, such as the ability to auto-remove metrics bearing specific labels, or excluding specific labels, that could also be quite beneficial.

My immediate use case requires the first. The second is mostly convenience.

PS
Thanks for all of the excellent work on this project! I was quite relieved when I found it.

@tobz
Copy link
Member

tobz commented Nov 15, 2021

First off, you're welcome! Glad you've found this project helpful/useful.

Overall, a removal API would be nice and I can understand where you're coming from. The biggest issue is that this would essentially have to be implemented at the exporter-level as things stand right now, which means a lot of code duplication for each exporter.

At a high level, "exporters" provide the implementation of the Recorder trait, which is what sits behind all of the macros in terms of registration and emission of metrics. Due to this structure, exporters end up being responsible for both holding metrics and doing any necessary transformations, sending downstream, etc.

We've added a lot of power user knobs/features to the Prometheus exporter, so adding this capability to it wouldn't necessarily be out of the ordinary... although we're beginning the stretch the goal for the project, which is to provide composable building blocks.

If this is a feature you'd be willing to PR for the Prometheus exporter, I'd definitely be up for reviewing it, but I can't really think of a natural design to provide this generically, and don't have the time to work on coming up with such a design in the short term.

@tobz tobz added C-exporter Component: exporters such as Prometheus, TCP, etc. E-complex Effort: complex. T-enhancement Type: enhancement. labels Nov 15, 2021
@tobz tobz added the S-future-work Status: valid as a potential future work item, but not currently prioritized label Jan 3, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-exporter Component: exporters such as Prometheus, TCP, etc. E-complex Effort: complex. S-future-work Status: valid as a potential future work item, but not currently prioritized T-enhancement Type: enhancement.
Projects
None yet
Development

No branches or pull requests

2 participants