Implement methods on Registry for managing prefix and common labels

[alexforster]

This allows users to set the registry's prefix or common labels when using the default registry.

[lucab]

Here and in prefix() above, can we return a reference instead (and let the consumers clone if they want)?

[alexforster]

No, because the borrow would outlive the function call.

[lucab]

Thanks for the PR! In order to merge, this will need a rebase and a Signed-off-by on each commit.

I think we'd need a bit more context behind this. I do like the getters (minus the clone part), but I'm not thrilled by the set/clean logic. I won't expect people to use the registry that way, and the fact that those methods internally lock will likely become a bad performance surprise for many people.
I'd prefer sticking to the "set options on build" pattern and only keep the getters here.

[polachok]

I think the problem this PR is inspired by is that it's register_* macros use default registry and creating metrics with non-default registries is very verbose. At least that's what I found in my use and this PR helps a lot, I can just add labels to the default registry and use macros as usual.

Disclaimer: I'm not the author, they may have another use case.

[lucab]

@polachok thanks, that was useful feedback! Next release should come with #396 which should hopefully improve that UX aspect, but taking a different path from this PR.

That said, I'm still intimately not in favor of doing this kind of registry mutation at runtime. It's a bazooka with side-effects at distance, which can easily turn into a very large footgun.

[alexforster]

I think we'd need a bit more context behind this.

Right, I think based on your feedback that I wasn't clear on the use-case. Specifically, this is intended to make it possible to manipulate the set of default labels on the default registry. I do not believe that this adds any useful functionality for custom registries. However, I think custom registries are probably a very niche use-case anyway:

• I've never had a need to create more than one registry in any codebase. I can't even think of a hypothetical scenario where I'd want to.
• Creating a custom registry and passing it around everywhere is a huge chore. Metrics are everywhere in a typical codebase, so the registry object ends up infecting every corner of a system.

Because of this, I always use the default registry, and I bet 99% of your users do too.

I do like the getters (minus the clone part), but I'm not thrilled by the set/clean logic.

Keeping getters and removing setters doesn't add any meaningful functionality imo. The functionality I'm trying to add here is the ability to set default labels on the default registry.

I won't expect people to use the registry that way, and the fact that those methods internally lock will likely become a bad performance surprise for many people. I'd prefer sticking to the "set options on build" pattern and only keep the getters here.

Again, this is only for default labels on a Registry. Presumably default labels would only need to be configured once, not continuously.

[alexforster]

I've rebased and added a Signed-off-by

[adeschamps]

I thought I was going to need this feature, and was about to use this branch via a [patch.crates-io] entry. I wanted to expose a build version and other information that's static over the lifetime of the process. I ended up exposing it via a single gauge metric, as described in the article Exposing the software version to Prometheus instead (which I discovered via a recent blog post from the autometrics crate).

I do have a use case for multiple registries though -- we have an application that we deliver to users, and also operate as a hosted service. Some metrics measure implementation details or unstable features, so we initially add them to the default registry (which is only exposed in internal builds) and later switch them to a different registry when we're sure that they're useful for users and unlikely to be changed.