client_rust
client_rust copied to clipboard
prometheus
Global registry pattern
For systems where there are many components which need to register their own metrics, shared mutable access to the registry is required in order to keep things nice and simple (for the user). Providing a built-in solution for this pattern in the crate would lower the barrier of adoption, and could also help folks not to mess up their own implementation of the pattern where they might code the mutex incorrectly.
The prometheus crate has such a pattern, and it definitely makes getting started quite easy.
I am undecided on the topic of global registries. Not offering it within open-metrics-client thus far has been by design.
On the one hand I do understand that offering a global metrics registry within open-metrics-client directly simplifies instrumentation across ones application.
On the other hand:
- I consider global variables in general and a global metric registry in specific error prone. The implicit side effect of registering metrics with a global registry might catch folks by surprise, e.g. when importing an external library for the sake of a single helper function.
- Instead of
open-metrics-clientoffering a global registry, users can define their own within their binary.
My proposition moving forward: Instead of adding a global registry to open-metrics-client, add an example showcasing how users can define it themselves, including a disclaimer on how they might be shooting themselves in the foot.
Hi! I think making an example of global registries would be a great solution. I'd love to switch over to this library but I'm a bit reluctant to sit down and do the work of figuring out a global registry myself. Has anyone done this yet? I'd happily contribute examples or even an explainer post on my Rust programming blog. I just haven't sat down yet to figure out how to implement a global registry.
From my reading of the client library doco, there appears to be a requirement for a global registry (default collector registry): https://prometheus.io/docs/instrumenting/writing_clientlibs/#metrics
I would suppose that having a global registry is no different to having a global memory allocator.
Taking this further, having static/compile time registration could also make sense. The client library doco also appears to encourage this in the same section referenced above, albeit static, not const.
I actually think this is a non-issue. You don't need a global registry, you need global metrics. Your individual metrics can be global, and accessible by both your registry and your normal code. The registry can read them and serve them without being global!
See my example here. Here I have a local registry, which is owned by the HTTP server which serves metrics. But my counter is in a lazy_static block, and can be read by both the registry and my normal business logic code.