[infinispan-dev] JOPR and managing Infinispan

[Heiko W.Rupp]

Hi Manik,

Am 17.07.2009 um 21:26 schrieb Manik Surtani:

> So while in Stuttgart presenting at the JUG there, I had a chance to
> catch up with Heiko and discuss some details of upcoming management/
> admin features for Infinispan.
>
> Immediately, we have a JOPR plugin that allows JOPR to manage
> Infinispan instances.

Note that the plugin and Jopr infrastructure can do much more than
what we currently do with monitoring and allowing the user to run
operations -- it is also possible to show configurations in the UI and
to change the configuration of managed resources. Of course the
plugin needs to support that.

> Where this does need to improve though is that the JOPR plugin is
> built with an XML definitions file that is hand written.
>
> * This should be generated as a part of the build process, by parsing
> @ManagedAttribute and at ManagedOperation annotations in Infinispan.
> * @ManagedAttribute needs to contain more information:
> 	* Type.  JOPR has a concept of different types:
> 		* informational types (labels that cannot be compared or measured),
> e.g., Version number

Those can actually be compared, but as Strings not be plotted. The  
idea behind those
so called "traits" is that those metrics (strings or numbers in  
origin) only rarely change,
so they are not stored on the server each time they are collected, but  
only when they
have changed.

> 		* measurable types (numeric) that can be compared, plotted on a
> graph, visualised in other ways, e.g., cache size
> 		* two sub-types of measurable types: incrementing and decrementing,
> e.g., number of commits

There are actually 3 sub-types: inc, dec, dynamic. The first two mean  
that the value is
strictly monotonous increasing / decreasing e.g. number of Tx  
committed. Jopr is able
for those to automatically create per minute derivates.
The last one (dynamic) means that values can "jump around".

> 		* a timing-type, (represented in milliseconds as a long), e.g.,
> average replication time

This call time thing is actually a little different (but I probably  
did not explain it well):
This has some key like e.g. a URL or a method name of a Session Bean  
and values
of it are min/avg/max (3 values).
This could perhaps be used to track replication times per channel or  
such.

> 	* This should be encapsulated as an enum and declared on each managed
> attribute so JOPR can provide better visuals on these
> 	* Some metrics need to be resettable to be meaningful, and the JOPR
> plugin would need to reset these whenever the metrics are collected.
> E.g., average replication time would need to be reset and recalculated
> every time JOPR picks up the last average and plots it on a graph.
> * @ManagedAttribute also needs to be able to describe units of
> measurement
> 	* JOPR has some allowed values here and these should be encapsulated
> in an enum.  E.g., milliseconds.  Allows JOPR to display the
> appropriate widgets based on the unit of data being displayed.

The available units are declared here:

http://viewvc.rhq-project.org/cgi-bin/viewvc.cgi/rhq/trunk/modules/core/domain/src/main/java/org/rhq/core/domain/measurement/MeasurementUnits.java?view=log

   Heiko