- 3 minutes to read

JMX Monitoring Agent

Keep your Java workloads healthy with Nodinite JMX Monitoring. The agent watches the CPU usage and the free heap memory of every Java Virtual Machine (JVM) you add, such as Boomi Atoms, WSO2 servers, Spring Boot services, and custom Java applications. Each JVM becomes a Resource with OK, Warning, and Error states, so your team learns that a JVM runs hot or is about to run out of heap before an OutOfMemoryError stops it.

The Nodinite Java run-time monitoring JMX monitoring uses Java OpenJDK with the GNU General Public License, version 2, with the Classpath Exception.

Benefits

  • ✅ CPU monitoring - Get a Warning or an Error when JVM CPU usage stays over your threshold for the Duration you set
  • ✅ Heap Size monitoring - Get a Warning or an Error when free heap drops below your threshold, with time to act before an OutOfMemoryError
  • ✅ Availability - A JVM that the agent can't reach shows as Unavailable
  • ✅ Multi-JVM support - Monitor many JVMs through one or more JMX Gateways, on-premise or in containers
  • ✅ Zero code changes - Enable JMX remote access with JVM startup flags; the Java application stays unchanged
  • ✅ Self-service - Share JVM status in Monitor Views and get notified through Alarm Plugins

What the Agent Monitors

You add each JVM as an Application Host under a JMX Gateway in the Configuration, and set the thresholds per Application Host. The agent evaluates two values per JVM:

Check Threshold settings Resulting state
CPU Warning Threshold %, Error Threshold %, and Duration (seconds) that CPU usage must stay over the threshold ⚠️ Warning or ❌ Error
Heap Size Warning Threshold % and Error Threshold % for the minimum free heap, and Duration (seconds) ⚠️ Warning or ❌ Error
Connection None 🚫 Unavailable when the JVM can't be reached through the JMX Gateway

Resources are grouped by Application and then by Category, so you can build Monitor Views per team or environment.

Note

The JMX Monitoring Agent monitors CPU and Heap Size only. It doesn't detect thread deadlocks, count threads, collect garbage collection or class loading statistics, read operating system metrics, or read other MBean attributes. See Thread Deadlock Detection, Supported Garbage Collectors, and OS vs JVM Monitoring for how to cover those areas.

graph LR Poll["fa:fa-clock Poll JVM through the JMX Gateway"] --> Reach{"JVM reachable?"} Reach -->|"No"| Unavailable["fa:fa-ban Unavailable"] Reach -->|"Yes"| Eval["fa:fa-gauge Evaluate CPU and free heap"] Eval -->|"Within thresholds"| OK["fa:fa-circle-check OK"] Eval -->|"Warning threshold passed for Duration"| Warning["fa:fa-triangle-exclamation Warning"] Eval -->|"Error threshold passed for Duration"| Error["fa:fa-circle-xmark Error"] style Poll fill:#2678BD style Eval fill:#2678BD style OK fill:#93d16d style Warning fill:#FFD525 style Error fill:#c33d34 style Unavailable fill:#c33d34

Diagram: How the JMX Monitoring Agent sets the state of a JVM Resource: green OK within thresholds, yellow Warning, red Error when a threshold has been passed for the Duration, and red Unavailable when the JVM can't be reached.

Architecture

The Nodinite JMX Monitoring solution consists of three components:

  1. JMX Monitoring Agent - IIS-hosted agent that polls the JMX Gateway and reports CPU and heap values to Nodinite
  2. JMX Gateway - Spring Boot application (Windows Service) that connects to JVMs via JMX protocol
  3. Your JVM Applications - Boomi Atoms, WSO2 Enterprise Integrator and Micro Integrator, custom Java apps, or any JVM workload (local or remote)
graph LR subgraph "JMX Environment #1" roBoomiAtom1(fab:fa-java Java Virtual Machine) end subgraph "JMX Environment #2" roBoomiAtom2(fa:fa-atom Boomi Atom) end subgraph "Host with Agent" subgraph "Spring Boot" roGW(fa:fa-hard-drive JMX API Gateway
.jar package) end subgraph "IIS" roJMXAgent(JMX Monitoring Agent) ---|"8080"| roGW end roGW ---|"5002"| roBoomiAtom1 roGW ---|"5002"| roBoomiAtom2 end subgraph "Nodinite Instance" roMonitor[fa:fa-monitor-waveform Monitoring] ---|"80/443/..."| roJMXAgent end

Diagram: The Monitoring Service calls the JMX Monitoring Agent, the agent calls the Spring Boot JMX Gateway, and the gateway connects to each JVM over JMX.

When the JVM requires authentication, enable jmxremote.authenticate with a password file on the JVM and use the same credentials in the Spring Boot JMX Gateway configuration; see Enable JMX Remote Monitoring.

Troubleshooting and FAQ

The Troubleshooting guide answers common questions about thresholds, heap memory, Docker containers, multiple JVMs, and Java versions.

Next Steps

Prerequisites
Install JMX Monitoring Agent
Configuration

Monitor Views - Configure JVM monitoring dashboards
Alarm Plugins - Set up alerts for CPU and heap thresholds
Resources - Manage monitored JVM resources
Troubleshooting - JMX FAQ and troubleshooting topics
WSO2 Enterprise Integrator - Monitoring - Monitor WSO2 EI and Micro Integrator JVMs with this agent
Monitoring Agents Troubleshooting – Install, diagnostics, and multiple instances for any Monitoring Agent