Clone Family.metrics and iterate over family

[JaydenElliott]

Problems

1. There is no way to copy/clone the HashMap<S,M> within family.

   • Use case: Storing metrics to compare against later

2. There is no way to iterate over a metric Family or get metrics without knowing the labels.

   • The only to get all metrics is to manually call get_or_create() for every metric. This isn't great if you don't know the label names (don't store them etc...).

I am happy to tackle these if you want. I think making M clone (not sure why it isn't atm) and returning a new hashmap with the cloned values would fix both these problems.

[mxinden]

Can you expand on the use-cases that you want to solve with the above proposed changes?

[JaydenElliott]

Sure.

Iter

The primary problem I have found when using this library is that without knowing all the label keys, it's not possible (please let me know if it is) to get any metrics.

Suppose I have an application that requires me to spawn n components to process some workload. At runtime each of these will be spawned and assigned a uuid. In order to monitor these I would like to attach a metrics counter to each (using uuid as the primary label field). I will create a Family<ComponentLabel, Counter> for this.

Now suppose I am now in some other part of the application and would like to iterate over every metric in that family. The only way to do this at the moment (i believe) would be to store a vec of uuids that you inserted into the family and manually iterate over each and get_or_create().

The family "hashmap" is already storing all the data we need to iterate over it, but doesn't expose any functionality to interact with it (outside of get_or_create). Requiring a separate data structure to store insertions for later seems wasteful and unessesary.

Clone

Using the above example, suppose I want to compare metrics of each component over time. To do this, I would like to take a snapshot of the metric family at time t and then some time later in the processing take another snapshot and then compare the two. This may be used for example to see if the processing is lagging (counters are not increasing).

This is not possible at the moment as M (in `Family<S,M>) is not clone and the underlying family hashmap isn't exposed.

Suggestion

To solve both these problems I suggest making M clone (in Family<S,M>) and exposing the read method of family.metrics.

E.g. in metrics/family.rs:

 pub fn read(&self) -> RwLockReadGuard<HashMap<S, M>> {
        self.metrics.read()
    }

This would solve both these problems and allow a user to do something like:

family .read().iter() .map(|(label, counter)| { do_something() })

Also providing a snapshot() method on the registry,family or metrics would be nice. This should be easy to implement and give user's a nice interface to compare metrics over time.

[gamgi]

I am also looking for these features.

My use case is to expose some metrics and labels, via a proprietary endpoint in addition to the standard /metrics endpoint. Currently I have to store the inserted labels in a HashSet which seems unnecesary.

[cratelyn]

I would also be interested in this, @mxinden.

My use-case loosely mirrors what @gamgi said above. Additionally, I'm interested in writing test cases that make assertions on what time series do or do not exist within a Family<S, M, C>.

The ability to iterate over a family of metrics would allow me not only to check that my expected time series exist and are set to the proper values, but also to check that other unexpected time series will not be emitted by my application.

Would a PR adding an IntoIterator implementation to Family be welcome?

I'll cross-reference my comment in #231, which concerns how singular metrics are fetched from a family. Ideally, any iterator implementation would not be subject to the same deadlock concerns, and could emit Item = M items.