JMX Automatic Monitoring Java Application Resolution well-known file is not Secure__java

JMX Automatic Monitoring Java application solution well-known file is not secure Preface

Recently in doing a monitoring agent component development work, the main is to collect a variety of system metrics information, and then reported to the monitoring system, in order to monitor and alarm. The goal is to achieve automation: Automatic discovery Services, dynamic detection services, monitoring automatic operation of the dimension, Plug-ins and so on.
In the Java application monitoring this piece, mainly is monitors the Java application the JMX information. In order to be able to automatically discover Java applications, automatic connection to JMX, has done a lot of attempts. This article is to share, one of the problems of the solution, the problem of the resolution of the ideas recorded. What is well-known file isn't secure

When we want to connect to the VM, such as Jmx,jmap,jstack, the VM checks/tmp/hsperfdata_$user/$PID Such a file, it checks whether the user executing the command, and hsperfdata_$ User this file belongs to the same users, if not consistent, it will appear well-known file is not secure this exception, and deny the connection how to connect Java applications through JMX and monitor

JMX connections are created by calling the Jmxconnectorfactory.connect () method through a connection string. In general, there are two ways to get a JMX connection string: The first is to manually specify a JMX Remote URL that is shaped like service:jmx:rmi:///jndi/rmi://host:ip/jmxrmi. The second way is to use the Virtualmachine.list () method to get all the JMX information locally, Then the com.sun.management.jmxremote.localConnectorAddress of the relevant PID is connected by attach.

The first method, when Java application is started, specifies that JMX Remote should be turned on, such as the following parameters can be added

-dcom.sun.management.jmxremote 
-dcom.sun.management.jmxremote.port=${jmxport} 
- Dcom.sun.management.jmxremote.ssl=false 
-dcom.sun.management.jmxremote.authenticate=false

The advantage of this approach is that there is no well-known file is not secure, but this requires that the connection information be manually configured, and the automatic connection described in the title is lost and automatically monitored.

The second method is able to automatically detect local applications, regardless of whether the application has the ability to open JMX remote, can be connected. But the downside is that there is a well-known file is not secure exception that occurs when the target Java application is different from the user started by this program. So it needs to be combined with two methods. how to combine both.

Don't talk much, straight to the point.

The combination of the two is to use the second method of local Java application scanning, regardless of whether the target application is the same user started, can be obtained, and also can get its PID. Then for each application, the second method is connected, and if the connection fails, there is a well-known file is not secure exception on behalf of the application. Then, according to the application of the PID, using Ps-aux | grep pid Way, get to the application of the startup command, and then parse the start command, Gets the port of the Com.sun.management.jmxremote.port parameter value in the Startup command and, based on that port, automatically constructs a JMX Remote URL connection using the local IP address 127.0.0.1.

Of course, if you set the parameter-dcom.sun.management.jmxremote.authenticate=true when the application is started, the JMX is authorized to authenticate and requires a login name and password to connect. My solution is to parse the/etc/profile file, get the Java_home address, and then parse java_home/jre/lib/management/jmxremote.access and java_home/jre/lib/ Management/jmxremote.password the contents of the file to obtain the user name and password.

However, because Java has strict user rights control over these two files: it must be the user running the program to read or write, or the Java application will refuse to start. So even if the root user starts, the two files cannot be accessed as long as they are not the same user.
There is always a solution to everything. My solution is to copy the corresponding configuration file to a temporary file, and authorize 777 (because it is monitoring, so this program is basically run as root), and then get the temporary file content, resolve to obtain the user name and password, parsing finished and then delete the temporary files. This allows you to obtain an authorized user and password for a JMX remote connection.

Finally, if the target application does not have the ability to turn on JMX Remote Connect and the user that started it, you should not be able to connect using JMX unless you are using the same user and then start a process to connect. Normally, however, companies should be able to turn on the JMX remote functionality of Java applications.

But there's another problem.
What if Java is running on the Docker container. How to monitor the application of Docker containers and containers at the same time. Have time to share this solution.