more flexibility desired from Registry interface

[danevandyck]

Hello, hope this finds you well. We're using this library and are happy with its interface and performance in general.

The Registry's interface doesn't support the following usecase, which seems valid.

• create a metric family with a generic name (e.g. http_request_seconds) and some labels
• later create a family with the same name but a different set of constant labels
• get one of the two already allocated instances by Adding its name / labels

Well, I guess it supports it, but only through the NonStandardAppend insert behavior. That behavior isn't suitable for our use since it seems to result in unbounded growth of the set of families absent de-registration.

Functionally, a Family instance provides a convenient way of passing labels through to a component. For example, consider a usecase where I update the same metric (http_request_seconds) in two different components. Ideally, I'd be able to allocate a Family instance with the component name as a label of each. So each metric added to each family instance gets that component label.

[jupp0r]

Hey,

would GetMetric() from #418 solve your issue?

[danevandyck]

No, the problem is the registry rather than the family. We want to be able to add metric families with the same name but different sets of labels. We can't use the non-standard-append insert behavior for the reasons mentioned above.

The registry insert behavior we want is:

• check if a metric with the same name and labels exists
• if so, return it
• if not, create a new one with the specified name and labels

I you approve of the idea, I'm happy to submit a patch.

[nidoyle]

I may have a similar requirement, was looking for functionality similar to GoLang's client library, 'CounterVec' and 'GaugeVec' metrics, where based on the labels supplied with .WithLabel() an existing counter or new counter was created and then updated.

[jupp0r]

@danevandyck I can see what you want, but it would introduce some inconsistencies into the API, which makes me reluctant to make changes to better support your use case:

• what happens if you create families with different metric types (Gauge and Histogram)
• what happens if the help string differs?

I think you can accomodate your use case by having one family with the intersection set of your two families, then create metrics on this family with the appropriate labels applied to them. You'd need to share these labels outside of prometheus-cpp, but that shouldn't be a problem as those will be known at compile time anyway.

Does that work for you?

Thanks!