Hi, IIRC (a) is doable and the prefered way of naming metrics. In other systems that use Metrics they typically use the package or class name, sometimes an API classname, in the same way that loggers do. This makes it much easier to process and report on blocks of functionality at the reporting stage. For instance when the metrics are ingested into InfluxDB using Grafana as a front end they can be filtered effectively on the metrics name.
Some background (mostly for the wider community) Oaks MetricsRegistry is deployed as a service into Sling with a name the name "oak". Sling has its own MetricsRegistry exposed as a service with the name "sling". The reporting tools aggregate all the MetricsRegistries prefixing them with their service name. Hence the Oak MetricsRegistry metrics will all be prefixed with "oak-" when reported. That means Oak doesn't need to differentiate itself from other metrics, but (a) is a good idea to avoid 100s of metrics all in 1 namespace. MetricsRegistries are designed to scale to 1000s. Anyone using a MetricsRegistry service should bind to a the "sling" registry service or create their own and register it with a unque name as is done here [1]. Thats the runtime instrumentation bundle, service named "woven". +1 to (a) Best Regards Ian 1 https://github.com/ieb/slingmetrics/blob/master/src/main/java/org/apache/sling/metrics/impl/MetricsActivator.java#L79 On 21 March 2017 at 12:53, Michael Dürig <[email protected]> wrote: > > Hi, > > AFAICS Oak's Metrics support exposes all Stats in a flat namespace under > "org.apache.jackrabbit.oak". I don't think this is desirable. We should (a) > either come up with a way to expose them by grouping related ones together > or at least (b) arrive at a consensus on how we construct the names of the > individual Stats in an unambiguous and standard way. Currently we have > different approaches in the various component resulting in a confusing list > of items. > > My preference would be (a), but I don't know if this is doable. > > > Michael >
