Thanks Chetan and Julian for the pointers. On one hand I would like to do something similar - in spirit - to DocumentStoreStats. On the other hand, I don't see the advantage of the Metrics framework over a hand-rolled IOMonitorMBean with two AtomicLong fields and two volatile variables. IIUC there is no automatic way of exposing Metrics via an MBean. In fact, the DocumentNodeStoreService registers the DocumentStoreStatsMBean in the same way I would register the IOMonitorMBean from the SegmentNodeStoreService. What could be gained by adding Metrics to the trivial implementation of IOMonitorMBean described above?
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? 2017-02-14 5:13 GMT+01:00 Chetan Mehrotra <[email protected]>: > Hi Francesco, > > As Julian mentioned it would be good to collects stats as Metrics. > Have a look at DocumentStoreStats which collects some stats around > operations being performed by DocumentStore implementations > Chetan Mehrotra > > > On Tue, Feb 14, 2017 at 12:37 AM, Julian Sedding <[email protected]> wrote: >> Hi Francesco >> >> I believe you should implement an IOMonitor using the metrics in the >> org.apache.jackrabbit.oak.stats package. These can be backed by >> swappable StatisticsProvider implementations. I believe by default >> it's a NOOP implementation. However, I believe that if the >> MetricStatisticsProvider implementation is used, it automatically >> exposes the metrics via JMX. So all you need to do is feed the correct >> data into a suitable metric. I believe Chetan contributed these, so he >> will know more about the details. >> >> Regards >> Julian >> >> >> On Mon, Feb 13, 2017 at 6:21 PM, Francesco Mari >> <[email protected]> wrote: >>> Hi all, >>> >>> The recently introduced IOMonitor allows the FileStore to trigger I/O >>> events. Callback methods from IOMonitor can be implemented to receive >>> information about segment reads and writes. >>> >>> A trivial implementation of IOMonitor is able to track the following raw >>> data. >>> >>> - The number of segments read and write operations. >>> - The duration in nanoseconds of every read and write. >>> - The number of bytes read or written by each operation. >>> >>> We are about to expose this kind of information from an MBean - for >>> the sake of discussion, let's call it IOMonitorMBean. I'm currently in >>> favour of starting small and exposing the following statistics: >>> >>> - The duration of the latest write (long). >>> - The duration of the latest read (long). >>> - The number of write operations (long). >>> - The number of read operations (long). >>> >>> I would like your opinion about what's the most useful way to present >>> this data through an MBean. Should just raw data be exposed? 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? >>> >>> Please keep in mind that this data is supposed to be consumed by a >>> monitoring solution, and not a by human reader.
