How to know jmx port?

The Java virtual machine (Java VM) has built-in instrumentation that enables you to monitor and manage it using the Java Management Extensions (JMX) technology. These built-in management utilities are often referred to as out-of-the-box management tools for the Java VM. You can also monitor any appropriately instrumented applications using the JMX API.

To enable and configure the out-of-the-box JMX agent so that it can monitor and manage the Java VM, you must set certain system properties when you start the Java VM. You set a system property on the command-line as follows.

You can set any number of system properties in this way. If you do not specify a value for a management property, then the property is set with its default value. The full set of out-of-the-box management properties is described in Table 2-1 at the end of this chapter. You can also set system properties in a configuration file, as described in Out-of-the-Box Monitoring and Management Properties.

Note - To run the Java VM from the command line, you must add JRE_HOME/bin to your path, where JRE_HOME is the directory containing the Java Runtime Environment (JRE) implementation. Alternatively, you can enter the full path when you type the command.

The following documents describe the syntax and the full set of command-line options supported by the Java HotSpot VMs.

To monitor a Java platform using the JMX API, you must do the following.

These steps are described in the next sections.

Under previous releases of the Java SE platform, to allow the JMX client access to a local Java VM, you had to set the following system property when you started the Java VM or Java application.

Setting this property registered the Java VM platform's MBeans and published the Remote Method Invocation (RMI) connector via a private interface to allow JMX client applications to monitor a local Java platform, that is, a Java VM running on the same machine as the JMX client.

In the Java SE 6 platform, it is no longer necessary to set this system property. Any application that is started on the Java SE 6 platform will support the Attach API, and so will automatically be made available for local monitoring and management when needed.

For example, previously, to enable the JMX agent for the Java SE sample application Notepad, you would have to run the following commands.

In the above command, JDK_HOME is the directory in which the Java Development Kit (JDK) is installed. In the Java SE 6 platform, you would simply have to run the following command to start Notepad.

Once Notepad has been started, a JMX client using the Attach API can then enable the out-of-the-box management agent to monitor and manage the Notepad application.

Note - On Windows platforms, for security reasons, local monitoring and management is only supported if your default temporary directory is on a file system that allows the setting of permissions on files and directories (for example, on a New Technology File System (NTFS) file system). It is not supported on a File Allocation Table (FAT) file system, which provides insufficient access controls.

Local monitoring with JConsole is useful for development and creating prototypes. Using JConsole locally is not recommended for production environments, because JConsole itself consumes significant system resources. Rather, you should use JConsole on a remote system to isolate it from the platform being monitored.

However, if you do wish to perform local monitoring using JConsole, you start the tool by typing jconsole in a command shell. When you start jconsole without any arguments, it will automatically detect all local Java applications, and display a dialog box that enables you to select the application you want to monitor. Both JConsole and the application must by executed by the same user, since the monitoring and management system uses the operating system's file permissions.

Note - To run JConsole from the command line, you must add JDK_HOME/bin to your path. Alternatively, you can enter the full path when you type the command.

For more information, see Chapter 3, Using JConsole.

To enable monitoring and management from remote systems, you must set the following system property when you start the Java VM.

In the property above, portNum is the port number through which you want to enable JMX RMI connections. Be sure to specify an unused port number. In addition to publishing an RMI connector for local access, setting this property publishes an additional RMI connector in a private read-only registry at the specified port using a well known name, "jmxrmi".

Note - You must set the above system property in addition to any properties you might set for security.

Remote monitoring and management requires security to ensure that unauthorized persons cannot control or monitor your application. Password authentication over the Secure Sockets Layer (SSL) and Transport Layer Security (TLS) is enabled by default. You can disable password authentication and SSL separately, as described in the next sections.

Note - For production systems, use both SSL client certificates to authenticate the client host and password authentication for user management. See the topics Using SSL and Using LDAP Authentication for more information.

The Java platform supports pluggable login modules for authentication. You can plug in any login module depending on the authentication infrastructure in your organization. The section titled Using LDAP Authentication describes how to plug in the com.sun.security.auth.module.LdapLoginModule for Lightweight Directory Access Protocol (LDAP) based authentication.

After you have enabled the JMX agent for remote use, you can monitor your application using JConsole, as described in Remote Monitoring with JConsole. How to connect to the management agent programmatically is described in Connecting to the JMX Agent Programmatically.

The JMXAuthenticator implementation in the JMX agent is based on Java Authentication and Authorization Service (JAAS) technology. Authentication is performed by passing the user credentials to a JAAS javax.security.auth.spi.LoginModule object. The com.sun.security.auth.module.LdapLoginModule class enables authentication using LDAP. You can replace the default LoginModule class with the LdapLoginModule as described next.

Create a JAAS configuration file that would work in the required business organization. An example of a configuration file (ldap.config) is shown next:

The options in the configuration file are briefly explained next. See documentation for the com.sun.security.auth.module.LdapLoginModule class for information about the configuration options shown in the code snippet.

Start your application with the following properties set on the command line:

A sample command line is shown next.

The file-based password authentication mechanism supported by the JMX agent stores the password in clear-text and is intended only for development use. For production use, it is strongly recommended that you use SSL client certificates for authentication or plug in a secure login configuration.

Caution - A potential security issue has been identified with password authentication for remote connectors when the client obtains the remote connector from an insecure RMI registry (the default). If an attacker starts a bogus RMI registry on the target server before the legitimate registry is started, then the attacker can steal clients' passwords. This scenario includes the case where you launch a Java VM with remote management enabled, using the system property com.sun.management.jmxremote.port=portNum, even when SSL is enabled. Although such attacks are likely to be noticed, it is nevertheless a vulnerability.

By default, when you enable the JMX agent for remote monitoring, it uses password authentication. However, the way you set it up depends on whether you are in a single-user environment or a multiple-user environment.

Since passwords are stored in clear-text in the password file, it is not advisable to use your regular user name and password for monitoring. Instead, use the user names specified in the password file such as monitorRole and controlRole. For more information, see Using Password and Access Files.

You set up the password file in the JRE_HOME/lib/management directory as follows.

You set up the password file in the JRE_HOME/lib/management directory as follows.

Password authentication for remote monitoring is enabled by default. To disable it, set the following system property when you start the Java VM.

Caution - This configuration is insecure. Any remote user who knows (or guesses) your JMX port number and host name will be able to monitor and control your Java application and platform. While it may be acceptable for development, it is not recommended for production systems.

When you disable password authentication, you can also disable SSL, as described in Disabling Security. You may also want to disable passwords, but use SSL client authentication, as described in Enabling SSL Client Authentication.

SSL is enabled by default when you enable remote monitoring and management. To use SSL, you need to set up a digital certificate on the system where the JMX agent (the MBean server) is running and then configure SSL properly. You use the command-line utility keytool to work with certificates. The general procedure is as follows.

When setting up connections for monitoring remote applications, you can optionally bind the RMI connector stub to an RMI registry that is protected by SSL. This allows clients with the appropriate SSL certificates to get the connector stub that is registered in the RMI registry. To protect the RMI registry using SSL, you must set the following system property.

When this property is set to true, an RMI registry protected by SSL will be created and configured by the out-of-the-box management agent when the Java VM is started. The default value of this property is false. However, it is recommended that you set this property to true. If this property is set to true, then to have full security, you must also enable SSL client authentication, as described in the next section.

To enable SSL client authentication, set the following system property when you start the Java VM.

SSL must be enabled (default is set to false), to use client SSL authentication. It is recommended that you set this property to true. This configuration requires that the client system have a valid digital certificate. You must install a certificate and configure SSL on the client system, as described in Using SSL. As stated in the previous section, if RMI registry SSL protection is enabled, then client SSL authentication must be set to true.

To disable SSL when monitoring remotely, you must set the following system property when you start the Java VM.

Password authentication will still be required unless you disable it, as specified in Disabling Password Authentication.

To disable both password authentication and SSL (namely to disable all security), you should set the following system properties when you start the Java VM.

Caution - This configuration is insecure: any remote user who knows (or guesses) your port number and host name will be able to monitor and control your Java applications and platform. Furthermore, possible harm is not limited to the operations you define in your MBeans. A remote client could create a javax.management.loading.MLet MBean and use it to create new MBeans from arbitrary URLs, at least if there is no security manager. In other words, a rogue remote client could make your Java application execute arbitrary code.

Consequently, while disabling security might be acceptable for development, it is strongly recommended that you do not disable security for production systems.

You can remotely monitor an application using JConsole, with or without security enabled.

To monitor a remote application with SSL disabled, you would start JConsole with the following command.

You can also omit the host name and port number, and enter them in the dialog box that JConsole provides.

To monitor a remote application with SSL enabled, you need to set up the truststore on the system where JConsole is running and configure SSL properly. For example, you can create a keystore as described in the JSSE Guide and start your application (called Server in this example) with the following commands.

If you created the keystore and started Server as shown above, then you would have to start JConsole as follows.

The above configuration authenticates the server only. If SSL client authentication is set up, you will need to provide a similar keystore for JConsole's keys, and an appropriate truststore for the application.

See Customizing the Default Key and Trust Stores, Store Types, and Store Passwords in the JSSE Guide for information.

For more information on using JConsole, see Chapter 3, Using JConsole.

The password and access files control security for remote monitoring and management. These files are located by default in JRE_HOME/lib/management and are in the standard Java properties file format. For more information on the format, see the API reference for the java.util.Properties package.

The password file defines the different roles and their passwords. The access control file (jmxremote.access by default) defines the permitted access for each role. To be functional, a role must have an entry in both the password and the access files.

The JRE implementation contains a password file template named jmxremote.password.template. Copy this file to JRE_HOME/lib/management/jmxremote.password or to your home directory, and add the passwords for the roles defined in the access file.

You must ensure that only the owner has read and write permissions on this file, since it contains the passwords in clear text. For security reasons, the system checks that the file is only readable by the owner and exits with an error if it is not. Thus in a multiple-user environment, you should store the password file in private location such as your home directory.

Property names are roles, and the associated value is the role's password. For example, the following are sample entries in the password file.

On Solaris, Linux, or Mac OS X operating systems, you can set the file permissions for the password file by running the following command.

For instructions on how to set file permissions on Windows platforms, see Appendix A, Additional Security Information For Microsoft Windows.

By default, the access file is named jmxremote.access. Property names are identities from the same space as the password file. The associated value must be either readonly or readwrite.

The access file defines roles and their access levels. By default, the access file defines the two following primary roles.

An access control entry consists of a role name and an associated access level. The role name cannot contain spaces or tabs and must correspond to an entry in the password file. The access level can be either one of the following.

A role should have only one entry in the access file. If a role has no entry, it has no access. If a role has multiple entries, then the last entry takes precedence. Typical predefined roles in the access file resemble the following.

You can set out-of-the-box monitoring and management properties in a configuration file or on the command line. Properties specified on the command line override properties in a configuration file. The default location for the configuration file is JRE_HOME/lib/management/management.properties. The Java VM reads this file if either of the command-line properties com.sun.management.jmxremote or com.sun.management.jmxremote.port are set. Management via the Simple Network Management Protocol (SNMP) uses the same configuration file. For more information about SNMP monitoring, see Chapter 5, SNMP Monitoring and Management.

You can specify a different location for the configuration file with the following command-line option.

In the property above, ConfigFilePath is the path to the configuration file.

Table 2-1 describes all the out-of-the-box monitoring and management properties.

If any errors occur during start up of the MBean server, the RMI registry, or the connector, the Java VM will throw an exception and exit. Configuration errors include the following.

If your application runs a security manager, then additional permissions are required in the security permissions file.

Once you have enabled the JMX agent, a client can use the following URL to access the monitoring service.

A client can create a connector for the agent by instantiating a javax.management.remote.JMXServiceURL object using the URL, and then creating a connection using the JMXConnectorFactory.connect method, shown in Example 2-3.

As stated previously, in the Java SE platform version 6, you can create a JMX client that uses the Attach API to enable out-of-the-box monitoring and management of any applications that are started on the Java SE 6 platform, without having to configure the applications for monitoring when you launch them. The Attach API provides a way for tools to attach to and start agents in the target application. Once an agent is running, JMX clients (and other tools) are able to obtain the JMX connector address for that agent via a property list that is maintained by the Java VM on behalf of the agents. The properties in the list are accessible from tools that use the Attach API. So, if an agent is started in an application, and if the agent creates a property to represent a piece of configuration information, then that configuration information is available to tools that attach to the application.

The JMX agent creates a property with the address of the local JMX connector server. This allows JMX tools to attach to and get the connector address of an agent, if it is running.

Example 2-4 shows code that could be used in a JMX tool to attach to a target VM, get the connector address of the JMX agent and connect to it.

Example 2-4 uses the com.sun.tools.attach.VirtualMachine class's attach() method to attach to a given Java VM so that it can read the properties that the target Java VM maintains on behalf of any agents running in it. If an agent is already running, then the VirtualMachine class's getAgentProperties() method is called to obtain the agent's address. The getAgentProperties() method returns a string property for the local connector address com.sun.management.jmxremote.localConnectorAddress, that you can use to connect to the local JMX agent.

If no agent is running already, then one is loaded by the VirtualMachine from JRE_HOME/lib/management-agent.jar, and its connector address is obtained by getAgentProperties().

A connection to the agent is then established by calling JMXConnectorFactory.connect on a JMX service URL that has been constructed from this connector address.

As explained above, remote access to the out-of-the-box management agent is protected by authentication and authorization, and by SSL encryption, and all configuration is performed by setting system properties or by defining a management.properties file. In most cases, using the out-of-the-box management agent and configuring it through the management.properties file is more than sufficient to provide secure management of remote Java VMs. However, in some cases greater levels of security are required and in other cases certain system configurations do not allow the use of a management.properties file. Such cases might involve exporting the RMI server's remote objects over a certain port to allow passage through a firewall, or exporting the RMI server's remote objects using a specific network interface in multi-homed systems. For such cases, the behavior of the out-of-the-box management agent can be mimicked by using the JMX Remote API directly to create, configure and deploy the management agent programmatically.

This section provides an example of how to implement a JMX agent that identically mimics an out-of-the-box management agent. In exactly the same way as the out-of-the-box management agent, the agent created in Example 2-5 will run on port 3000, will have a password file named password.properties, an access file named access.properties and it will implement the default configuration for SSL/TLS-based RMI Socket Factories, requiring server authentication only. This example assumes a keystore has already been created, as described in Using SSL. Information about how to set up the SSL configuration can be found in the JSSE Reference Guide.

To enable monitoring and management on an application named com.example.MyApp using the out-of-the-box JMX agent with the configuration described above, you would run com.example.MyApp with the following command.

Note - The com.sun.management.jmxremote.* properties could have been specified in a management.properties file instead of passing them at the command line. In that case, the system property -Dcom.sun.management.config.file=management.properties would be required to specify the location of the management.properties file.

Example 2-5 shows the code you would need to write to create programmatically a JMX agent that will allow exactly the same monitoring and management on com.example.MyApp as would be possible using the command above.

Start this application with the following command.

The com.example.MyApp application will enable the JMX agent and will be able to be monitored and managed in exactly the same way as if the Java platform's out-of-the-box management agent had been used. However, there is one slight but important difference between the RMI registry used by the out-of-the-box management agent and the one used by a management agent that mimics it. The RMI registry used by the out-of-the-box management agent is read-only, namely a single entry can be bound to it and once bound this entry cannot be unbound. This is not true of the RMI registry created in Example 2-5.

Furthermore, both RMI registries are insecure as they do not use SSL/TLS. The RMI registries should be created using SSL/TLS-based RMI socket factories which require client authentication. This will prevent a client from sending its credentials to a rogue RMI server and will also prevent the RMI registry from giving access to the RMI server stub to a non-trusted client.

RMI registries which implement SSL/TLS RMI socket factories can be created by adding the following properties to your management.properties file.

Example 2-5 mimics the main behavior of the out-of-the-box JMX agent, but does not replicate all the existing properties in the management.properties file. However, you could add other properties by modifying com.example.MyApp appropriately.

As stated above, the code in Example 2-5 can be used to monitor applications through a firewall, which might not be possible if you use the out-of-the-box monitoring solution. The com.sun.management.jmxremote.port management property specifies the port where the RMI Registry can be reached but the ports where the RMIServer and RMIConnection remote objects are exported is chosen by the RMI stack. To export the remote objects (RMIServer and RMIConnection) to a given port you need to create your own RMI connector server programmatically, as described in Example 2-5. However, you must specify the JMXServiceURL as follows:

In the URL above, port1 is the port number on which the RMIServer and RMIConnection remote objects are exported and port2 is the port number of the RMI Registry.

The Java SE platform provides services that allow Java programming language agents to instrument programs running on the Java VM. Creating an instrumentation agent means you do not have to add any new code to your application in order to allow it to be monitored. Instead of implementing monitoring and management in your application's static main method you implement it in a separate agent class, and start your application with the -javaagent option specified. See the API reference documentation for the java.lang.instrument package for full details about how to create an agent class to instrument your applications.

The following procedure shows how you can adapt the code of com.example.MyApp to make an agent to instrument any other application for monitoring and management.

To start SpringSource dm Server with default JMX access enabled, run startup.sh passing in no arguments:

To start JConsole, run the jconsole.sh script, located in the bin directory, as shown:

The following image shows how to specify a local connection using JConsole.

The following image shows how to specify a remote connection in JConsole that uses SSL with the default username/password (admin/springsource and default secure port of 9875).

To start with the JMX remote access on a specific port number other than the default 9875, pass this port number in as the value of the -jmxport argument:

This will start the SpringSource dm Server with JMX enabled for remote connections on port 9009.

To start the JMX remote access with a custom username and password edit the files located at $SERVER_HOME/config/management/jmxremote.password and $SERVER_HOME/config/management/jmxremote.access. Add the username, along with their permissions (either readonly or readwrite) to the jmxremote.access file. Then add a corresponding line to the jmxremote.password file that specifies the user's password. The specify the custom username in JConsole as shown.

To start the JMX remote access using a custom SSL certificate, edit the file located at $SERVER_HOME/config/management/keystore. If you wish to use a different keystore, pass this filename in as the value for the -keystore argument and the keystore password in as the value for the -keystorePassword argument:

To start SpringSource dm Server with default JMX access enabled, run startup.sh passing in no arguments:

To start JConsole, run the jconsole.sh script, located in the bin directory, as shown:

The following image shows how to specify a local connection using JConsole.

The following image shows how to specify a remote connection in JConsole that uses SSL with the default username/password (admin/springsource and default secure port of 9875).

To start with the JMX remote access on a specific port number other than the default 9875, pass this port number in as the value of the -jmxport argument:

This will start the SpringSource dm Server with JMX enabled for remote connections on port 9009.

To start the JMX remote access with a custom username and password edit the files located at $SERVER_HOME/config/management/jmxremote.password and $SERVER_HOME/config/management/jmxremote.access. Add the username, along with their permissions (either readonly or readwrite) to the jmxremote.access file. Then add a corresponding line to the jmxremote.password file that specifies the user's password. The specify the custom username in JConsole as shown.

To start the JMX remote access using a custom SSL certificate, edit the file located at $SERVER_HOME/config/management/keystore. If you wish to use a different keystore, pass this filename in as the value for the -keystore argument and the keystore password in as the value for the -keystorePassword argument:

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.

First, the java web application can be accessed via a web browser (typically on port 8080) but the detailed performance info is accessed on a different port called remote JMX. Java applications do not have this remote JMX port enabled by default.  You have to manually enable it. The "how" part can vary based on tomcat or websphere and can even change based on the version you're running of each. This is where the initial confusion can begin. Since I can't outline every way to configure it, i'll outline the basic concept and let you use some google fu to fill in the blanks.

We need to find the JAVA_OPTS startup setting. It is normally defined in whatever startup script java uses.

When you find it, you need to add the following 4 options. For linux, they need to be all on the same line with a space separating them. For Windows, multi-line usually works.

-Dcom.sun.management.jmxremote

-Dcom.sun.management.jmxremote.port=8686

-Dcom.sun.management.jmxremote.authenticate=false

-Dcom.sun.management.jmxremote.ssl=false

First, we need to enable the remote JMX on a global level. In the WebSphere administration, there is a setting called "Platform MBean Server" that needs to be enabled. It's location and exact name varies based on your version of WebSphere but it is typically found in the Admin WebUI: Domain > Configuration > General > Advanced > Platform MBean Server Enabled Checkbox.

Once that is enabled then we need to add the following to each webspehere instance we want to monitor. Find the JAVA_OPTS area of startup and add these lines.

-Dcom.sun.management.jmxremote

-Dcom.sun.management.jmxremote.port=8686

-Dcom.sun.management.jmxremote.authenticate=false

-Dcom.sun.management.jmxremote.ssl=false

-Djava.rmi.server.hostname=

*The last setting, replace with the IP of your webspehere server.

The jmxremote.port= can be any port you want that isn't already in use. The templates in SAM default to using port 8686.

*If you have multiple java apps running on the same server like I do, then come up with a standard port convention to make it easier.

*My java apps ran on ports 8040, 8050, 8060, 8070 and 8080. That means that I would have to add those JAVA_OPTS to EACH of those instances that I want to monitor. So each corresponding JMX port was 2040, 2050, 2060, 2070 and 2080.

The jmxremote.authenticate=false and jmxremote.ssl=false are set to false only in this example and for testing purposes. There are a lot more variables that could break and troubleshooting it is a pain.  Setting those to true is recommended but involve a lot of extra config which would really fall outside of the scope of this article.

Once those settings above are in place it will require a service restart to take effect. If you have a dev server, great! If not, schedule a maintenance window.

First, we need to see if the operating system is using the port. Run the following commands via SSH or on Windows Command Prompt/PowerShell.

Linux: netstat -nlp | grep 8686

Windows: netstat -ano | findstr "8686"

If nothing returns then something isn't setup correctly with the java opts, this is where google will be your friend.

Second, we want to test with Java JDK. Download and install it on your SolarWinds Orion server. The download link is here: Java SE Development Kit 8 - Downloads

Once installed, browser to the installation directory: C:\Program Files\Java\\bin. Open the jconsole.exe app inside.

Choose Remote Process and enter the IP:Port and click connect.

Since we originally set the jmxremote.ssl=false we'll get this message, just continue anyways by clicking Insecure connection.

If all of your hard work has paid off you should be presented with this screen.

The MBeans tab is where all of the details of the application are located and it's what SAM is polling metrics from. We'll dive into this a little more in another article.

Finally! On to assigning the SAM java template. Continued on the follow link.

• On your Tomcat host, open the start menu and click on Tomcat Configuration (alternatively, edit the catalina.bat or catalina.sh)
• Click on the Java tab, then add the following Java Options. -Dcom.sun.management.jmxremote.
• Save the changes and restart Tomcat.