Monitoring EAP 6.1

[fcorneli]

I would like to add EAP 6.1 to my collectd monitoring. For JBoss AS 6.1 I have the following connection string: service:jmx:rmi:///jndi/rmi://localhost:1090/jmxrmi

I've found several documents online stating that for JBoss AS 7.1+ this should become: service:jmx:remoting-jmx://localhost:4447

However, this is not working for me. Is there somewhere an updated documentation on how to JMX connect to JBoss EAP 6.1 for monitoring purposes?

[ctomc]

Hi,

you can find more information on how remoting-jmx works on this link:

https://community.jboss.org/wiki/UsingJconsoleToConnectToJMXOnAS7

--

tomaz

[erhard]

Hi Frank,

You may consider using the HTTP-management interface instead of JMX. Like:

http://localhost:9990/management?json.pretty

http://localhost:9990/management/subsystem/logging/logger/com.arjuna?operation=attribute&name=level

Regards

Erhard

[fcorneli]

I don't really have a choice of picking another interface. Collectd comes with a JMX plugin, so it has to be JMX as I don't want to write a Collectd plugin specific for JBoss AS 7.2/EAP 6.1.

Already tried the service:jmx:remoting-jmx://localhost:9999 URL which works perfect with jconsole (using the classpath from jconsole.sh), but for somehow reason Collectd keeps complaining:

May 20 11:31:56 localhost collectd[25090]: GenericJMXConfConnection: Creating MBean server connection failed: java.net.MalformedURLException: Unsupported protocol: remoting-jmx service URL: service:jmx:remoting-jmx://localhost:9999

So the big question is, can we still do JMX over RMI with JBoss EAP 6.1?

What I find weird is that nobody else is fighting with this. How the heck are people monitoring their JBoss AS instances?

[fcorneli]

For those interested in monitoring EAP 6.1 using collectd, I've written a patch for the curl_json collectd plugin to support Digest authentication which seems to be required for the management API.

See also: https://github.com/collectd/collectd/issues/328

[stainless85]

it might be useful.. check below.

http://everything-jboss.blogspot.kr/2013/06/ways-of-connecting-to-as-7-using-jmx.html

[miheys]

Hello, I have met the same issue using collectd 5.4.1 and JBoss. According to previous posts I could connect to target JBoss JMX from Java (both JConsole and self-written JMX client) having jboss-cli-client.jar in classpath and using "service:jmx:remoting-jmx://<host>:9999" as service URL and JBoss management credentials. But when I tried the same with collectd I always got "GenericJMXConfConnection: Creating MBean server connection failed: java.net.MalformedURLException: Unsupported protocol: remoting-jmx". I tried putting jboss-cli-client.jar in jdk1.7.0_40/jre/lib/ext/, defining -Xbootclasspath/a:/usr/share/collectd/java/jboss-cli-client.jar and even dynamically extending classpath (regular collectd Java plugin) - nothing worked. Then I found out that there is no context class loader in plugin thread and that exactly class loader used by JMXConnectorFactory and ServiceLoader as default one (if not defined otherwise via properties). According to collectd GenericJMX plugin source code they DO REDEFINE class loader: environment.put(JMXConnectorFactory.PROTOCOL_PROVIDER_CLASS_LOADER, this.getClass().getClassLoader());. But binary behaves like it is not defined.

So, until latest collectd GenericJMX plugin being distributed is not updated (fix was committed by Alexandre Moutot on 2013-10-09, but was merged into 5.4 only on 2014-09-06) we can define context class loader in plugin thread. It worked, however it added complexity to deploying custom plugin.

Solution:

1. Extend GenericJMX plugin:

import org.collectd.api.OConfigItem;

import org.collectd.java.GenericJMX;

import javax.management.remote.JMXConnectorFactory;

public class GenericJMX2 extends GenericJMX {

    @Override

    public int config(OConfigItem ci) {

        setClassLoader();

        return super.config(ci);

    }

    @Override

    public int read() {

        setClassLoader();

        return super.read();

    }

    private void setClassLoader() {

        Thread.currentThread().setContextClassLoader(ClassLoader.getSystemClassLoader());

    }

}

2. Add your jar to -Djava.class.path in JVMArg and instead of LoadPlugin "org.collectd.java.GenericJMX" use LoadPlugin "com.foo.bar.jmx.GenericJMX2". Regular JMX plugin configuration is left as is.

Hope it will help somebody.