> It is also unclear to me if it's really appropriate to digest some
> statistics before exposing them to the outside world. In example, how
> the methods in DocumentStoreStats returning time series as
> CompositeData play with other monitoring solutions like
> ElasticSearch/Kibana? How easy is to consume and aggregate this data
> for a monitoring solution?
From my experience and IMHO:
Using CompositeData (e.g. javax.management.openmbean.Oak. CompositeDataSupport
from Repository Statistics) has the advantage to be easy to read by end-users
but when it comes to ingest it with monitoring solution it’s more complicated.
Some of the monitoring tools are not all able to cope with CompositeData (e.g.
JMX Module from Logstash doesn’t support this structure) and this required us
to write specific scripts to extract the appropriate data.
Same with tabular data, a monitoring application won’t be able to deal directly
with array: what is the time reference of each item 1 per minute, 1 per 5
minutes? If the array cover an interval of 60min and the monitoring solution is
pulling every minutes it will have to remove data he already got from previous
pull, etc.
With simple format as it is done for example with fulltext-async.INDEXER_TIME
(Min, Max, OneMinuteRate, etc.), it more likely that it can be directly
ingested by monitoring solutions. The drawback seems that it requires to create
MBean for each metrics you want to expose as it cannot be grouped into more
“complex” data structure.
> IMO aggregation should in general be left to the monitoring
> infrastructure. Our MBeans should only provide the raw data. An
> exception is when querying the raw data would result in to many calls.
> E.g. for tracking the max. read time.
I agree with you but there should be anyway a level of aggregation (e.g.
1min/5min/10min) otherwise:
- Getting the metrics at time T is not representative of what happen between
[T-1, T] and we might miss some important event which happened in between.
- Retrieving an array with raw value will go against having simple format I
exposed above.
Regards,
Michael.
On 14/02/17 10:16, "Michael Dürig" <mdue...@apache.org> wrote:
On 13.2.17 6:21 , Francesco Mari wrote:
> Is it
> appropriate for IOMonitorMBean to perform some kind of aggregation,
> like sum and average? Should richer data be returned from the MBean,
> like tabular data?
IMO aggregation should in general be left to the monitoring
infrastructure. Our MBeans should only provide the raw data. An
exception is when querying the raw data would result in to many calls.
E.g. for tracking the max. read time.
Michael
