Download PDF
Download page Manually Configure App Agents to Correlate with the Cluster Agent.
Manually Configure App Agents to Correlate with the Cluster Agent
This page describes how to configure APM container correlation with the Cluster Agent when manually instrumenting Kubernetes applications. See Kubernetes.
When you establish APM correlation, the application containers monitored by the Cluster Agent display in the Controller under the Application/Container view. The Cluster Agent Pod Dashboard also provides a link to the APM Node Dashboard in the Pod Details page.
For Kubernetes >=1.25
The following configuration is required only for Kubernetes >=1.25
.
For Kubernetes>= 1.25
, if you require to correlate agents with Cluster Agent you must enable auto-instrumentation and set containerAppCorrelationMethod
to proxy
. This is required for the agents to retrieve the container ID of the application container.
When you enable auto-instrumentation using the proceeding steps, auto-instrumentation does not instrument the application, but starts the container metadata server to fetch the container ID.
You can choose to ignore specific namespaces by using the nsToExcludeRegex
parameter.
To correlate app agents with Cluster Agent on Kubernetes >=1.25
, you must perform the following steps:
- Upgrade the Cluster Agent to version >=
23.9
- Add the following environment variables (env) on the pod on which the application is running:
APPDYNAMICS_CONTAINER_NAME
: <name of the instrumented container>APPDYNAMICS_CONTAINERINFO_FETCH_SERVICE
:'cluster-metadata-service.<namespace of the cluster agent>:<metadataServerPort(default 9090)>'
APPDYNAMICS_POD_NAMESPACE
: <namespace of the application pod>
- Configure the
containerAppCorrelationMethod
parameter under thespec
section in the configuration file with the value asproxy
. For more information about this parameter, see Correlate Application Containers with AppAgents (For Kubernetes version >=1.25) - Edit the configuration file to include the instrumentation method as
Env
. This enables correlation of application containers with Cluster Agent.Applying these properties enable applications to correlate with Cluster Agent for the manual application instrumentation. This does not enable the auto-instrumentation functionality. You must set these properties for manual instrumentation
(In cluster-agent.yaml)
instrumentationMethod: None
Sample cluster-agent.yaml
apiVersion: cluster.appdynamics.com/v1alpha1 kind: Clusteragent metadata: name: k8s-cluster-agent namespace: appdynamics spec: instrumentationMethod: Env
YML(In values.yaml)
enabled: true
forinstrumentationConfig
Sample values.yaml
deploymentMode: MASTER clusterAgent: nsToMonitorRegex: .* instrumentationConfig: enabled: true instrumentationMethod: Env
YMLFor more information about enabling auto-instrumentation, see Auto Instrumentation Configuration.
For Kubernetes <1.25
The following configuration is applicable only for Kubernetes <1.25.
This configuration is required only when you use init containers or Dockerfiles to manually instrument applications in a cluster where the Cluster Agent is running. When you use Cluster Agent auto-instrumentation, APM container correlation is processed automatically. See Auto-Instrument Applications with the Cluster Agent.
APM container correlation uses the UNIQUE_HOST_ID (
or APPDYNAMICS_AGENT_UNIQUE_HOST_ID)
property of specific language agents. For examples of how to set this property, see the language-specific container installation page:
- Install the Java Agent in Containers
- Install the .NET Core Agent for Linux in Containers
- Install the Node.js Agent in Containers
The table lists the commands required to assign the UNIQUE_HOST_ID
value based on runtime, platform, and App Agent type:
Platform | Container Runtime | Command for Container ID |
---|---|---|
Kubernetes | Docker | UNIQUE_HOST_ID=$(sed -rn '1s#.*/##; 1s/(.{12}).*/\1/p' /proc/self/cgroup) |
OpenShift 3.11 | Docker | UNIQUE_HOST_ID=$(sed -rn '1s#.*/##; 1s/docker-(.{12}).*/\1/p' /proc/self/cgroup) |
OpenShift 4.x | CRI-O | UNIQUE_HOST_ID=$(cat /proc/self/cgroup | head -1 | awk -F '/' ' {print $NF}' | awk -F '-' '{print $2}' | cut -c 1-12) ; if [ -z $UNIQUE_HOST_ID]; then UNIQUE_HOST_ID=$(cat /proc/self/cgroup | head -1 | awk -F '/' '{print $NF} ' | cut -c 1-12) ; fi ; |
Kubernetes with Docker
Java APM correlation works out-of-the-box because the Agent retrieves the UNIQUE_HOST_ID
value automatically. For other Agents with the UNIQUE_HOST_ID
property, you must set the property using this command: UNIQUE_HOST_ID=$(sed -rn '1s#.*/##; 1s/-(.{12}).*/\1/p' /proc/self/cgroup)
For all language Agents with a uniqueHostId
property, set the property using this method when building the App image:
UNIQUE_HOST_ID=$(sed -rn '1s#.*/##; 1s/(.{12}).*/\1/p' /proc/self/cgroup)
JAVA_OPTS="$JAVA_OPTS -Dappdynamics.agent.uniqueHostId=$UNIQUE_HOST_ID"
If you cannot change the application image, you can assign the UNIQUE_HOST_ID
in the Kubernetes deployment specification by modifying the command
attribute:
command: ["/bin/sh"]
args: ["-c", "UNIQUE_HOST_ID=$(sed -rn '1s#.*/##; 1s/(.{12}).*/\1/p' /proc/self/cgroup) && java -Dappdynamics.agent.uniqueHostId=$UNIQUE_HOST_ID $JAVA_OPTS -jar /java-services.jar"]
This approach implies that the entry point of the application is known. In the example, the original entry point is:
java $JAVA_OPTS -jar /java-services.jar
OpenShift 3.11 with Docker Runtime
For all language Agents with the UNIQUE_HOST_ID
property in OpenShift v3.10 and v3.11 with Docker runtime, set the property using this method when building the App image:
UNIQUE_HOST_ID=$(sed -rn '1s#.*/##; 1s/docker-(.{12}).*/\1/p' /proc/self/cgroup)
If you cannot change the application image, you can assign the UNIQUE_HOST_ID
in the OpenShift v3.10 or v3.11 deployment specification by modifying the command
attribute:
command: ["/bin/sh"]
args: ["-c", "UNIQUE_HOST_ID=$(sed -rn '1s#.*/##; 1s/docker-(.{12}).*/\1/p' /proc/self/cgroup) && java -Dappdynamics.agent.uniqueHostId=$UNIQUE_HOST_ID $JAVA_OPTS -jar /java-services.jar"]
This approach implies that the entry point of the application is known. In the example, the original entry point is:
java $JAVA_OPTS -jar /java-services.jar
OpenShift 4.x with CRI-O Runtime
For all language Agents with the UNIQUE_HOST_ID
property in OpenShift v4.x with CRI-O runtime, set the property using this method when building the App image:
UNIQUE_HOST_ID=$(cat /proc/self/cgroup | head -1 | awk -F '/' '
{print $NF}' | awk -F '-' '{print $2}' | cut -c 1-12) ; if [ -z $UNIQUE_HOST_ID ]; then UNIQUE_HOST_ID=$(cat /proc/self/cgroup | head -1 | awk -F '/' '{print $NF}' | cut -c 1-12) ; fi ;
If you cannot change the application image, you can assign the UNIQUE_HOST_ID
in the OpenShift v4.x deployment specification by modifying the command
attribute:
command: ["/bin/sh"]
args: ["-c", "UNIQUE_HOST_ID=$(cat /proc/self/cgroup | head -1 | awk -F '/' '{print $NF}' | awk -F '-' '{print $2}' | cut -c 1-12) ; if [ -z $UNIQUE_HOST_ID ]; then UNIQUE_HOST_ID=$(cat /proc/self/cgroup | head -1 | awk -F '/' '{print $NF}' | cut -c 1-12) ; fi ; java -Dappdynamics.agent.uniqueHostId=$UNIQUE_HOST_ID $JAVA_OPTS -jar /java-services.jar"]
This approach implies that the entry point of the application is known. In the example, the original entry point is:
java $JAVA_OPTS -jar /java-services.jar