You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
At present (v0.19.0 and previously) the prometheus_client.registry.Registry class is secondary in terms of API control flow to the prometheus_client.metrics.MetricWrapperBase and subclasses in that a caller says prometheus_client.Counter() and doing so implicitly first instantiates a new metric and then registers the names it defines into the global registry.
This makes the default behavior of the library code-reloading unsafe. Today if you reload code which invokes Counter(), you get a new counter instance which encounters a name conflict when it tries to register itself.
It would be better if the primary interface first performed a get-or-set against the specified registry so that reloading would re-fetch the original counter functionally as a singleton.
The real solution is that we should be explicitly managing and lifecycling registries, but the library default behavior of using a shared global registry creates this pitfall.
The text was updated successfully, but these errors were encountered:
My concern with a get-or-set feature is what if two files actually tried to create identical metrics? Then you could get unexpected behavior if the second usage started changing the metric defined in the first file. I would prefer to error in that case, but maybe I am missing something?
Another option could be to make it easier to clear an entire registry (including the default registry). Would that also help your reloading use case?
At present (v0.19.0 and previously) the
prometheus_client.registry.Registry
class is secondary in terms of API control flow to theprometheus_client.metrics.MetricWrapperBase
and subclasses in that a caller saysprometheus_client.Counter()
and doing so implicitly first instantiates a new metric and then registers the names it defines into the global registry.This makes the default behavior of the library code-reloading unsafe. Today if you reload code which invokes
Counter()
, you get a new counter instance which encounters a name conflict when it tries to register itself.It would be better if the primary interface first performed a get-or-set against the specified registry so that reloading would re-fetch the original counter functionally as a singleton.
The real solution is that we should be explicitly managing and lifecycling registries, but the library default behavior of using a shared global registry creates this pitfall.
The text was updated successfully, but these errors were encountered: