Should we support a hierarchy of metrics?

[mikecroft]

Currently (for 1.0), Metrics exposes a flat list of available metrics.

There is a possibility of supporting a hierarchy instead (as discussed in #26). Is this a good idea and for what use case might we want to implement it?

[keilw]

That sounds a bit similar to Spring Boot (which I used as inspiration for a recent project, but we could do without hierarchical metrics there)
Of course there are plenty of caveats, especially if the hierarchy should allow to cummulate values, you must not mix the unit

[kwsutter]

Can we clarify what hierarchy is being proposed? I read through #26 and Heiko's recent post to the Google group. In Heiko's post he mentioned allowing more than one app per server. Is that a common topology? Given the cloud environment and kubernetes control of app servers, it would seem that a more common topology would be to limit one app per server.

[keilw]

#26 talks a lot about hierarchies in the sense of rest endpoints or "actuators". If there's just one /metrics endpoint per server, then a hierarchy on the rest level could only be added via filters like /metrics/SOMETHING as mentioned. Maybe we should distinguish between hierarchy and aggregate.