[collectd] JVM statistics collection?

Justo Alonso justo.alonso at gmail.com
Thu Sep 11 11:27:41 CEST 2008

Hi !

  I'm working on a JNI-JMX plugin. It's work as snmp plugin ... you define
instances (a jvm with jmx on) and for each instance the beans that collectd
will pull it.

  On start collectd, we up one jni connection, and foreach instance, we
create a new java JMXConnector (with the instance parameters). On pull,
foreach instance, we call the JMXConnector get method and pass it to

 I hope to send to the list a alpha-alpha version in two weeks.

thanks in advance, and sorry for me english


On Thu, Sep 11, 2008 at 7:59 AM, Brian Long <brian at dotspots.com> wrote:

> Hi Steve,
> I've integrated collectd with JMX in our systems. We use it to poll the JVM
> as well as any other relevant metrics we want from our applications.
> What I ended up doing was creating a MonitoredResource and
> MonitoredAttribute annotation (similar to ManagedResource and
> ManagedAttribute) which can be applied to any bean and getter. Then I have a
> MonitoredAnnotationBeanPostProcessor which registers all beans and their
> attributes which wish to be monitored. A MonitoringAgent bean is constructed
> which emits a single JMX operation, getMonitoredBeans. This returns a
> collection of object names and attributes which have been decorated by the
> Monitored* annotations and registered via the post processor. (And since
> there are no beans to annotate for JVM metrics, I just hand-register all the
> interesting JVM objects/attributes in code...)
> I have a bridge process with is invoked by the exec plugin which connects
> to an app and retrieves all monitored beans by invoking getMonitoredBeans
> (via JMX obviously). It proceeds to then retrieve all the monitored
> attributes by retrieving each attribute for each object name emitted in
> getMonitoredBeans. The bridge is responsible for turning object names and
> attributes into plugin/type/instance/data source labels that are posted by
> Everything about this works fine... the only thing we had to revisit was
> launching the bridge app at every iteration. We eventually turned it into a
> long-running process which never exits, just to avoid the overhead of
> bringing up a new JVM each time.
> This is obviously very specific to a system which is based around Spring,
> but I found it very simple to emit new metrics this way - all you need to do
> is apply the annotations and everything works completely automatically.
> -B
> On Wed, Sep 10, 2008 at 5:59 AM, steve hillier <
> shillier at halogensoftware.com> wrote:
>>        Hi,
>>        I've read through the docs and faq, and done a few test builds
>>        from
>>        source, but did not find any answers to my question(s).
>>        I'm prototyping a statistics collection package that includes
>>        system,
>>        network, and JVM statistics collection. I see that collectd can
>>        do most
>>        of what I want already (great!), but I don't see anything that
>>        might
>>        point towards someone else having used it to gather JVM
>>        statistics.
>>        I'm not averse to writing my own plugin, but I don't want to
>>        reinvent
>>        the wheel either, so my question is: Has anyone ever tried to
>>        implement
>>        JVM statistics collection, specifically via JMX or some such
>>        method?
>>        If not, what barriers might I encounter trying to code up a
>>        plugin to
>>        add this functionality?
>>        Thanks,
>>        Steve.
>> _______________________________________________
>> collectd mailing list
>> collectd at verplant.org
>> http://mailman.verplant.org/listinfo/collectd
> _______________________________________________
> collectd mailing list
> collectd at verplant.org
> http://mailman.verplant.org/listinfo/collectd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.verplant.org/pipermail/collectd/attachments/20080911/7753c16d/attachment-0001.htm 

More information about the collectd mailing list