Example 1 targets Java applications in the namespaces that match the ecom.* pattern. Each matching application will be instrumented with a 20.20.1 Java Agent and will report to the Ecommerce application in the Splunk AppDynamics Controller. By default, the tier name is the name of the Kubernetes workload, but you can override it by setting the tierName property.

apiVersion: cluster.appdynamics.com/v1alpha1
kind: Clusteragent
metadata:
name: k8s-cluster-agent
namespace: appdynamics
spec:
appName: "<cluster-name>"
controllerUrl: "<protocol>://<appdynamics-controller-host>:8080"
account: "<account-name>"
image: "docker.io/appdynamics/cluster-agent:20.12.1"
serviceAccountName: appdynamics-cluster-agent
nsToMonitorRegex: ecom.*
#
# auto-instrumentation config
#
instrumentationMethod: Env
nsToInstrumentRegex: ecom.*
defaultAppName: Ecommerce
instrumentationRules:
- language: java
imageInfo:
image: docker.io/appdynamics/java-agent:20.20.1
agentMountPath: /opt/appdynamics

Example 2 targets namespaces that contain Java and .NET Core on Linux applications, and incorporates these advanced configurations:

• Uses multiple instrumentationRules to target Java applications versus .NET Core on Linux applications.
• Uses the labelMatch strategy to determine the agent type and associated agent image based on the value of the framework label in the workload spec auto-instrumented-dotnet-app.yaml and auto-instrumented-java-app.yaml .
• Rather than assigning a Controller application name in the YAML file, the configuration uses appNameStrategy: label to assign an application name based on a label from the workload spec.
• For the Java applications, it uses instrumentContainer: select and containerMatchString: .*service to instruct the Cluster Agent to auto-instrument only the application service container only, and ignore any other defined containers defined.

apiVersion: cluster.appdynamics.com/v1alpha1
kind: Clusteragent
metadata:
name: k8s-cluster-agent
namespace: appdynamics
spec:
appName: "<cluster-name>"
controllerUrl: "<protocol>://<appdynamics-controller-host>:8080"
account: "<account-name>"
image: "docker.io/appdynamics/cluster-agent:20.12.1"
serviceAccountName: appdynamics-cluster-agent
nsToMonitorRegex: ecom.*
#
# auto-instrumentation config
#
instrumentationMethod: Env
nsToInstrumentRegex: stage
appNameStrategy: label
instrumentationRules:
- namespaceRegex: stage
language: dotnetcore
labelMatch:
- framework: dotnetcore
appNameLabel: appName
imageInfo:
image: "docker.io/appdynamics/dotnet-core-agent:20.11.0-linux"
agentMountPath: /opt/appdynamics
- namespaceRegex: stage
language: java
labelMatch:
- framework: java
appNameLabel: appName
instrumentContainer: select
containerMatchString: .*service
imageInfo:
image: "docker.io/appdynamics/java-agent:21.3.0"
agentMountPath: /opt/appdynamics

Examples 3 and 4 show Deployment specs for .NET and Java services that define the appName and framework labels, based on the auto-instrumentation configuration from the cluster-agent-auto-2.yaml:

Example 3: auto-instrumented-dotnet-app.yaml

.NET

apiVersion: apps/v1
kind: Deployment
metadata:
name: dotnet-profile-service
labels:
appName: backend-services
framework: dotnetcore
spec:
containers:
- image: myrepo/profile-service:v2
name: profile-service
# ...

Example 4: auto-instrumented-java-app.yaml

Java

apiVersion: apps/v1
kind: Deployment
metadata:
name: java-account-service
labels:
appName: backend-services
framework: java
spec:
containers:
- image: myrepo/account-service:v2
name: account-service
- image: myrepo/proxy-util:v1
name: proxy-util
# ...

The value of containerMatchString in cluster-agent-auto-2.yaml indicates that only the account-service container will be auto-instrumented in auto-instrumented-java-app.yaml.

For additional configuration examples, see Auto-Instrumentation Configuration Examples.