[collectd] generic JMX plugin

[Florian Forster]

Hi guys,

On Tue, Jul 28, 2009 at 08:54:15AM +0200, Florian Forster wrote:
>   - Write a generic JMX plugin in Java, using the collectd Java
>     bindings [1]. My preferred solution would be to use the same
>     configuration as jcollectd (or at least something very similar),
>     so that they can share the configuration code.

I started reading up on this one and started coding such a generic JMX
plugin in Java. This JMX stuff is probably the most over-engineered
piece of software I've seen this year. Then again, I haven't seen much
Java code, so I have this looming suspicion that this is just the tip of
the iceberg…

Anyway, the basic problem here seems to be the mapping from “MBeans” /
attributes to types / data sources. Getting a specific MBean is easy
enough and so is getting a specific attribute. The hardest part is
decoding recursive composite types, but that shouldn't be a huge problem
either.

I have written a little mock-up configuration which demonstrates what I
have in mind. You can see it here:
  <http://verplant.org/temp/jmx.conf>
(The file will be deleted automatically in 30 days or so.)

There are `MBean' blocks and `Connection' blocks. The `MBean' blocks
define what MBean is mapped on which collectd data structure, the
`Connection' blocks define a connection to a JVM and what information to
collect. Of course, this is all very similar to the `SNMP' plugin's
configuration.

I hope that the `Connection' blocks are self-explanatory. The JMX
service URL is one of those details that's hopelessly over-engineered.
We could provide `Host' and `Port' options as an alternative and build
this magnificent URL from those. This is what some of the management
demo applications are doing. I have yet to figure out how to simply
connect to JVM on the local host using the PID.

Inside the `MBean' block there are `Value' blocks which describe one
value list (one graph) each. `Attribute' specifies the MBean attribute
to query. If it is a numeric or string type, it's simply converted to an
integer or double and submitted (see `invocations' and `runtime').
Values inside composite types can be accessed using the dot as
separator, see `LastGcInfo.GcThreadCount' in the example config.

> > Then a type, obviously, and the Table feature would be pretty handy
> > as well for getting values that come back in lists.

I'm a bit unsure on how to handle this. Your input is much appreciated.
I see basically the same two scenarios as in the SNMP plugin:

 - A scalar type (a number or a string) is expected. If a composite type
   is returned in this situation, it's an error.

 - A composite or tabular type is expected. If a “simple” type is
   returned, this is an error. The key is used as the type instance in
   this case. If multiple attributes were specified, only those keys for
   which every instance has a value will be submitted.

Does that sound useful to you?

Regards,
-octo
-- 
Florian octo Forster
Hacker in training
GnuPG: 0x91523C3D
http://verplant.org/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://mailman.verplant.org/pipermail/collectd/attachments/20090802/e40c1b94/attachment.pgp