Feedback required for providing a new MetricOptions in MetricService API (SLING-5420)

[Chetan Mehrotra <ch...@gmail.com>]

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

Re: Feedback required for providing a new MetricOptions in MetricService API (SLING-5420)

[Bertrand Delacretaz <bd...@apache.org>]

Hi Chetan,

On Mon, Jan 11, 2016 at 12:04 PM, Chetan Mehrotra
<ch...@gmail.com> wrote:
> ...if no other suggestion
> would withdraw this issue and cut the first release of the bundle
> tomorrow morning..

I agree with Ian's points, having a first release with less features
sounds better to me, in order to get feedback and add just what's
really needed later, if anything.

-Bertrand

Re: Feedback required for providing a new MetricOptions in MetricService API (SLING-5420)

[Chetan Mehrotra <ch...@gmail.com>]

On Mon, Jan 11, 2016 at 3:32 PM, Ian Boston <ie...@tfd.co.uk> wrote:
> I think you should keep it simple and not add this functionality into the
> Metrics API involved in instrumentation.

okie makes sense now. If required we can capture such "meta"
information via OSGi config as its not the concern of the instrumented
code and is more of deployment concern. The MetricService API is just
meant for collection and hence should be precise and stable.

Would wait for today for thoughts from other. if no other suggestion
would withdraw this issue and cut the first release of the bundle
tomorrow morning


Chetan Mehrotra

Re: Feedback required for providing a new MetricOptions in MetricService API (SLING-5420)

[Ian Boston <ie...@tfd.co.uk>]

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 <ch...@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
>