Hi,
always the same problem, I still manage to better understand what is the real problem. I'll try my best to describe the problem, and I hope someone can help me.
For a while, I try to monitor JRockit JVM for Tomcat. To do this, I chose the solution zabbix + zapcat. The only problem, zapcat was designed for Sun JVM. After much research (and lots of little details forgotten stupidly), I found that there was apparently only one small difference to enable the JMX agent necessary zapcat:
For Sun JVM:
-Dcom.sun.management.jmxremote
For JRockit:
-Dcom.oracle.management.jmxremote
I confess that I saw a little ashamed that I took time to find this ... But it turned out that this was not the only difference.
To test, I first tried with a Sun JVM to verify that everything worked properly. After several parameters forgotten (unblocking listening ports for example ...), everything was OK, MBeans (created by the JMX agent) were correctly transmitted by the Zapcat JMX Bridge to Zabbix server.
I therefore turn to JRockit, and there the beginning of the investigation begins:
After putting the correct argument in the Tomcat console I could see that the JMX bridge was done correctly:
But there is a problem of MBeans:
Each JMX demands from zabbix's server, the agent returns that is not supported (although these demands worked correctely with Sun's JVM):
jmx[Catalina:type=Manager,path=/,host=localhost][activeSessions]
I have several assumptions, some may be deficient:
- The command doesn't enable the JMX agent (there was another command, -Xmanagement, but prevented from starting the Tomcat server)
- There is a difference between JRockit's MBeans and Sun JVM MBeans (but which?)
- (more wacky, I think) the command that enables the JMX agent, opens a default listening port to the local machine, the default listening port is noted in the Zapcat agent to retrieve and transmit MBeans . But this default listening port can be different for JRockit?
I despair about this problem, would really need help ... Please let me know your ideas
Thanks
always the same problem, I still manage to better understand what is the real problem. I'll try my best to describe the problem, and I hope someone can help me.
For a while, I try to monitor JRockit JVM for Tomcat. To do this, I chose the solution zabbix + zapcat. The only problem, zapcat was designed for Sun JVM. After much research (and lots of little details forgotten stupidly), I found that there was apparently only one small difference to enable the JMX agent necessary zapcat:
For Sun JVM:
-Dcom.sun.management.jmxremote
For JRockit:
-Dcom.oracle.management.jmxremote
I confess that I saw a little ashamed that I took time to find this ... But it turned out that this was not the only difference.
To test, I first tried with a Sun JVM to verify that everything worked properly. After several parameters forgotten (unblocking listening ports for example ...), everything was OK, MBeans (created by the JMX agent) were correctly transmitted by the Zapcat JMX Bridge to Zabbix server.
I therefore turn to JRockit, and there the beginning of the investigation begins:
After putting the correct argument in the Tomcat console I could see that the JMX bridge was done correctly:
But there is a problem of MBeans:
Each JMX demands from zabbix's server, the agent returns that is not supported (although these demands worked correctely with Sun's JVM):
jmx[Catalina:type=Manager,path=/,host=localhost][activeSessions]
I have several assumptions, some may be deficient:
- The command doesn't enable the JMX agent (there was another command, -Xmanagement, but prevented from starting the Tomcat server)
- There is a difference between JRockit's MBeans and Sun JVM MBeans (but which?)
- (more wacky, I think) the command that enables the JMX agent, opens a default listening port to the local machine, the default listening port is noted in the Zapcat agent to retrieve and transmit MBeans . But this default listening port can be different for JRockit?
I despair about this problem, would really need help ... Please let me know your ideas
Thanks
Comment