My pattern when instrumenting an application is to pass a registry around and register the metrics close to their usage. This becomes more important for larger applications in order to reduce what is passed around.
I think there's a potential foot-gun given that registering a metric internally pushes it on to a vector. This means that if a metric is registered more than once (possible, in the absence of the API stating otherwise), then a dynamic situation could result in the process running out of memory. For example, if a task was started for each connection, and that connection registered the metric each time, then memory would grow.
In terms of a solution, I think the API should document that registering a metric more than once is an error and panic. Or, use a set rather than a vector internally, and allow metrics to be registered multiple times.
My pattern when instrumenting an application is to pass a registry around and register the metrics close to their usage. This becomes more important for larger applications in order to reduce what is passed around.
I think there's a potential foot-gun given that registering a metric internally pushes it on to a vector. This means that if a metric is registered more than once (possible, in the absence of the API stating otherwise), then a dynamic situation could result in the process running out of memory. For example, if a task was started for each connection, and that connection registered the metric each time, then memory would grow.
In terms of a solution, I think the API should document that registering a metric more than once is an error and panic. Or, use a set rather than a vector internally, and allow metrics to be registered multiple times.