Version 8

    Overview

    I wanted to outline some misunderstanding and give some guidance on monitoring java web apps via remote JMX. The flavor of how you're hosting the java application, e.g. Tomcat, Websphere, etc, all follow the same foundation.

     

    This article builds off this previous article and assumes you have a working Java server with remote JMX enabled.

    Understanding Java Remote JMX - Initial Setup/Config Overview

     

    In SAM, there are some Java templates out of the box and several more shared here on Thwack. I'll use the Java Virtual Machine (JMX) template but the concepts will be the same for all java templates.

     

     

    Assigning the template

    When i'm assigning the template just choose 'Inherit credentials from node.' This is because in the previous article we set this java option: jmxremote.authenticate=false. If you have this option set to true, then you'll want to ensure you assign the correct credentials.

     

    Now, what you'll notice is when you test the template that not all of the monitors come back green. Honestly, that is expected, nothing is actually broken. There are hundreds of libraries that could be used when java is compiled. That allows for a lot of variations in how data is returned. All this means is that it comes down to mapping to the correct metric (MBean). A common one to fail is Garage Collection. Let's dive into what mapping means.

     

    I'm going assign the template anyways with the failed tests. Then, edit the template and find the one that's failing.

     

    JMX MBean Mapping

    When I expand the Memory Garbage Collections Count i'm going to focus on the area below boxed in red.

    We're going to dissect this info and correlate it back to the jconsole.exe session from the previous article. To break out the above I'm just going to use a few lines.

     

    Object Name: java.lang

    Type=GarbageCollector

    Name=Copy

    Attribute Name=Collection Count

     

    In jconsole, go to the MBeans tab and follow the breakdown above. Navigate to the java.lang folder, then GarbageCollector folder. You'll see Copy in there and a sub category called Attributes with an entry for CollectionCount.

    *When a test fails on a template it just means I can't find the exact entry. If you looked in the jconsole session you wouldn't find it either. However, it's common to drill into the mbean tree and see something next to it. e.g. I've expanded the same tree and in the Attributes section I would see 'PM Collection Count' instead of just 'Collection Count'. That just means in the SAM template we just need to update the attribute to reflect what's actually there.

    *If you have an in-house java development team, then ask them if they know where the mbean maps too. If you're using 3rd party java software then reach out to the vendor and ask them.

     

     

     

    Data in the template

    The CollectionCount Attribute in the screenshot above has a value of 15902 and that is the numeric value that SAM is polling.

     

    Going into the assigned application and drilling down in the Garbage Collection component you'll see the statistic data with the same value.

    *The value might be different based on polling intervals.

     

     

    Conclusion

    Any java application is going to have hundreds of metrics exposed as MBeans. If a component in a template fails you just need to find where that metric actually exists. Once the component is updated, it'll start polling the data.

     

    Hope this helps.