Remotely connecting through Kubernetes to a JMX agent in a Spring Boot 1.x application to monitor an application
What‘s JMX, Kubernetes, and Spring Boot?
The Java Management Extensions (JMX) technology is a Java standard and allows for a means of monitoring and managing resources–most notably the Java Virtual Machine (JVM).
A resource is instrumented with Managed Beans (MBeans) that are registered in a core-managed MBean server which can run on devices that have the Java programming language installed.
Kubernetes is an open-source container-based system that automates deployments, scaling, and general container management. In a use case relevant to this article, it can orchestrate Java applications that are deployed in Docker containers.
Spring Boot is a Java framework for running a Spring application to support stand-alone, production-grade applications. It includes features such as built-in annotations and embedded HTTP servers like Tomcat or Jetty.
What’s the problem?
As it turns out, connecting to a JMX agent locally through a JMX UI client is quite simple. Typically, the client is automatically aware of the application through its running .jar file and gives the user the option to connect to its JMX port, which in Spring and in many other cases is by default 1099.
However, once a Spring Boot application is deployed in Kubernetes, the connection somehow ceases to work, at least in my case when I tried doing so.
After searching for possible solutions online, it became clear that this issue was somewhat common, as evidenced by multiple threads on Stack Overflow. Unfortunately, none of the solutions provided seemed to directly work for me, and none of them seemed directly tailored to Kubernetes specifically.
A large part of the issue is that in a remote connection through a typical RMI connector, then a second random port is essentially chosen for a user’s application as an accessible JMX endpoint. It’s essentially impossible for someone to dynamically be able to guess this endpoint. This blog post by Mark Feeney goes so far as to say “(Don’t Use) RMI” — instead, he (among others) suggests using the JMX…