On successfully provisioning the APM Java agent, you can deploy the APM Java
agent.
To deploy the APM Java agent on any Java application, you need to add the
-javaagent parameter to the JVM startup script. Depending on the
Java environment, an application server or a microservice, users may have shell or bat
startup scripts, or another way to execute the Java command line.
See below examples on how to deploy the APM Java agent on the following Java
applications:
Here's information on how to deploy the APM Java agent on the Oracle WebLogic
Server.
Set a variable to point to your application server destination directory. This is
the directory in which the APM Java agent is provisioned.
Set the
$DOMAIN_HOME variable to point to the Oracle WebLogic
Server Domain directory and confirm that the APM Java agent was provisioned in
the same destination directory before you perform the next step.
Application Server
Destination Directory Variable
Information
Oracle WebLogic Server
Set the $DOMAIN_HOME variable
to point to the Oracle WebLogic Server
Domain.
export DOMAIN_HOME=<Oracle WebLogic Server Domain>
Make a backup copy of the startWebLogic.sh
file:
cd $DOMAIN_HOME/bin
cp startWebLogic.sh startWebLogic.sh.orig
Use a text editor and edit the original
startWebLogic.sh script and add the -javaagent
option.
If you're deploying the APM Java agent on the Oracle WebLogic
Administration Server and Managed Servers, then add the following
-javaagent option to the set of
JAVA_OPTIONS, after the
setDomainEnv.sh
call:
If you're deploying the APM Java agent on Managed Servers only, then add the following -javaagent option to the set of JAVA_OPTIONS within an if statement after the setDomainEnv.sh call:
if [ "$SERVER_NAME" != "AdminServer" ] ; then
set JAVA_OPTIONS="${JAVA_OPTIONS} -javaagent:$DOMAIN_HOME/oracle-apm-agent/bootstrap/ApmAgent.jar"
fi
Stop and restart the Oracle WebLogic Server:
cd $DOMAIN_HOME/bin
./stopWebLogic.sh
cd ..
nohup ./startWebLogic.sh >& startup.log &
If you have Managed Servers, stop and restart them too:
Notice that the $DOMAIN_HOME version of startWebLogic.sh is used, even though you edited the $DOMAIN_HOME/bin version. Invoking the command from one level higher (from $DOMAIN_HOME) invokes the command from a lower level (from $DOMAIN_HOME/bin). However, the stopWebLogic.sh command will be called from the $DOMAIN_HOME/bin directory.
After the APM Java agent is successfully deployed, the Oracle APM
Agent: Initialized AgentInstance message is displayed in the server startup
log.
Apache Tomcat Server 🔗
Here's information on how to deploy the APM Java agent on the Apache Tomcat
Server.
Set a variable to point to your application server destination directory. This is
the directory in which the APM Java agent is provisioned.
Set the
$CATALINA_HOME variable to point to the Apache Tomcat
Server destination directory and confirm that the APM Java agent was provisioned
in the same destination directory before you perform the next step.
Application Server
Destination Directory Variable
Information
Apache Tomcat Server
Set the $CATALINA_HOME variable
to point to the Apache Tomcat Server destination directory.
If you're using a Bash
shell:
export CATALINA_HOME=<Apache Tomcat Server destination directory>
If you're using a C
shell:
setenv CATALINA_HOME "<Apache Tomcat Server destination directory>"
Make a backup copy of the catalina.sh
file.
$ cd $CATALINA_HOME/bin
$ cp catalina.sh catalina.sh.orig
Use a text editor and edit the original catalina.sh
file and add the following -javaagent option to
CATALINA_OPTS. Make the change outside of any
if statements or code blocks that may not be executed during
server startup. This will ensure that the -javaagent flag is always
added to the server startup
options.
Here's information on how to deploy the APM Java agent on the Jetty
Server.
Set a variable to point to your application server destination
directory. This is the directory in which the APM Java agent is provisioned.
Set the JETTY_HOME variable to point to the
Jetty Server destination directory (where the Jetty software was extracted)
and confirm that the APM Java agent was provisioned in the same
destination directory before you perform the next step.
After the APM Java agent is successfully deployed, the Oracle APM
Agent: Initialized AgentInstance message is displayed in the server startup
log.
Spring Boot 🔗
Here's information on how to deploy an APM Java agent on a Spring Boot
microservice running embedded Apache Tomcat.
It's assumed that you've completed the prerequisite tasks and provisioned
the APM Java agent. Also, you must ensure that you've added the following properties to
the Spring Boot application's application.properties file to enable
Apache Tomcat
Mbeans:
Alternatively, add the above properties: spring.jmx.enabled and
server.tomcat.mbeanregistry.enabled as system properties on the
command line.
To deploy the APM Java agent, add the following -javaagent
option to the startup script of your microservice. Note that <Destination
Directory> denotes the directory in which you provisioned the
agent.
After the APM Java agent is successfully deployed, the Oracle APM
Agent: Initialized AgentInstance message is displayed in the microservice
startup log.
JBoss Server 🔗
Here's information on how to deploy the APM Java agent on the JBoss Server.
The below instructions are applicable for JBoss EAP and Wildfly.
Set a variable to point to your application server destination
directory. This is the directory in which the APM Java agent is provisioned.
Set
the $JBOSS_HOME variable to point to the JBoss Server
destination directory and confirm that the APM Java agent was provisioned in the
same destination directory before you perform the next step.
Application Server
Destination Directory Variable
Information
JBoss Server
Set the $JBOSS_HOME variable to point to the
JBoss Server destination directory.
If you're using a Bash
shell:
export JBOSS_HOME=<JBoss Server destination directory>
If you're using a C shell:
setenv JBOSS_HOME "<JBoss Server destination directory>"
Make a backup copy of the standalone.conf
file:
cd $JBOSS_HOME/bin
cp standalone.conf standalone.conf.orig
Use a text editor and edit the original
standalone.conf file and add the following Java options to
JAVA_OPTS. Make the change outside of any if
statements or code blocks that may not be executed during server startup.
After the APM Java agent is successfully deployed, the Oracle APM
Agent: Initialized AgentInstance message is displayed in the server startup
log.
Docker and Kubernetes 🔗
Here's information on how to deploy an APM Java agent in a Docker container
and Oracle Container Engine for Kubernetes (OKE).
There are different options available to deploy the APM Java Agent in Docker and Kubernetes environments. Review the below and select the scenario that meets your business needs:
Note that <DESTINATION_DIRECTORY> denotes the location on your local machine where you provisioned the APM Java agent and <Docker_Image_Directory> denotes the directory in the Docker image to which you're copying the APM Java agent. The <Docker_Image_Directory> could also be the application server destination directory in Docker, for example, $DOMAIN_HOME, if you're working with Oracle WebLogic Server.
Add the following -javaagent option to the startup script of your application server:
Build a new Docker image with the built-in APM Java agent and the modified startup script, and push the image to the registry.
If you use Kubernetes to manage your Docker containers, then update your Kubernetes configuration to use the new Docker image, and restart the Kubernetes pod.
Also, you can set additional dimensions to be reported from the Kubernetes pod using the Downward API, by copying the following environment and volume settings in the deployment specification (yaml file) of the Kubernetes pod. For information on the Downward API, see The Downward API in Kubernetes documentation.
If the Kubernetes deployment does not have labels, annotations, or both, the Downward API for the same will cause an error when the application is deployed. In this case, you must remove the Downward API entry corresponding to metadata.labels, metadata.annotations, or both.
Deploy APM Java Agent using OpenTelemetry Operator 🔗
Here's information on how to deploy an APM Java agent using the OpenTelemetry operator to automatically inject and configure the APM Java agent into your Java application pods running on Kubernetes (K8s) clusters.
Figure 3-2 Deploy APM Java Agent using OpenTelemetry Operator
Recommendation:
Use this option if it's not possible to update the Docker container image and you prefer to make APM Java agent configuration changes using Kubernetes custom resource (CR) to automatically inject the APM agent into the JVMs at startup.
Docker and Kubernetes Considerations:
For the Docker image versioning, avoid using the tag :latest when deploying containers in production as it is harder to track which version of the image is running and more difficult to roll back properly. Instead, specify a meaningful tag such as v1.12.1.3.
For Kubernetes, take backups of the Kubernetes custom resources (CRs) and configmaps.
To manage automatic instrumentation, the OpenTelemetry Operator needs to be provided with information about the APM Java agent and its configuration which it's done using the Custom Resource Definition (CRD).
This Custom Resource will be used by the operator to copy the agent into the pod and add to it the required configuration.
<data-upload-endpoint> is the data upload endpoint URL that is generated when the APM domain is created. For information, see Obtain Data Upload Endpoint and Data Keys.
<private-data-key> is the APM Java agent installation private data key which is generated when the APM domain is created. For information, see Obtain Data Upload Endpoint and Data Keys.
The created CR can be queried by running the following command:
kubectl get otelinst -n opentelemetry-operator-system
All endpoints and environment variables required to be correct for auto-instrumentation to work properly.
Add the Kubernetes annotation.
The OpenTelemetry operator uses Kubernetes annotation to decide which pods should be auto-injected with the APM Java agent.
The annotation can be added to a namespace. In that case, all the pods within that namespace will get injected. The annotation can also be added to individual PodSpec objects, available as part of Deployment, Statefulset, and other resources.
Here's information on how to deploy an APM Java agent in Oracle Container Engine for Kubernetes (OKE) using a mounted volume.
Figure 3-3 Deploy APM Java Agent on a Mounted Volume
Recommendation:
Use this option when it's not possible to make changes to the Docker container image and you prefer to use a shared mounted volume when changes to the APM Java agent are needed.
Example 1: If you need to make frequent configuration changes to the APM agent then the container image requires to get updated, but it's not feasible to do it.
Example 2: If the user who is deploying the APM agent does not have the required access or permissions to rebuild a container image.
For the docker image versioning, back up the binary and config files.
To deploy the APM Java agent on a mounted volume, follow these steps:
Make a note of the data upload endpoint and data key when the APM Domain was created.
Create a new file system that will mount the pods.
When creating the file system, it's important to ensure to select the same Virtual Cloud Network (VCN) Compartment that Kubernetes is using. Do the same for the Subnet Compartment.
Mount the file system into the pods.
This step requires edits to the corresponding yaml files.
Create the PersistentVolume and related entities in Kubernetes, using the below yaml file. Note the following fields you need to edit for your environment: mntTargetId, server and path.
kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
name: oci-fss
provisioner: oracle.com/oci-fss
parameters:
mntTargetId: ocid1.mounttarget.oc1.iad.xxxxxxxxxxxxxxxxxxxxxx
---
apiVersion: v1
kind: PersistentVolume
metadata:
name: oke-fsspv
spec:
storageClassName: oci-fss
capacity:
storage: 10Gi
accessModes:
- ReadWriteMany
mountOptions:
- nosuid
nfs:
# Replace this with the IP of your FSS file system in OCI
server: 10.0.10.39
# Replace this with the Path of your FSS file system in OCI
path: "/fss-for-kub"
readOnly: false
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: oke-fsspvc
spec:
storageClassName: oci-fss
accessModes:
- ReadWriteMany
resources:
requests:
# Although storage is provided here it is not used for FSS file systems
storage: 10Gi
volumeName: oke-fsspv
To apply the changes, run kubectl apply -f <filename.yaml>
Then, update the yaml file that manages the pods and add the volume and volume mount.