Jmx4Perl reaches is next evolution step, with a bunch of new features. The most important news are a new JDK 6 based JVM agent which allows monitoring of arbitrary Java applications (not only servlet containers) and the support for bulk read requests.
Yeah, spring is coming and the growing energy needs some space to expand to ;-) jmx4perl goes into its next round with version 0.65 containing a lot of new, exciting features.
This version includes a generic JVM agent which can be used to instrument any Java application for usage with jmx4perl. The only prerequisite for now is a Sun JVM 6 since the agent uses the HttpServer included in Sun’s JVM implementation. This restriction will probably relaxed in a further version.
This agent has been successfully tested with ActiveMQ, Hadoop and Teracotta.
Now there are really no excuses to not use jmx4perl ;-)
The agent has to be added as a startup parameter for Java application to monitor:
java .... -javaagent:j4p-jvm-jdk6-0.65-agent.jar=port=7777,host=localhost ....
It can be configured via agent options or with a property file. Details are explained in the README
.
If you follow the evolution of jmx4perl, you might have noticed that since 0.40 jmx4perl can use bulk requests, which combine multiple JMX::Jmx4Perl::Requests
into a single HTTP-Request resulting in a single server turnaround. However, if you want to read multiple attributes from a single bean, or the same attribute from many, similar beans (like queue representations of a JMS provider) you would have need to setup multiple JMX::Jmx4Perl::Request
objects which can be rather tedious, e.g. if you don’t know the full MBean names in advance (you would have to do a search first).
Now there is a simple alternative with a single JMX::Jmx4Perl::Request
to collect multiple attribute values at once:
$val = $jmx->get_attribute("java.lang:type=*",
["HeapMemoryUsage","NonHeapMemoryUsage"]);
print Dumper($val);
$VAR1 = {
'java.lang:type=Memory' => {
'NonHeapMemoryUsage' => {
'committed' => '87552000',
'used' => '50514304',
'max' => '218103808',
'init' => '24317952'
},
'HeapMemoryUsage' => {
'committed' => '174530560',
'used' => '38868584',
'max' => '1580007424',
'init' => '134217728'
}
}
};
The following bugs has been squeezed and small goodies has been added, too:
GET
HTTP requests there is now an alternative representation of the pathinfo using a query parameter p. The reason for this is, that certain application servers don’t allow certain URL escaped characters for security reasons (like ‘/’, ‘' or ‘;’) in an URL path. This variant will be automatically chosen by JMX::Jmx4Perl::Agent
if it detects an unsafe character in the generated GET HTTP URLJMX::Jmx4Perl::Request
and JMX::Jmx4Perl::Agent
has been hardened in order to be more smart with unsafe MBean Names and detect automatically the most convenient HTTP Request method (if not explicitly set)JMX::Jmx4Perl
in order to get to agent and protocol version. jmx4perl’s –version shows this server side information, too, if provided with an agent urlJMX::Jmx4Perl->info
for IBM JVMs.JMX::Jmx4Perl->parse_name()
has been added for splitting up a given MBean object name into its parts, domain name and key-value pairs for the attributes.For version 0.70 a generic JMX shell is on the roadmap, j4psh, which allows for interactive access to remote JMX MBeans. It will reuse the experience gained while developing osgish, my little OSGi remote shell.
Especially the following stuff hangs around in my mind for j4psh:
What would you like to see in a JMX shell ? Let me know, it’s still conception time. As always, there are neither an ETA nor promises, though ;-)