We are looking for a mechanism to fetch jmx data from remote jvm(s). The restriction is that port 22 is only accessible on those vm(s).
We were planning to use a thin client on those vm(s) which can connect to MBeanServer locally and query the object. These local client could be invoked (remotely) via ssh java command and the results can be transferred. This client can be developed, but we are trying to avoid this as we have to install it in several VM(s) and were looking for any out of the box client available in jre8, which can be invoked directly.
We have explored various options on internet, such as jconsole, jmxrmi connector, jmxterm etc., but these does not fit as
- jconsole - requires jdk and there is no headless mechanism to query jmx data via cli.
- jmxrmi connector - requires a client to be built and deployed in several vms
- jmxterm or any tool - requires deployment in several vms.
So posting the question here to get some insight. We are using jre from openjdk version "1.8.0_275"
I'm not quite sure what you need because your question seems to read to me like you are looking to do conflicting things there. But let me describe what I would be looking at and see if it can align.
I am inferring that you have multiple remote VMs each of which can potentially be running more that one JMX-instrumented JVM. Right here you have an issue, since JMX presents itself to the external world via TCP/IP and only one application in a given OS instance may own a given port. That's a TCP/IP rule and not related to Java. So JVM 1 might serve on port 5000, JVM 2 might serv on port 5001. JVM 3 on port 5003 and so forth. The exact port number to use is a JVM command-line option set on the JVM start-up command line.
If you only had one JVM to monitor per VM, you could have your remote JMX monitor connect via TCP/IP port 22 by setting the JVM parameter "-Dcom.sun.management.jmxremote.port=22". But note that since the one-application-per-port rule applies to the SSH server as well, you would then have to shut down normal SSH services for that machine. You probably don't want to do that.
So the next best option is to install something that can serve as a master agent for all the JMX servers on that machine. Probably the easiest architecture for this on an SSL channel is actually to be a web services service on the remote-facing end and use JMX remote connectors from it to the JMX agent JVMs.
I don't know of any ready-made systems of this type, but then I never looked. If you wanted to create your own server you could base it on Spring Boot or an OSGi server like Apache ServiceMix. I'd prefer ServiceMix myself, since it's more flexible, but Spring Boot is so popular that it's easy to find people who know it.
Of necessity, all VMs wishing to participate this way would have to have locally-installed master agents, and this is where I got confused since you seemed to both want and not want this. You've really got no options, though, unless you want the client VMs to have separate JMX ports open on the firewall for each JVM being monitored. If that seems to be a maintenance problem, you should probably look at Ansible, which can provision systems singly and in bulk using SSH as its sole network input and requires no client-side software of its own.
Some people, when well-known sources tell them that fire will burn them, don't put their hands in the fire.
Some people, being skeptical, will put their hands in the fire, get burned, and learn not to put their hands in the fire.
And some people, believing that they know better than well-known sources, will claim it's a lie, put their hands in the fire, and continue to scream it's a lie even as their hands burn down to charred stumps.
They weren't very bright, but they were very, very big. Ad contrast:
SKIP - a book about connecting industrious people with elderly land owners