bcrowder
24-09-2011, 01:15
Multiple-instance JVM monitoring on a single host could be improved.
Right now I have a template, and i use "virtual" hosts to monitor them. For each JVM i have a separate host defined, linked to the template, with appropriate macros defined at the host level (IP, PORT, USERNAME, PASSWORD).
I can't set up a low-level discovery because each instance of JVM requires a separate "interface" defined on the host, and the key has no distinction for an instance, as most (all?) keys for multiple-instance items do (vfs.fs, net.if).
Putting the port in as the first parameter to the key would solve the key-uniqness problem, and not require multiple "interfaces" to communicate to the separate JVMs. It would also be in line with the current usage of keys for multiple-instance items having the instance as a parameter in the key.
Ideally for me, i'd have a low-level discovery item like jmx.apps.discovery that would return a list of instances and the corresponding port (and maybe username and password) to use. I can then define a template of JMX items with name "{HOSTNAME}{#JMXAPP} - Perm Gen used" and key jmx[{#JMXPORT},"java.lang:type=MemoryPool,name=PS Perm Gen","CollectionUsage.used"]
{#JMXUSER} for username, {#JMXPASS} for password. If another instance is needed, adding it to the discovery script is 10 seconds of work.
Right now I have a template, and i use "virtual" hosts to monitor them. For each JVM i have a separate host defined, linked to the template, with appropriate macros defined at the host level (IP, PORT, USERNAME, PASSWORD).
I can't set up a low-level discovery because each instance of JVM requires a separate "interface" defined on the host, and the key has no distinction for an instance, as most (all?) keys for multiple-instance items do (vfs.fs, net.if).
Putting the port in as the first parameter to the key would solve the key-uniqness problem, and not require multiple "interfaces" to communicate to the separate JVMs. It would also be in line with the current usage of keys for multiple-instance items having the instance as a parameter in the key.
Ideally for me, i'd have a low-level discovery item like jmx.apps.discovery that would return a list of instances and the corresponding port (and maybe username and password) to use. I can then define a template of JMX items with name "{HOSTNAME}{#JMXAPP} - Perm Gen used" and key jmx[{#JMXPORT},"java.lang:type=MemoryPool,name=PS Perm Gen","CollectionUsage.used"]
{#JMXUSER} for username, {#JMXPASS} for password. If another instance is needed, adding it to the discovery script is 10 seconds of work.