[collectd] generic JMX plugin

[matthew sporleder]

On Sun, Aug 2, 2009 at 6:40 AM, Florian Forster<octo at verplant.org> wrote:
> 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.
>

This works for me.

> 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.
>

I don't know how this works, actually.  I tried looking at the source
for jps and jconsole, but the source browser wasn't generating links
for each class, so it was hard to track stuff down.  (opengrok would
be much better)

I just assumed it opened a named pipe or similar when you had
-Dcom.sun.management.jmxremote set.

> 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.
>

This should work for java.lang:type=MemoryPool,name=Tenured Gen for
Usage.committed and Usage.used, right?


>> > 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.

I was thinking of the javax.management.openmbean.CompositeDataSupport
specifically, but if it's just as easy to define each attribute you
want manually into a single graph, that's fine with me.

If you were to try it, would you just keep going with the .dot syntax
until you found a real value, or would you want to try and keep going
until you found values?  I don't think there's a limit on how deeply
the "Composite navigation" in jconsole can go:
LastGcInfo.memoryUsageAfterGc keeps going, for example.  How would you
handle that amount of depth?


>
> Does that sound useful to you?
>

This is so useful it's scary.