Hi, I think you should keep it simple and not add this functionality into the Metrics API involved in instrumentation.
If you need control over metadata associated with metrics or the behaviour of an implementation of a metrics that should (imo) be done in a separate API, optionally implemented by the metrics provider. That API would allow a consumer to set properties of metrics by name if required, and it could be versioned more frequently as new use cases emerged without destabilizing all instrumentation. Talking of use cases. I have not seen a situation where it has been proven to be helpful to have a customised histogram or reservoir. Although there are lots of arguments from a developer point of view for doing so, it damages consistency and requires that the special case is communicated to deployers who then need to find some way of accommodating that special case in the monitoring tools where consistency is vital to perform statistical analysis and correlations. Again, descriptions may help but are rarely output in reporting mechanisms and so the documentation use case is better covered by documentation of each metric. Sometimes this can be achieved by using a readable metric ID. "request" gives no context, but "org.apache.sling.engine.impl.SlingHttpContext.handleSecurity_m" is quiet an effective pointer. Best Regards Ian On 11 January 2016 at 09:42, Chetan Mehrotra <chetan.mehro...@gmail.com> wrote: > Hi Team, > > Given that 1.0 release is not yet cut I was thinking about some future > requirements and how they might impact the API. Based on that I have > opened SLING-5420 where a new MetricOptions class is proposed to > control how certain aspect of Metric collection/reporting are > controlled. > > Kindly have a look at that and provide your feedback. This would > ensure that API remains useful and stable! > > Chetan Mehrotra >
