Hello. I was installing and configuring the SonarQube server. Now I have a task to collect metrics. With metrics available through endpoints via HTTP everything is clear to me. But with JMX metrics somehow it does not work. My SonarQube server runs in Docker, right in front of it there is Nginx which acts as a reverse proxy. Nginx is also in a container, both containers are combined using Docker Network. I deployed JMX Exporter from Prometheus in a Docker container and combined it into the same Docker Network as the SonarQube server with Nginx. To make the container work with the exporter, I added a line to the config from the documentation on remote access to JMX Mbeans, but set the parameter -Dcom.sun.management.jmxremote.authenticate=false to test whether it works at all or not. The exporter itself works, its web interface is displayed, but it does not collect any metrics (I understood this from the parameter indicating an error). I do not understand what port should be specified in the end to listen to JMX Mbeans. In the config for the exporter I specified the hostPort - this is the name of the container with the sonarcube server, and the port was different (5555, 10443, 10444), but nothing works. The pattern was specified .*. I set up my entire configuration using ansible. Could you please describe in more detail the procedure that I need to take to gain access to all JMX Mbeans from a neighboring container with the exporter?
I used:
SonarQube server image: sonarqube:10.7.0-community
JMX expoorter image: bitnami/jmx-exporter:1.1.0
And some one of latest nginx image.
My string in SonarQube server config for JMX seems like:
sonar.web.javaAdditionalOpts=-Dcom.sun.management.jmxremote=true \
-Dcom.sun.management.jmxremote.ssl=false \
-Dcom.sun.management.jmxremote.authenticate=false \
-Dcom.sun.management.jmxremote.port=10443 \
-Dcom.sun.management.jmxremote.rmi.port=10444
Is there any easier way to access JMX Mbeans.
UPD.
I found solutions from ten years ago that simply say to add the parameter -Djava.rmi.server.hostname. Is this really true?
In general, I figured it out. the Djava.rmi.server.hostname parameter is not needed, it works fine without it in the docker network. My problem was mainly related to the fact that the JMX exporter image from Bitnami was launched with the default config and tried to connect to the localhost, I discovered this late, but I found it. the whole problem was that in one of the tasks in Ansible I wrote the name of the config file as the file name and added the " symbol, which was not closed (for example like this config.yml"), because of which my config file was mounted in the container not as a file, but as a directory. I will say right away that all the information specified in the documentation on this matter is really working (in extreme cases, you can google something and look in the documentation for Java). However, the documentation from the developer is incomplete and some things are silent. For example, in this page of documentation the Mbeans for the WEB part are indicated, although in their documentation it is said that there are two ports (for the WEB part and CE), but nothing is said about CE. Actually, the config for CE is identical to what is presented in the documentation, except that you need to write not WEB but CE, as in the example below.
sonar.ce.javaAdditionalOpts=-Dcom.sun.management.jmxremote=true \
-Dcom.sun.management.jmxremote.ssl=false \
-Dcom.sun.management.jmxremote.authenticate=false \
-Dcom.sun.management.jmxremote.port=port \
-Dcom.sun.management.jmxremote.rmi.port=port
Actually, the last question I have is whether I can use the same *.rmi.port for WEB and CE, because essentially this port is needed to manage the JVM.
Hello @dubstepenjoyer thanks a lot for your participation in the community.
I am glad to it does work now in your situation.
Regarding your questions i never tried jvm export from scratch within docker and i am not super familiar with it.
I’ll ask @alain.kermis to take over and help with the jvm technical details you have and @caroline.dupuis as it looks like we are lacking some documentation, nonetheless i dont know if we want to support this specific use case.
in the helm chart we do have prometheus exporter feature, but it does not run as a sidecar container but directly injected as a jar lib into sonarqube application, hence the configuration might be a bit different.