Add option to connect with the Attach API

[elecnix]

com.sun.tools.attach.VirtualMachine.attach allows one to load an agent into a target JVM to expose a JMX port, knowing the PID of the JVM.

There should be an option to provide a PID instead of host & port.

[brian-brazil]

The recommended way to use the jmx exporter is as a java agent, which avoids this.

[elecnix]

Thanks for the suggestion. The java agent is indeed easier and more lightweight to deploy. However, some applications already expose interesting metrics through MBeans, but may not be listening on a port. It is a bit invasive to require a restart of such applications only to have Prometheus scrape them, when they are already providing a mechanism to be scraped, through the Attach API.

[brian-brazil]

In such a scenario, how do you plan on handling the application restarting?

[elecnix]

If the application restarts for some reason, and jmx_exporter was connected through the Attach API, jmx_exporter would exit if it notices that the PID no longer exists. An external agent would re-launch it once the PID is known.

[brian-brazil]

That seems a bit on the complicated side to me, and you'd likely be better off accepting the one restart required for the java agent.

[elecnix]

Managing thousands of JVMs has to be slightly complicated ;-)

[brian-brazil]

Have you considered not using JMX ;)

[elecnix]

To elaborate, in a large system that consists of small services, some of them written a decade ago, and actively used by people, some are not designed to be restarted without causing some amount of disruption. Deploying a monitoring agent that spawns a jmx_exporter child to monitor these JVMs is a reasonable use-case.

It would be a small addition to the project that other people could find useful for other reasons (perhaps just to try it out on a running JVM prior to deciding to go for an agent).

[elecnix]

Instead of adding an external agent to restart jmx_exporter, I'm thinking of giving the path to a PID file to jmx_exporter, and watching changes to that file through the same mechanism as the configuration reload.

[brian-brazil]

I'm not sure this feature is worth the complexity it'd add, considering the objection to one of the supported ways we already have for this is that it causes a single application restart.

I'm already not a big fan of the webserver way of doing things.