Prerequisites for the JMX Monitoring Agent
This page describes the prerequisites to successfully install and run the Nodinite JMX Monitoring Agent to Monitor JVM CPU and Memory.
Software Requirements
The Nodinite JMX Monitoring Agent is a hosted Windows Service using NSSM and is usually installed on the JVM application server.
| Product | Version/Edition |
|---|---|
| Windows Server with IIS | Windows 2025Windows 2022Windows 2019Windows 2016Windows 2012 R2 |
| ASP.NET Core Runtime v6 Hosting Bundle | .NET 6 |
| JVM | OpenJDK |
| NSSM | Download |
For obvious reasons, JMX Monitoring must be enabled in the JVM Application to monitor.
Below is an example configuration with parameters to enable JMX Monitoring using an unauthenticated connection not using SSL on a Java Application:
java -Dcom.sun.management.jmxremote.port=5002
-Dcom.sun.management.jmxremote.authenticate=false
-Dcom.sun.management.jmxremote.ssl=false
-jar $CONTOSO_HOME/lib/ContosoApp_v1337.jar server start
What Windows User Rights does the JMX Monitoring Agent require?
The JMX Monitoring Agent runs as a Windows Service (using NSSM) and the Spring Boot Gateway component runs as a separate Java process.
Service Account Requirements
- The service account must have
Log on as a servicerights - see How to set Logon as a Service right - Use a local named account or domain account (preferred)
- The account needs network access to communicate with the Spring Boot Gateway (typically localhost) and the Monitoring Service
Spring Boot Gateway Requirements
- The Gateway runs as a Java process and requires network access to target JVM applications via JMX ports
- Ensure the account running the Gateway has appropriate file system permissions for log files and configuration
Firewall
Where you install the Nodinite JMX Monitoring Agent and its Spring Boot Gateway in relation to the Nodinite Monitoring Service and your JVM applications determines your firewall configuration. The diagram shows every host involved, with the agent and the gateway on their own server; each arrow starts at the side that opens the connection.
Network diagram: the Monitoring Service calls the agent, the agent calls the Spring Boot Gateway (usually on the same server), and the gateway connects to each JVM over JMX.
Note
When the agent runs on the Core Services Server, you need no firewall rule between the Monitoring Service and the agent. When the gateway runs on the Agent Server (the typical installation), the agent → gateway hop is loopback (127.0.0.1) traffic.
Between the Monitoring Service and the JMX Monitoring Agent
The Monitoring Service opens every connection; the agent never calls it. The agent is an IIS web site or web application (Install); the port is the HTTP/HTTPS binding you give it in IIS.
| Direction | Source | Destination | Protocol | Port(s) | Purpose | Notes |
|---|---|---|---|---|---|---|
| Inbound | Core Services Server | Agent Server | TCP (HTTPS/HTTP) | Agent IIS site port | Poll the agent and send configuration | 80/443 or the custom binding of the agent's IIS site (e.g. 8443). Only when the agent is on a remote server |
Between the JMX Monitoring Agent and the Spring Boot Gateway
The agent calls the JMX API Gateway (a Spring Boot .jar that NSSM runs as a Windows Service) to retrieve monitoring data.
| Direction | Source | Destination | Protocol | Port(s) | Purpose | Notes |
|---|---|---|---|---|---|---|
| Outbound | Agent Server | Agent Server (Spring Boot Gateway) | TCP (HTTP) | 8080 | JMX API Gateway communication | Default Spring Boot port. Loopback when both run on the same server; open it only if you host the gateway on another server |
| Inbound | Agent Server (Spring Boot Gateway) | Agent Server | TCP | 8080 | Response traffic | Automatically allowed by stateful firewall inspection |
Tip
Custom Gateway Port: The Spring Boot Gateway port can be configured in the application properties. If you use a custom port (e.g., 9000), adjust the agent configuration and firewall rules accordingly.
Between the Spring Boot Gateway and the JVM applications
The gateway connects to each target JVM over JMX (RMI) on the Port set per JVM in the Configuration guide.
| Direction | Source | Destination | Protocol | Port(s) | Purpose | Notes |
|---|---|---|---|---|---|---|
| Outbound | Agent Server (Spring Boot Gateway) | Target (JVM application, Boomi Atom) | TCP | 5002 (default) | JMX connection to JVM | Port depends on -Dcom.sun.management.jmxremote.port; set -Dcom.sun.management.jmxremote.rmi.port to the same value so only one port is needed |
| Inbound | Target (JVM application, Boomi Atom) | Agent Server (Spring Boot Gateway) | TCP | 5002 (default) | Response traffic | Automatically allowed by stateful firewall inspection |
Tip
JMX Port Configuration: Common JMX ports include 5002, 9999, 7199 (Cassandra), 9010 (Kafka). Each JVM on the same host needs its own port (see Multi-JVM Monitoring); a JVM in a container needs the port published to the host (see Docker Container Monitoring).
Tip
JMX Authentication and SSL: For production environments, enable JMX authentication and SSL/TLS encryption. This may require additional certificate configuration and firewall rules for secure JMX communication.
Between the servers and DNS
| Direction | Source | Destination | Protocol | Port(s) | Purpose | Notes |
|---|---|---|---|---|---|---|
| Outbound | Agent Server | DNS Server | TCP/UDP | 53 | Name resolution | Resolve the JVM hosts, the gateway (if remote), and the Core Services Server. A local hosts file can replace DNS |
| Outbound | Core Services Server | DNS Server | TCP/UDP | 53 | Name resolution | Resolve the Agent Server |
Important
Stateful Firewalls: Most Windows Firewall implementations are stateful, so response traffic for established outbound connections is allowed automatically. The inbound response rules above are for reference and troubleshooting.
Frequently asked questions
Additional solutions to common problems and the FAQ for the Nodinite JMX Monitoring agent exist in the Troubleshooting user guide.
Next Steps
Installing the JMX Monitoring Agent
Add or manage a Monitoring Agent Configuration