You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oak-dev@jackrabbit.apache.org by Andrei Kalfas <ak...@adobe.com.INVALID> on 2017/05/29 11:32:50 UTC
codahale metrics Jmx reporter
Hi,
I’m looking at ways of exposing oak-core metrics via coda hale metrics and looking at MetricStatisticsProvider I see that its using a Jmx based reporter.
Is this the only intended way of reporting these metrics? I would have expected to see a way to configure a different type of reporter - but perhaps I’m missing the place where that can happen.
Thanks,
Andrei
Re: codahale metrics Jmx reporter
Posted by Ian Boston <ie...@tfd.co.uk>.
On 30 May 2017 at 07:35, Chetan Mehrotra <ch...@gmail.com> wrote:
> On Tue, May 30, 2017 at 11:53 AM, Andrei Kalfas
> <ak...@adobe.com.invalid> wrote:
> > Looks to me that there is a dependency on oak functionality.
>
> Ian can confirm but I believe thats not required now (the component
> does not get activated) and was only a temporary workaround. Oak
> publishes the MetricRegistry instance in OSGi service registry and
> then any component can look up that service and configure a reporter
> for it
>
Correct. Older versions of Oak didn't publish the MetricsRegistry as a
service so it had to be extracted from Oak forcibly. (;)
Once older versions of Oak disappear, the dependency goes. I could have
done it with the class name and no dependency, but that was more effort,
and no one would have found the code to delete.
Best Regards
Ian
>
> Chetan Mehrotra
>
Re: codahale metrics Jmx reporter
Posted by Chetan Mehrotra <ch...@gmail.com>.
On Tue, May 30, 2017 at 11:53 AM, Andrei Kalfas
<ak...@adobe.com.invalid> wrote:
> Looks to me that there is a dependency on oak functionality.
Ian can confirm but I believe thats not required now (the component
does not get activated) and was only a temporary workaround. Oak
publishes the MetricRegistry instance in OSGi service registry and
then any component can look up that service and configure a reporter
for it
Chetan Mehrotra
Re: codahale metrics Jmx reporter
Posted by Andrei Kalfas <ak...@adobe.com.INVALID>.
https://github.com/ieb/statsd-reporter-osgi/blob/master/src/main/java/org/apache/sling/statsd/OakStatisticsProviderShim.java#L24 <https://github.com/ieb/statsd-reporter-osgi/blob/master/src/main/java/org/apache/sling/statsd/OakStatisticsProviderShim.java#L24>
Looks to me that there is a dependency on oak functionality.
Anyhow, thank you for the clarifications.
Thanks,
Andrei
> On May 30, 2017, at 9:13 AM, Chetan Mehrotra <ch...@gmail.com> wrote:
>
> On Tue, May 30, 2017 at 11:30 AM, Andrei Kalfas
> <ak...@adobe.com.invalid> wrote:
>> I thought that oak-core is the best position to say what metrics are needed, and the way that we want to extend the behavior is by picking whatever reporter we say fits the environment - this is why I started the thread, I wanted to understand whats the intended design.
>
> Oak is only concerned with publishing metrics to a MetricRegistry. How
> the metrics are consumed and reported are outside of Oak scope
>
> Various reporters that Ian referred are generic and can support any
> MetricRegistry and have no dependency on Oak. Hence no needs for them
> to be in Oak
>
> Chetan Mehrotra
Re: codahale metrics Jmx reporter
Posted by Chetan Mehrotra <ch...@gmail.com>.
On Tue, May 30, 2017 at 11:30 AM, Andrei Kalfas
<ak...@adobe.com.invalid> wrote:
> I thought that oak-core is the best position to say what metrics are needed, and the way that we want to extend the behavior is by picking whatever reporter we say fits the environment - this is why I started the thread, I wanted to understand whats the intended design.
Oak is only concerned with publishing metrics to a MetricRegistry. How
the metrics are consumed and reported are outside of Oak scope
Various reporters that Ian referred are generic and can support any
MetricRegistry and have no dependency on Oak. Hence no needs for them
to be in Oak
Chetan Mehrotra
Re: codahale metrics Jmx reporter
Posted by Andrei Kalfas <ak...@adobe.com.INVALID>.
Hi,
Exposing the metrics registry is about exposing the data, while exposing the reporter would be exposing behavior. Doing so, the encouraged pattern here is that you get to tap into the metrics and pick whatever you like.
I thought that oak-core is the best position to say what metrics are needed, and the way that we want to extend the behavior is by picking whatever reporter we say fits the environment - this is why I started the thread, I wanted to understand whats the intended design.
I was not saying that reporting in JMX is a good thing, I was simply stating that it can be the default in order not to break already existing assumptions.
Why are the bellow mentioned reporters not in oak?
Thanks,
Andrei
> On May 29, 2017, at 2:56 PM, Ian Boston <ie...@tfd.co.uk> wrote:
>
> Hi,
> Here are some reporters that work with Sling/Oak/AEM. [1]. They all look
> for components registered as implementing MetricsRegistry and then
> aggregate the data pumping it out to a reporter. They are all implemented
> as independent bundles. <imvho>TBH I would avoid pumping the metrics into
> JMX as JMX was designed for management, and not metrics. It might be able
> to cope with trivial metrics sets, but will likely start to consume
> unreasonable JVM resources with a production set of metrics.</imvho>.
>
> Most of the reporters in [1] are simple wrappers round other 3rd party
> Metrics reporters. If you have a target not included in that list, its
> trivial to follow the same pattern.
>
> HTH
> Best Regards
> Ian
>
> 1
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fieb%2Fstatsd-reporter-osgi&data=02%7C01%7C%7Cf54c602fdb634fb1adad08d4a689d350%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636316558271983739&sdata=1ypTPtDZV8lxw95HEYrd2llBjlu%2F4KO1e3xISA8Hd2Y%3D&reserved=0
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fieb%2Fprometheus-reporter-osgi&data=02%7C01%7C%7Cf54c602fdb634fb1adad08d4a689d350%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636316558271983739&sdata=so6%2F2Jn6m7zst5vZ3aCI25HOpOhPbk8RvomBPa7J%2B%2FA%3D&reserved=0
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fieb%2Finfluxdb-reporter-osgi&data=02%7C01%7C%7Cf54c602fdb634fb1adad08d4a689d350%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636316558271993752&sdata=qyBUqTAxLSkFUPJZGIUujBqFVOnCy5I9n4su12i%2BWSo%3D&reserved=0
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fieb%2Fgmond-osgi&data=02%7C01%7C%7Cf54c602fdb634fb1adad08d4a689d350%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636316558271993752&sdata=Wtvr1gs1nFRm5W81fGsA3l8QXUS6Cm8Z%2BMKE6%2F%2BEy2k%3D&reserved=0
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fieb%2Ftsdb-reporter-osgi&data=02%7C01%7C%7Cf54c602fdb634fb1adad08d4a689d350%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636316558271993752&sdata=V%2F%2BVdEsjyqiae1k%2BWSYGIecDt4v7loujSWdj8uue3jo%3D&reserved=0
>
> On 29 May 2017 at 12:48, Andrei Kalfas <ak...@adobe.com.invalid> wrote:
>
>> Hi,
>>
>>> By default this is the only mode.
>>
>> What would you guys rather prefer, have a different component peeks into
>> the metrics registry or change oak-core to deal with multiple reporters -
>> Jmx should be the default one.
>>
>> Thanks,
>> Andrei
>>
>>
Re: codahale metrics Jmx reporter
Posted by Ian Boston <ie...@tfd.co.uk>.
Hi,
Here are some reporters that work with Sling/Oak/AEM. [1]. They all look
for components registered as implementing MetricsRegistry and then
aggregate the data pumping it out to a reporter. They are all implemented
as independent bundles. <imvho>TBH I would avoid pumping the metrics into
JMX as JMX was designed for management, and not metrics. It might be able
to cope with trivial metrics sets, but will likely start to consume
unreasonable JVM resources with a production set of metrics.</imvho>.
Most of the reporters in [1] are simple wrappers round other 3rd party
Metrics reporters. If you have a target not included in that list, its
trivial to follow the same pattern.
HTH
Best Regards
Ian
1
https://github.com/ieb/statsd-reporter-osgi
https://github.com/ieb/prometheus-reporter-osgi
https://github.com/ieb/influxdb-reporter-osgi
https://github.com/ieb/gmond-osgi
https://github.com/ieb/tsdb-reporter-osgi
On 29 May 2017 at 12:48, Andrei Kalfas <ak...@adobe.com.invalid> wrote:
> Hi,
>
> > By default this is the only mode.
>
> What would you guys rather prefer, have a different component peeks into
> the metrics registry or change oak-core to deal with multiple reporters -
> Jmx should be the default one.
>
> Thanks,
> Andrei
>
>
Re: codahale metrics Jmx reporter
Posted by Chetan Mehrotra <ch...@gmail.com>.
On Mon, May 29, 2017 at 5:18 PM, Andrei Kalfas
<ak...@adobe.com.invalid> wrote:
> have a different component peeks into the metrics registry or change oak-core to deal with multiple reporters
I would prefer to let Oak focus on basic reporting and some other
component deal with integration with different types of reporters
Chetan Mehrotra
Re: codahale metrics Jmx reporter
Posted by Andrei Kalfas <ak...@adobe.com.INVALID>.
Hi,
> By default this is the only mode.
What would you guys rather prefer, have a different component peeks into the metrics registry or change oak-core to deal with multiple reporters - Jmx should be the default one.
Thanks,
Andrei
Re: codahale metrics Jmx reporter
Posted by Chetan Mehrotra <ch...@gmail.com>.
On Mon, May 29, 2017 at 5:02 PM, Andrei Kalfas
<ak...@adobe.com.invalid> wrote:
> Is this the only intended way of reporting these metrics?
By default this is the only mode. In addition the MetricRegistry is
registered in OSGi service registry. So some other component can look
it up and use it with different reporter. This is used in Sling to
report the metrics to Felix WebConsole [1] and [2]
Chetan Mehrotra
[1] https://github.com/apache/sling/blob/trunk/bundles/commons/metrics/src/main/java/org/apache/sling/commons/metrics/internal/MetricWebConsolePlugin.java#L106
[2] https://sling.apache.org/documentation/bundles/metrics.html#webconsole-plugin