[collectd] generic JMX plugin

matthew sporleder msporleder at gmail.com
Mon Aug 3 21:00:51 CEST 2009

I got the plugin to load and I see an open connection to my host, but
I don't see any output.  Where are these stats supposed to go?

Also, where do I configure a username and password for a connection?
Right now I'm using no security.

On Sun, Aug 2, 2009 at 3:08 PM, Doug
MacEachern<Doug.MacEachern at springsource.com> wrote:
> Hi Florian,
> I don't think there's any doc on connecting to the local url, but here's how you can get it:
> String url = sun.management.ConnectorAddressLink.importFrom(pid);
> Which can be passed to new JMXServiceURL(url);  It digs into /tmp/hsperfdata_$USER/$pid to get the url.
> Looks like some interesting ideas here, I'll take a look at the branch later.
> -Doug
>> -----Original Message-----
>> From: collectd-bounces at verplant.org [mailto:collectd-
>> bounces at verplant.org] On Behalf Of Florian Forster
>> Sent: Sunday, August 02, 2009 9:38 AM
>> To: matthew sporleder
>> Cc: Benjamin Coddington; collectd at verplant.org; roman.klesel at noris.net
>> Subject: Re: [collectd] generic JMX plugin
>> Hi everybody,
>> I have a prototype of this generic JMX plugin here, ready for testing.
>> You can get it by checking out the “ff/genericjmx” branch of the Git
>> repository.
>> On Sun, Aug 02, 2009 at 09:03:33AM -0400, matthew sporleder wrote:
>> > > 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.
>> If you do, please let me know ;)
>> > 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)
>> Where can I take a look at jconsole's source?
>> > I just assumed it opened a named pipe or similar when you had
>> > -Dcom.sun.management.jmxremote set.
>> Yes, I think it's a UNIX domain socket, but I wasn't able to track it's
>> file system representation down nor found any documentation on how to
>> connect..
>> > > 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?
>> There are two concepts:
>> 1) There are MBeans which are identified by an “ObjectName”. Examples
>>    for such an object name are:
>>      java.lang:type=MemoryPool,name=Tenured Gen
>>      java.lang:type=GarbageCollector,name=PS Scavenge
>>      java.lang:type=GarbageCollector,name=PS MarkSweep
>>      java.lang:type=Memory
>>    The code can work with wildcards, so you can specify something like
>>    this:
>>      java.lang:type=GarbageCollector,name=*
>>    Of course, the name of the mbean (or at least part or the name)
>> needs
>>    to be present in the plugin instance to differentiate between, for
>>    example, a number of memory pools. This can be done using the
>>    `InstancePrefix' and `InstanceFrom' options. The syntax is roughly:
>>      <MBean "memory_pool">
>>        ObjectName "java.lang:type=MemoryPool,name=*"
>>        InstancePrefix "mempool-"
>>        InstanceFrom "name"
>>        :
>>      </MBean>
>>    This would, for example, create a values a la
>>      localhost/GenericJMX-mempool-Tenured Gen/…
>> 2) There are attributes and the types of the attributes. The objects
>>    returned by the attributes can be of various so called “OpenType”s,
>>    most notably a “composite type”. You can access a specific value
>>    within a composite type by using the dot-syntax I've talked about
>>    before. For example, in the garbage collector MBean you can find
>> this
>>    “LastGcInfo.GcThreadCount” example. Here “LastGcInfo” is the name of
>>    the attribute which is of type “CompositeType”. Within the returned
>>    object, there is an object of type integer which can be received by
>>    the key “GcThreadCount”.
>>    Of course, this also works for more levels of composite data, i. e.
>>    something like
>>      foo.bar.blah.when.is.this.going.to.end.Bytes
>>    would be possible, too.
>> > 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.
>> That's exactly the one I'm talking about here.
>> > 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?
>> The dot syntax above simply specifies the path to an object. How this
>> object is handled depends on the (new) “Table” setting:
>>   - If set to `false', the object will be cast to something numeric,
>>     i. e. a double or integer value. If it turns out not to be a
>> numeric
>>     class, for example another “CompositeData”, that's an error.
>>   - If set to `true', the object returned must be a composite type.
>>     Scalar values, such as a string, will trigger an error in this
>> case.
>>     The plugin will iterate over all keys in the composite type and
>> will
>>     try to handle all values as numeric types. This means that
>> composite
>>     values are not handled recursively. The key for each value will be
>>     used as type instance.
>>     In the “java.lang:type=Memory” example in the sample config file,
>>     you see the attribute “HeapMemoryUsage” being requested. This is a
>>     composite type. Because “Table” is set to `true', the plugin will
>>     iterate over all keys (“committed”, “init”, “max”, and “used”) and
>>     handle the associated objects as numeric types (gauge in this
>> case).
>>     If the data set had multiple data sources, only those keys present
>>     in *all* attributes will be used!
>> Does this answer your questions? Or, does anyone have any further
>> comments / ideas?
>> > This is so useful it's scary.
>> I certainly hope so ;)
>> Regards,
>> -octo
>> --
>> Florian octo Forster
>> Hacker in training
>> GnuPG: 0x91523C3D
>> http://verplant.org/

More information about the collectd mailing list