4
votes

I need to monitor my VCenter Server application(It's a Java application) using JMX.

I have seen many posts on this and followed but still I'm not able to get it to work.

The VCenter is running on a VM on our internal network.

Had made these changes in the wrapper.conf file

wrapper.java.additional.22="-Dcom.sun.management.jmxremote"
wrapper.java.additional.23="-Dcom.sun.management.jmxremote.port=1100"
wrapper.java.additional.24="-Dcom.sun.management.jmxremote.ssl=false"
wrapper.java.additional.25="-Dcom.sun.management.jmxremote.authenticate=false"
wrapper.java.additional.26="-Djava.rmi.server.hostname=hostname where vcenter runs"
#wrapper.java.additional.27="-Dcom.sun.management.jmxremote.rmi.port=1100"

I'm able to connect Jconsole to 1100 port locally. As soon as I start the service, I see that the port listens properly

PS U:\> netstat -an | findstr 1100
   TCP    0.0.0.0:1100           0.0.0.0:0              LISTENING
   TCP    [::]:1100              [::]:0                 LISTENING

As soon as I try to connect it from my laptop, it displays this

PS U:\> netstat -an | findstr 1100
  TCP    0.0.0.0:1100           0.0.0.0:0              LISTENING
  TCP    "ipofvcenterserver":1100      11.248.18.xx:51988     ESTABLISHED
  TCP    [::]:1100              [::]:0                 LISTENING

[Update] I noticed that if I add Dcom.sun.management.jmxremote.rmi.port=1100 , and I connect using jconsole, the established connections shows as below. But 11.248.18.xxx is not the IP address of the remote client (my laptop)

PS U:\> netstat -an | Findstr 1100
  TCP    0.0.0.0:1100           0.0.0.0:0              LISTENING
  TCP    ipofrmiserver:1100      11.248.18.xxx:56728     ESTABLISHED
  TCP    ipofrmiserver:1100      11.248.18.xxx:56729     ESTABLISHED
  TCP    [::]:1100              [::]:0                 LISTENING

I see that there is some connection established, but still, jconsole complains that it is not able to connect

Troubleshooting steps were done:

1) Turned off firewall on the vcenter server machine to keep things simple 2) telnet to 1100 works from my laptop 3) tried copying the jmxremote_optional.jar to VMWARE_JAVA_HOME\lib which is C:\Program Files\VMware\vCenter Server\jre\lib according to this post https://meteatamel.wordpress.com/2012/02/13/jmx-rmi-vs-jmxmp/ 4) Able to ping hostname of server where Vcenter runs 5) tried without this wrapper.java.additional.27="-Dcom.sun.management.jmxremote.rmi.port=1100" 6) Tried tcpdump, but couldn't make any sense since I'm not a network guy.

Updating log image enter image description here

Updating config images

enter image description here

Can't imagine anything else. If anyone else has some clue, please advice.

1
Where is JMX code? What is problematic part? your script? JMX code? JConsole? I am confused.kosa
There is no java code involved. I use Jconsole application from my laptop to connect to a remote java process which is my Vcenter application running on the remote machine.I provide the IP address of the remote machine and the port number in Jconsole remote process section. The configuration shown is the Vcenter application running on Tomcat on the remote machine.Vikram
Ok, so what is the response you are getting on JConsole?kosa
Connection failed:retry? The connection to "11.168.32.xxx":1100 did not succeed. Would you like to try againVikram
Try JConsole with debug trace and post the stack. blogs.oracle.com/jmxetc/entry/…kosa

1 Answers

0
votes

Finally was able to get it working for one service. Hope people don't have to spend 3 days tearing hairs to figure this out.....

The file in question was in C:\Program Files\VMware\vCenter Server\vdcs\vdcserver\conf\server.xml

<Listener accessFile="${catalina.base}/conf/jmxremote.access" authenticate="false" bind="11.168.32.xx" className="com.springsource.tcserver.serviceability.rmi.JmxSocketListener" passwordFile="${catalina.base}/conf/jmxremote.password" port="${base.jmx.port}" useSSL="false"/>

The bind value above seems to override the wrapper.conf properties, it was earlier 127.0.0.1. And changed the authentication to false seemed to do the trick temporarily. Would need to work to make it more secure now.