Introduction to JMX

The Java Management Extensions (JMX) framework is a Java technology that includes tools for managing and monitoring applications, system objects, and service-oriented networks. The JMX framework is designed to simplify the management of local and remote Java applications. The JMX framework introduces the concept of MBeans for real-time management of applications, whereby resources are represented by objects called MBeans (Managed Beans).

JMX is to Java applications, what SNMP is to network devices. Therefore, JMX is a very important mechanism that is widely used by monitoring and management tools to collect performance metrics about Java applications. This article will cover the basics of the JMX framework architecture and components and concepts such as MBeans and how they can be leveraged for enterprise grade proactive monitoring and performance troubleshooting.

eG Enterprise and Java Virtual Machine Monitoring using JMX

Figure 1: A dashboard showing key JVM metrics collected using JMX

The use of JMX technology is deeply embedded and automated within eG Enterprise’s platform to ensure out-of-the-box performance and availability of Java Virtual Machines (JVMs) correlated alongside end-to-end monitoring of the entire application and infrastructure stack. For a general overview of JVM monitoring, please see: JVM Monitoring Tools – Java Virtual Machine Monitoring of Threads, Garbage Collection, Memory Leaks & more (eginnovations.com).

What is JMX and How does JMX Monitoring Work?

Java Management Extensions (JMX) is a Java technology that includes tools for managing and monitoring applications, system objects and service-oriented networks. Those resources are represented by objects called MBeans (Managed Beans). An MBean can represent a device (such as a printer), a web server (e.g., a JVM server), an application, or any resource that needs to be managed.

JMX uses a three-level architecture:

  • The Probe level contains the probes (called MBeans) that represent different attributes about the resources being monitored.
  • The Agent level, or MBeanServer – exposes the MBeans to applications. A Java Management Extensions (JMX) agent is a management entity that runs in a Java Virtual Machine (Java VM) and acts as the liaison between the MBeans and the management application. The MBean server is the core component of a JMX agent.
  • The Remote Management level enables remote applications to access the MBeanServer through connectors and adaptors. A connector provides full remote access to the MBeanServer API using various communication protocols (RMI, IIOP, JMS, WS-* ). A connector is specific to a given protocol, but the management application can use any connector indifferently because they have the same remote interface.

Figure 2: The three level JMX architecture

A decent overview of MBeans is available from Oracle, see: Lesson: Introducing MBeans (The Java™ Tutorials > Java Management Extensions (JMX)) (oracle.com).

Full documentation of the JMX framework architecture is available in, The Java Management Extensions (JMX) Technology Overview from Oracle, including version and specification information.

How does JMX help with Java Application Monitoring?

JMX can be used in multiple ways for Java application monitoring:

  • Monitoring of the JVMs running on a server is done using JMX. Within eG Enterprise, agents connect to standard MBeans exposed by the JVMs to collect key performance metrics including threads running in the JVM and their states, when garbage collection happens, how much memory is released during garbage collection and so on.
  • Standard Java application servers such as Tomcat, JBoss, WebSphere, WebLogic, etc. expose performance metrics through JMX. JMX interfaces facilitate both agent and agentless monitoring of these application servers.
  • Custom MBeans exposed by applications running on these application servers can also be monitored.

Figure 3: Monitoring threads in different states in a JVM using JMX

eG Enterprise supports agent-based and agentless monitoring of Java applications using JMX, allowing application and IT operations teams to monitor Java applications without needing to write any code.

What are JMX MBeans?

Short for Managed Beans, MBeans are objects in Java and are a type of JavaBean, created with dependency injection. An MBean gives programmatic access to management tools for system objects, devices, and application monitoring and management, and allow other tasks to be executed. An MBean represents a resource running in the Java Virtual Machine (JVM), such as an application or a Java EE technical service (transactional monitor, JDBC driver, etc.). They can be used for collecting statistics on concerns like performance, resources usage, or problems (pull); for getting and setting application configurations or properties (push/pull); and notifying events like faults or state changes (push).

MBeans are registered with JMX agents. JMX agents are the entities running either locally or remotely which provide the management access to the MBeans registered with them. Within the JMX agent there is a core component (MBeanServer) which maintains registry of managed MBeans and provides an interface to access them.

Baeldung have a simple (very short) tutorial on setting up MBeans that is very insightful and worth a read, see: Basic Introduction to JMX | Baeldung.

Ensuring Secure JMX Access

Given the wealth of metrics that JMX can provide, security during access is important. The JMX security specification which is a part of the Java Management Extensions (JMX) Specification includes three forms of security:

  1. Authentication: The remote client needs to be authenticated in the connector server. For this purpose, the JMX client uses JMX APIs and provides credentials to connect to the server.
  2. Access control: MBean access control limits who can access the MBean information and who can perform the MBean operations. When a JMX operation is performed, a security check is done to check whether the program needing permission already has the permission for that operation. MBean policy definitions are used to define access control permissions.
  3. Secure transport: The transport between the JMX client and server can be secured with TLS/SSL. To use SSL, the truststore, truststore type and truststore password must be configured on the MBean client. Java system properties can be used for this.

More details about JMX security configurations are provided in this useful article, Java Management Extensions (JMX) security.

Use Cases of JMX Monitoring

#1 Memory Analysis of JVM

Memory leaks in Java applications can occur due to improper coding logic. Monitoring the JVM’s heap utilization will indicate a problem, but will not indicate why the problem is happening. The application may crash with java.lang.OutOfMemoryError and restarting the application may solve the problem for a bit, but the issue will occur again and again. JMX monitoring helps collect Java memory heap dumps which can be analyzed to determine:

  1. How many objects are loaded in JVM?
  2. What are the leak suspects or which object(s) are holding the major amount of JVM?
  3. How many leak suspects are found?

Java memory analysis is a two phased approach:

  • Phase 1: Take the memory dump of JVM
  • Phase 2: Analyze the memory dump

While several tools can be used for Java memory analysis, eG Enterprise provides a simple way to automate this process and save effort in isolating the problem.

Phase 1: Different Ways of Getting JVM Memory Dump

A simple, yet popular way is taking a Java memory dump manually using Jconsole utility, which is bundled with the JDK. The production support engineer can run this utility and connect to the JMX port of the Java application. In the Overview tab of Jconsole, you can see metrics like heap utilization, thread utilization etc. Use the MBeans tab and go to the dumpHeap node as shown in the screenshot below.

Figure 4: Using JConsole to generate a JVM heap dump

A memory dump of the JVM is a scan of the JVM’s memory at that moment in time. Other JDK built-in tools such as JVisualVM, jcmd, jmap can also be used to collect Java memory dumps.

If the JVM Option –XX:+HeapDumpOnOutOfMemoryError is configured for your JVM, it will take a memory dump automatically, if your application crashes with the java.lang.OutOfMemoryError exception.

Phase 2: Analyzing the Java Memory Dump

You will need to analyze the dump file to get the leak suspects. Tools such as Eclipse Memory Analyzer can be used in this phase.

Figure 5: MAT analyzes heap dumps to identify memory leak suspects

MAT identified 3 leak suspects after analyzing the memory dump, which was taken by JConsole earlier.

This is good. It makes the life of a developer or production support engineer easier. But this is reactive! In addition, it is taking some time to do all these. Is there a way to be more proactive and faster?

Figure 6: eG Enterprise leak suspects monitoring highlights the Java classes that could be leaking memory

eG Innovations JVM Leak Suspects monitoring helps engineers to achieve these aims. It performs phase 1 and 2 periodically and alerts the user proactively if any object consumes higher memory than threshold. In the above figure, eG Innovations JVM monitoring has identified 3 leak suspects before the application crashes. Importantly, it can be seen that the leak suspects existed for prolonged periods from the timeline chart given below.

Figure 7: Leak suspects reported over time by eG Enterprise

Besides identifying the suspects, eG Enterprise’s detailed diagnosis capability also provides the top memory consuming classes and their contribution to heap utilization.

Figure 8: Details of leak suspects in eG Enterprise points to the exact classes that are responsible for a JVM memory leak

#2 Identifying Blocked Threads and Deadlocks

In a multi-threaded application, the production support engineer may have to keep an eye on blocked threads. JMX enables them to have visibility about this. Sometimes, a single thread that is blocked for a long time will be an issue. In other cases (depending on the application design and functionality), if many threads are blocked even for a few seconds, this will be a problem.

Deadlock is something which nobody wants to see. It denotes a cyclic condition caused by improper coding. Deadlock can be fatal in production environments.

Identifying such scenarios quickly is important to run the services with minimal interruption.

Figure 9: Reporting of blocked and deadlocked threads in a JVM using eG Enterprise’s JMX monitoring

How to Monitor Custom Java Applications with JMX Technology

Many application developers use JMX technology, providing MBeans to expose metrics relating to the performance of their custom applications. eG Enterprise allows application and IT operations teams to monitor these custom applications without needing to write any code. With eG Enterprise, you can:

  • Auto-discover MBeans of a target application
  • Pick and choose which MBeans you are interested in monitoring
  • Also have the option to import the MBeans of interest to you
  • Track the values of these MBeans tracked historically; Track raw values, rate of change etc.
  • Auto-baseline the metrics and receive proactive alerts if the values go out of bound.

AIOps capabilities built into the eG Enterprise platform automate deployment and minimizes manual configuration allowing you to monitor and manage large numbers of applications at scale. Many application developers use eG Enterprise over other tools for its capabilities for monitoring custom Java applications and out-of-the-box abilities to alert instantly when abnormalities are noticed.

Out-of-the-box Monitoring, Alerting and Dashboards for Java Applications

Whilst it is important for IT and application administrators to understand the technologies and architectures of the JMX framework, a good enterprise solution will be designed to automatically take advantage of any JMX integration in place. The application or resource owner and development teams will expose whatever information is appropriate via MBeans and a decent observability platform such as eG Enterprise will automatically pick up the relevant information. At this point as an administrator all you need to know whether a monitoring tool has such a JMX integration. Beyond that you will want to investigate:

  • How good the features and interfaces to investigate applications and JVMs are – are there rich dashboards, reporting, and synthetic monitoring capabilities?
  • Does the product provide full observability monitoring of the JVMs and also the web containers that run on them? and can the solution support containerized environments that rely on Kubernetes and Red Hat OpenShift?
  • Are thresholds for alerts on metrics, events and logs automatically configured and is auto-baselining and dynamic thresholding possible to ensure alerting and anomaly detection can be used without onerous manual configuration?
  • Is the solution scalable and manageable with 100s or 1000s of applications and / or servers?

Figure 10:  A custom dashboard depicting application and infrastructure health

For those looking to build-their-own: What is JMX and Why do we need it? – DevOpsSchool.com gives a good idea of the work involved in integrating directly with the JMX framework. Questions such as “How to register an Application to MBean Server?” and “What is JConsole?” are covered in this article.

eG Enterprise is an Observability solution for Modern IT. Monitor digital workspaces,
web applications, SaaS services, cloud and containers from a single pane of glass.

Free Trial  See the platform

Related Information

About the Author

Pandian Ramaiah is a Technical Consultant based in the eG Innovations’ Singapore office. He works with customers across the APAC region providing technical advice and solution architectures to implement modern observability across a wide range of technologies including APM, infrastructure and databases.