Hi Marco,
Thanks for the workaround for registering the Runtime bean, I will add it into the docs.
Your environment seems as you say, correct, does your xymongrep program exist in /opt/hobbit/client/bin? Try changing line 6076 of the tcl to this to get some more information:
mydie "some error occurred executing $XYMONHOME/bin/$XYMONSEARCH $HTAG"
Results will vary with the version of JBoss. Despite a lot of effort, for neither old 4.2.3_GA nor 5.1.0_GA, were we able to get both the system MBeans and JBoss MBeans exposed at the same time. There were some additional JVM parameters supposed to help with that, but when we tried them, it broke the JMX stack when queried, and the JVM was thereafter basically useless. So since the system MBeans were more important to us, we settled for that. Later versions of JBoss may behave better, and expose both sets of MBeans.
This is what we get interactively for JBoss 4.2.3_GA
$ /usr/java/latest/bin/java -jar jmxsh-R5.jar -h <host> -p <port> -U MonitorRole -P <password>
jmxsh v1.0a, Tue Jul 24 16:09:47 BST 2012
Type 'help' for help. Give the option '-?' to any command
for usage help.
Starting up in shell mode.
%
Entering browse mode.
====================================================
Available Domains:
1. JMImplementation
2. jboss.ws
3. com.sun.management
4. java.lang
5. java.util.logging
SERVER: service:jmx:rmi:///jndi/rmi://<host>:<port>/jmxrmi
====================================================
And these are the major Java parameters behind this.
-Djava.security.manager
-Djava.security.policy=/apps/jboss/jboss-4.2.3.GA/server/<appserver>/conf/server.policy
-Djboss.home.dir=/apps/jboss/jboss-4.2.3.GA
-Djboss.server.home.dir=/apps/jboss/jboss-4.2.3.GA/server/<appserver>
-Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.port=<myport>
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.password.file=<mypasswordstore>
The big problem we had getting it working was updating the server.policy file to permit the JMX probes. These are the entries we came up with that were added to that file, but this really depends on whether you're running JBoss with Java Security enabled.
// MBean related permissions
grant {
permission javax.management.MBeanServerPermission "*";
permission javax.management.MBeanPermission "*", "*";
permission java.lang.management.ManagementPermission "monitor";
};
grant principal javax.management.remote.JMXPrincipal "monitorRole" {
permission javax.management.MBeanPermission "*", "getAttribute";
permission javax.management.MBeanPermission "*", "getClassLoader";
permission javax.management.MBeanPermission "*", "getClassLoaderFor";
permission javax.management.MBeanPermission "*", "getClassLoaderRepository";
permission javax.management.MBeanPermission "*", "getDomains";
permission javax.management.MBeanPermission "*", "getMBeanInfo";
permission javax.management.MBeanPermission "*", "getObjectInstance";
permission javax.management.MBeanPermission "*", "instantiate";
permission javax.management.MBeanPermission "*", "invoke";
permission javax.management.MBeanPermission "*", "queryMBeans";
permission javax.management.MBeanPermission "*", "queryNames";
};
grant principal javax.management.remote.JMXPrincipal "controlRole" {
permission javax.management.MBeanPermission "*", "*";
};
To work these out we added the following debug parameter to the JVM, and nibbled away at the access failures listed in the JBoss server log
-Djava.security.debug=access:failure
I could'nt find any attachment, can you browse to that Mbean (jboss.web:typeThreadPoll,name=http-myipserver-myports) and check that is has the attributes :
currentThreadCount
maxSpareThreads
currentThreadsBusy
minSpareThreads
MaxSpareThreads
Thanks
--
Andy
Marco Avvisano wrote:Hi Andy,
we use jboss 4.3.2 / 5.0.1, and xymon client.
For Runtime bean the problem was "not registred" values, until the first access from jmxconsole.
I solved adding the command
curl 'http://myserver:myport/jmx-console/HtmlAdaptor?action=inspectMBean&name=java.lang%3Atype%3DRuntime'; > /dev/null
in jmxstat.sh.
Probabily i have the same problem for the column GCInfo, collect on the version 5.0.1 but not on 4.3.2
I use the shell script for xymon, and the environment seem to be correct.
I get this error
+ PATH=/bin:/usr/bin:/sbin:/usr/sbin:/etc:/usr/lib/jvm/java-1.6.0-sun-1.6.0.26.x86_64/jre/bin
+ '[' -n /opt/hobbit/client ']'
+ XYMONEXT=/opt/hobbit/client/ext
+ JMXSH_JARFILE=/opt/hobbit/client/ext/jmxsh-R5.jar
+ JMXSH_SCRIPT=/opt/hobbit/client/ext/jmxstat.tcl
+ ENV=' '
+ '[' -n /opt/hobbit/client/bin/xymon ']'
+ ENV=' -DXYMON=/opt/hobbit/client/bin/xymon '
+ '[' -n /opt/hobbit/client ']'
+ ENV=' -DXYMON=/opt/hobbit/client/bin/xymon -DXYMONHOME=/opt/hobbit/client '
+ '[' -n myserverip ']'
+ ENV=' -DXYMON=/opt/hobbit/client/bin/xymon -DXYMONHOME=/opt/hobbit/client -DXYMSRV=myserverip '
+ case $@ in
+ exec /usr/lib/jvm/java-1.6.0-sun-1.6.0.26.x86_64/bin/java -DXYMON=/opt/hobbit/client/bin/xymon -DXYMONHOME=/opt/hobbit/clie
nt -DXYMSRV=myserverip -jar /opt/hobbit/client/ext/jmxsh-R5.jar /opt/hobbit/client/ext/jmxstat.tcl
some error occurred
jmxstat Usage: jmxstat [<options>] [<MBeans....>]
-b Print configured Beans
-n Dont send results to Xymon
-r value column name for status report <>
-I value Use the configuration file (default $XYMONHOME/etc/$HTAG.ini) <>
-J value Report specified JVM Name(s) <>
-x value Set debug level (0-9) <>
-B Browse Mode
-help Print this message
-? Print this message
JMX seems to report memory in kb (jboss 4,2.3). So, if i consider the conversion in the tcl in mb, and on the graph in gb, i get correct values (es . max heap size).
Found this link about (for 1.5.0) :
http://docs.oracle.com/javase/1.5.0/docs/guide/management/jconsole.html#summary
On the version 4.2.3 i need to add a new section for ThreadPool ( jboss.web:typeThreadPoll,name=http-myipserver-myports). Not always find the way to make graph :- (the value and the color status are "attached" )
Marco
Il 13/09/2012 23.19, Andy Smith ha scritto:
Hi,
Thanks for the feedback, good to hear you like it.
Regarding your questions, Memory is reported by JMX in bytes and this is converted in the tcl code to kbytes to avoid overflows in the integer arithmetic.
There is no Uptime bean, it is an attribute of the Runtime bean, I called it 'fake' because I wanted to treat it specially. Are you saying something fails for some JVM? Have they been running for a very long time, maybe uptime is overflowing? Let me know the Java version and the JBoss version I'll have a look if I can replicate it here.
If you need to specify the JVM for xymon then it sounds like the script is still trying to run bbhostgrep instead of xymongrep, anything in the logs?. There is a different shell wrapper for hobbit and xymon in the latest kit, and you need 0.1.3 of the tcl script. Have a look at the tcl script starting at line 5961 for how I envisaged this would work, the key is finding XYMONHOME in the environment instead of BBHOME. Let me know if you solve this please.
set XYMONCOMMS "xymon"
set XYMONSEARCH "xymongrep"
# inherit this from the environment or startup profile if its there
if { [info exists ::env(XYMONHOME) ] } {
set XYMONHOME $::env(XYMONHOME)
} elseif { [info exists ::env(BBHOME) ] } {
set XYMONHOME $::env(BBHOME)
set XYMONCOMMS "bb"
set XYMONSEARCH "bbhostgrep"
}