Extracting the methods of metrics_util::registry::Registry into a trait

[david-perez]

I think one of the great features of metrics_util::layers::Layer is how it makes Recorders composable. Usually Recorders hold a registry of all metrics emitted. It'd be cool if we could build and compose registry-agnostic Recorders, so that the same Recorder implementation could work with e.g. a registry backed by a hash map or by a struct.

The metrics_util::registry::Registry struct is a building block that already offers a nice interface I'd expect an arbitrary registry to have: at the very least it needs to have methods to get and register metrics (used by the Recorder), and methods to visit and drain metrics (used by the "exporter", the piece of code responsible for transferring the metrics out of the Recorder and into the sink).

Does this sound reasonable? Should we have a Registry trait, perhaps in the metrics_util crate?

[david-perez]

At the very least, I think such a trait should have the following methods:

• clear

And for each metric kind k (Counter, Gauge, Histogram):

• delete_k
• get_k
• get_or_create_k
• visit_k

Additionally, ideally get_or_create_k would be fallible to indicate when a metric could not be inserted (e.g. in a struct-backed registry, a key with an incorrect field name was used / a constrained-length collection ran out of space, etc).

[tobz]

Overall, I'm in favor of trait-ifying the "backend" of an exporter, and I've talked about it a little bit in this issue: #254 (comment)

I think your ideation around what the base set of functionality would be is also reasonable, too. Fallibility would also be nice because it would also for a slightly more straightforward interface around handling resource constraints and limits, instead of having to do something now like return a no-op handle, which gives no indication that the handle is actually non-functioning and has no way to even be interrogated to find that out.

Happy to try and mentor this work if you're looking to contribute, as my time is very limited and working on new things from scratch is just something I can't reasonably commit to at the moment.

[david-perez]

Would fallibility at the backend level trickle up to the Recorder API, making all its methods return Result? That would be a huge ergonomics hit to the current UX, but then again the current situation where we have to resort to papering over it by returning a Counter:noop handle to the user for their possibly critical metric is probably worse.