"Template JMX Generic" tweaked a bit in development branch svn://svn.zabbix.com/branches/dev/ZBX-6577.

The list of all changes is as follows:

1. adds "comp " prefix to jmx["java.lang:type=Compilation",...] items;
2. fixes jmx["java.lang:type=Compilation",TotalCompilationTime] multiplier, as suggested in ZBX-5590;
3. adds item jmx["java.lang:type=Runtime",VmName], as suggested here;
4. fixes "uses suboptimal JIT compiler" trigger to check for "Client" instead of "Server" (see https://www.zabbix.com/forum/showthread.php?t=38756 for "Tiered" compilers);
5. fixes typo in "Tthreads" graph name;
6. adds item jmx["java.lang:type=OperatingSystem",ProcessCpuLoad], which returns a value from 0 to 1 indicating how much CPU time this process is taking, and a trigger for that item;
7. adds items for monitoring heap and non-heap memory usage, and triggers for these items;
8. changes jmx["java.lang:type=Runtime",Uptime] item type from float to integer;
9. fixes typos in several MySQL item descriptions.

Something I have not done in this issue, but was considering, is to adjust the set of items for monitoring different memory pools. For instance, the template includes items for monitoring the following pools:

• CMS Old Gen
• CMS Perm Gen
• Code Cache
• Perm Gen
• PS Old Gen
• PS Perm Gen
• Tenured

A simple Java application that runs on OpenJDK 1.7.0_25 features the following memory pools:

• Code Cache
• PS Eden Space
• PS Old Gen
• PS Perm Gen
• PS Survivor Space

So most of the memory pool items are unsupported.

Similar situation is with garbage collectors. The current template monitors the following GCs:

• ConcurrentMarkSweep
• Copy
• MarkSweepCompact
• ParNew
• PS MarkSweep
• PS Scavenge

The Java instance I was monitoring locally only has the last two:

• PS MarkSweep
• PS Scavenge

I would be happy to investigate further if considered necessary.

As for the original request in this issue, I have added jmx["java.lang:type=Runtime",VmName] to the template because it seems interesting. However, jmx["java.lang:type=Compilation",Name] still seems to be the correct item for getting the current JIT compiler and I would like to ask the reporter to share his doubts regarding this method.

An interesting bit of trivia is that, according to OpenJDK 1.7.0_40 source code, the value of jmx["java.lang:type=Compilation",Name] is the same as "sun.management.compiler" property.

jmx["java.lang:type=Compilation",Name] seems not to provide the client/server information in general:

# /usr/java/latest/bin/java -client -version
java version "1.7.0_21"
Java(TM) SE Runtime Environment (build 1.7.0_21-b11)
Java HotSpot(TM) Client VM (build 23.21-b01, mixed mode, sharing)

# /usr/java/latest/bin/java -server -version
java version "1.7.0_21"
Java(TM) SE Runtime Environment (build 1.7.0_21-b11)
Java HotSpot(TM) Server VM (build 23.21-b01, mixed mode)

Values colleted by Zabbix from server JVM:

• jmx["java.lang:type=Compilation",Name]: 'HotSpot Tiered Compilers'
• jmx["java.lang:type=Runtime",VmName]: 'Java HotSpot(TM) Server VM'

According to the discussion linked above the 'HotSpot (64-Bit) Tiered Compilers' is preferred compiler. So you are fine unless the compiler name contains 'client' (hence the updated trigger).

(1) the jmx["java.lang:type=OperatingSystem",ProcessCpuLoad] would better be represented as percentage (adding multiplier and unit). Also when idle the returned value can be too small, resulting in nonsupported value. Converting to percentage would at least lessen if not eliminate this problem (it fixed for me, but I'm not sure how small the returned value could theoretically be).

asaveljevs Regarding returned value being too small, this is probably already fixed by ZBXNEXT-78.

wiper Yes, I might not have merged upstream before testing.

asaveljevs Regarding process CPU load, RESOLVED that in r39508.

wiper CLOSED

(2) I have also addressed Marc's suggestion in r39510 by adding trigger

#1 . Before, we checked for JIT compiler, but that is not the only thing that distinguishes a client VM from a server VM. Also, I did "str(Server)#1" instead of "str(Client)=1", because it is possible to start Java not only with "-client" and "-server", but also other kinds of VMs:

$ java -help |& grep VM
    -server       to select the "server" VM
    -zero         to select the "zero" VM
    -jamvm        to select the "jamvm" VM
    -avian        to select the "avian" VM
                  The default VM is server,

wiper reviewed, tested and CLOSED

Successfully tested

Improvements available in pre-2.1.9 (trunk) r39550.