jdk.jcmd is not a required module for the custom runtime. However, it is required for the proper functioning of Object Instance Tracking. See Object Instance Tracking for Java.
assumes that all packages from Java.se are installed.
Related pages: |
To begin monitoring a Java application, install the Java Agent into the application JVM:
Consider the following as you decide where and how to deploy the Java Agent:
For cURL installation, see Download Splunk AppDynamics Software.
The Java Agent is one type of bytecode injection (BCI) agent. To prevent unforeseen issues with other BCI agents, only supports environments running the Java Agent as the sole BCI agent on the JVM. You can run multiple BCI Agents on the JVM at your own risk. For Java Agent <= 4.5.16, you can decrease the chances of conflict with other agents by specifying the following command-line option:
Java Agent >= 4.5.17 automatically enables this option if they detect the presence of other agents. |
You can use the Java Agent to instrument an application running on a custom Java runtime image constructed with J-link. To instrument the agent, the custom runtime requires these modules:
jdk.managementjava.logging
jdk.unsupported
|
The Java Agent typically adds between 0% to 2% additional CPU consumption.
However, certain factors can increase CPU overhead from the agent beyond 2%. These include the use of resource-intensive features, such as asynchronous transaction tracking. Very active environments or configuration settings that result in a high number of metrics or snapshots reported per minute can also affect agent resource consumption.
In all cases, recommends that you test the agent in a staging environment, and monitor resource consumption of your application to ensure that it remains within proper operating parameters.
If your application operates within a small margin of its existing memory resource allocation, you may choose to increase the allocation for the application. recommends allocating the following amounts of additional Heap and PermGen space to accommodate the agent:
-Xmx): 100 MB in addition to the amount required by the application-XX:MaxPermSize): 20 MB in addition to the amount required by the application. The setting for MaxPermSize is applicable only for Java 6 or Java 7.You can get the agent from the Agent Download Wizard. If you have never installed an agent before, the wizard is a good place to start. The wizard populates the configuration file in the agent you download with Controller connection settings and identifying settings for the agent. After you download the agent, you can install it in the JVM.
Alternatively, you can download the agent manually, as follows:
\usr\local\appdynamics\appagent.conf and logs directories in the Java Agent home. One way to achieve this is to install the agent as the same user that owns the JVM or as an administrator on the host machine. For information on the contents of the Java Agent home directory, see Java Agent Directory Structure.
If you downloaded the agent from the Agent Download Wizard in the Controller, you can skip to the next section, as the agent is already configured.
To configure the settings manually (or verify the wizard settings):
<agent_home>/<version_number>/conf/controller-info.xml controller-host: Set to the IP address or hostname of the Controller. If the agent needs to connect through a proxy, see "Proxy Properties for the Controller" in Java Agent Configuration Properties.controller-port: Set to the primary listening port number on the Controller. By default: For a SaaS Controller, use 80 for HTTP or 443 for HTTPS
For an on-premises Controller, use 8090 for HTTP or 8181 for HTTPS
controller-ssl-enabled value to true. See Enable SSL for the Java Agent.application-name tier-name node-name In a self-service Trial edition of Pro, the agent uses a default naming scheme, see Java Agent. You can use automatic naming with a standard edition of
Pro by adding this property:
<auto-naming>true</auto-naming>
account-name account-access-key<controller_home>/initial_account_access_info.txtThe following shows a controller-info.xml file with sample configuration values:
<controller-info>
<controller-host>192.168.1.20</controller-host>
<controller-port>8090</controller-port>
<application-name>ACMEOnline</application-name>
<tier-name>InventoryTier</tier-name>
<node-name>Inventory1</node-name>
</controller-info> |
After configuring the agent settings, you can add the agent to the JVM. The exact steps for doing so vary by framework. The general approach involves specifying the agent as a ‑javaagent argument to the startup command for the JVM.
Ensure to add the -javaagent argument before the -jar argument.
The argument should indicate the location of the Java Agent JAR file:
-javaagent:<agent_home>/javaagent.jar |
On Windows, include the drive letter in the path to the agent:
-javaagent:C:<agent_home>\javaagent.jar |
In some scenarios, you need to use double backslashes instead of single backslashes. For example:
|
Adding javaagent to the startup script requires a restart of the JVM. If it's not possible to restart the JVM when you are installing the agent and modifying the JVM start up script, you can attach the agent dynamically to the running Java process.
See Agent Installation by Java Framework for more information on how to install Java Agent by Java framework or technology.
Attaching the agent to a running JVM allows you to install the Java Agent without requiring a JVM restart. This approach would normally be used alongside adding the ‑javaagent argument to the JVM startup script, or some other persistent approach to ensure that the agent is loaded again at the next JVM restart. However, the dynamic attachment allows you to install the agent when restarting the JVM is not possible or convenient.
In some scenarios, you need to use double backslashes instead of single backslashes. For example:
|
Dynamic agent attachment works if:
Other considerations include:
To attach the agent to the JVM:
Determine the PID of the JVM to which you want to attach.
For Linux, use:
ps -A | grep java |
On Windows, use:
jps -l |
Run the following command, replacing the placeholders for the path to the tools.jar file in your JDK, path to the Java Agent home directory, and the JVM process ID with values appropriate for your environment:
java -Xbootclasspath/a:<path_to_jdk>/lib/tools.jar -jar /<agent_home>/javaagent.jar <jvm_process_id> appdynamics.controller.hostName=<controller_hostname>,appdynamics.controller.port=<controller_port_no>,appdynamics.controller.ssl.enabled=false,appdynamics.agent.applicationName=<app_name>,appdynamics.agent.tierName=<agent_tier_name>,appdynamics.agent.nodeName=<agent_node_name> |
Use the equivalent paths for Windows, including drive letter. The following shows an example with system output included:
[appduser@my_centos6 ~]$ ps -A | grep java 6780 pts/1 00:00:04 java [appduser@my_centos6 ~]$ java -Xbootclasspath/a:/usr/java/jdk1.7.0_79/lib/tools.jar -jar /home/appduser/appagent/javaagent.jar 6780 Attaching to VM [6780] agent path >>>/home/appduser/appagent/javaagent.jar= |
After an installation, the agent log in <agent_home>/logs will contain this message:
Started AppDynamics Java Agent Successfully |
If the agent log file is not present, the Java Agent may not be accessing the javaagent command properties. To troubleshoot, check the application server log file where STDOUT is logged. It will have the fallback log messages, useful for troubleshooting the agent.
Also, verify that the agent is able to connect to the Controller in the Controller UI. To verify, log in to the Controller UI and click the Settings icon at the top right of the page, and then Agent Management > Manage Agents. In the list, search for the agent by machine hostname.