[collectd] generic JMX plugin
Doug.MacEachern at springsource.com
Sun Aug 2 21:08:04 CEST 2009
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.
> -----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
> 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
> > > Inside the `MBean' block there are `Value' blocks which describe
> > > 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
> The code can work with wildcards, so you can specify something like
> Of course, the name of the mbean (or at least part or the name)
> 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"
> 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
> “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
> 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
> 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
> The plugin will iterate over all keys in the composite type and
> try to handle all values as numeric types. This means that
> 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
> 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 ;)
> Florian octo Forster
> Hacker in training
> GnuPG: 0x91523C3D
More information about the collectd