Use the auto-instrumentation option to dynamically add the required agents to a Java, .NET Core (Linux), or a Node.js application deployed in the Kubernetes cluster. This option requires that you deploy the Cluster Agent to the cluster where the Java application is running. See Monitoring Kubernetes with the Cluster Agent.

By editing the cluster-agent.yaml file, you can enable auto-instrumentation for specific namespaces and/or specific deployments within a namespace. 

When the Cluster Agent detects a supported application deployment and the deployment matches the auto-instrumentation rules with configured namespaces and deployments, then the Cluster Agent modifies the application's deployment specification. The Cluster Agent attaches an init container with the AppDynamics .NET, Node.js, or Java Agent image to the deployment. When the application restarts, the required agent is copied into the application container. The application container now references the AppDynamics agent (Node.js Agent, .NET Agent for Linux, or Java Agent) resulting in an auto-instrumented application. See Enable Auto-instrumentation for the Supported Applications Applications.

(For Java)The auto-instrumentation feature has been tested and certified to work with these Java frameworks:

  • Tomcat
  • Spring 
  • GlassFish
  • JBoss Wildfly

Auto-instrumentation works for any Java application that provides an environment variable that supports the -javaagent argument. See Java Deployment Requirements.

Supported Applications for Auto-Instrumentation

You can auto-instrument:

  • Node.js applications with the Node.js Agent
  • .NET Core on Linux application with the .NET Agent for Linux
  • Java applications with the Java Agent
  • The .NET Core and Node.js applications support only certificates signed by CA, not the self-signed certificates. If your Controller is using a self-signed certificate, only auto-instrumentation for Java applications is supported.
  • To use the custom SSL certificate, ensure to configure the Cluster Agent to use SSL for on-premises Controllers. This certificate is used by the instrumentation agents. See, Configure the Cluster Agent to Use SSL for On-Premises Controllers.
  • For Node.js applications, you must update the following path of the certificate in the shim.js file and use this ConfigMap within the customAgentConfigSource parameter. For more information about this parameter, see Cluster Agent Configuration for Instrumentation Rule.
    certificateFile: “/opt/appdynamics-nodejs/custom-ssl.pem”

Requirements

Java Deployment Requirements

  • Java applications that support including the -javaagent argument in the Java command using an environment variable.
  • Java deployments with pods having a single container running a single JVM process. If you are using multiple containers, the Cluster Agent instruments the first container that is specified in the deployment spec.

Node.js Deployment Requirements

  • The application must use the Node.js 8.6 or higher version.
  • Ensure that you use the correct Node.js Agent image from the docker repository based on the application version and the operating system distribution that you are using. 
    For example, if you require the 20.5.0 Node.js Agent and the application uses the Alpine Linux distribution with Node.js version 10, then you can use the 20.5.0-alpinev10 image. See dockerhub to get the required version with the required operating system distribution. 
  • When configuring for auto-instrumentation, configure the analytics host and port if you require configuring the Node.js Agent to send the default transaction data to the Analytics Agent.

.NET Core Requirements (Linux) 

  • When configuring for auto-instrumentation, configure the analytics host and port if you are configuring the .NET Agent to send the default transaction data to the Analytics Agent.
  • Ensure that you use the correct .NET Agent image from the docker repository based on the application version and the operating system distribution that you are using. 
    For example, if you require the 20.5.0 .NET Agent for Linux and the application uses the Alpine Linux distribution, then you can use the 20.5.0-alpine image. See dockerhub to get the required version with the required operating system distribution. 

Prerequisites

  • The latest cluster-agent-operator.yaml is deployed to the cluster, which grants the Cluster Agent the required permissions. See Deploy the AppDynamics Operator on Kubernetes or Deploy the AppDynamics Operator on Red Hat OpenShift
  • The Cluster Agent is deployed to the cluster (see Install the Cluster Agent)
  • At least one application is deployed to the cluster that is not previously instrumented with the required agent
  • A Controller with sufficient agent licenses based on the number of applications that will be auto-instrumented
  • (For Java) Adjust the configured memory requests or limits for the pods based on Java Agent resource requirements (see Install the Java Agent)
  • Ensure that you have sufficient cluster capacity to handle pod restarts. Additional CPU and memory capacity are required for the initial phase to support the deletion and recreation of pods, especially when there are a large number of pods to auto-instrument. During the auto-instrumentation, the affected deployments undergo a rolling update. As a result, the number of pods in the cluster will temporarily go up while the new pods are being created and the old pods are terminated. The extra capacity required will depend on the number of deployments and the rolling update strategy settings (for example, max surge %). Before turning the auto-instrumentation on, ensure that there are sufficient CPU and memory capacity. It is possible to control the instrumentation rollout by incrementally adding instrumentation rules that target subsets of deployments.

Permissions

These permissions are required by the Cluster Agent to implement auto-instrumentation:

  • Modify deployment specification
  • Execute commands in pods
  • Create or update secrets to manage access keys in namespaces

By default, these permissions are added when you deploy the cluster-agent-operator.yaml file.

Enable Auto-Instrumentation for the Supported Applications

To enable auto-instrumentation for the Java applications deployed to a cluster you must create instrumentation rules and define the required parameters.

Perform the following steps to enable auto-instrumentation :

  1. Create a Cluster Agent secret with the Controller access key and API client credentials:

    kubectl -n appdynamics create secret generic cluster-agent-secret --from-literal=controller-key=<access-key> --from-literal=api-user="<username>@<customer>:<password>"

    Here, an api-user can be any user who has access to the controller with the assigned role as Administrator. The api-user is required to mark the nodes historical upon pod deletion.

    If an access key was already created without the api-user literal, then delete and recreate it. The api-user is required to mark the nodes historical upon pod deletion.

  2. Configure the cluster-agent.yaml file for auto-instrumentation. These configuration properties are mandatory: 
    1. instrumentationMethod: Set value to Env to enable instrumentation.
    2. nsToInstrumentRegex: Configure the namespaces that you want to monitor.
    3. instrumentationRules: Specify the auto-instrumentation rules and child properties. 
    • If the deployment does not match with the properties mentioned in instrumentationRules, the auto-instrumentation is not enabled. 
    • If there are no values specified for the parameters that are used in selecting rules within instrumentationRules, Cluster Agent uses the corresponding default value specified in Cluster Agent Configuration for Auto-Instrumentation. If there are no corresponding default values, auto-instrumentation is not enabled.

    See Cluster Agent Configuration for Auto-instrumentation.

  3. Apply the updated cluster-agent.yaml using kubectl:

    kubectl apply -f cluster-agent.yaml

    After you apply the updated cluster-agent.yaml file, the related pods and containers are restarted based on the deployment rollout strategy associated with the applications.

The pod annotation may display  APPD_POD_INSTRUMENTATION_STATE as failed for the Node.js and the .NET (Linux) applications even when the instrumentation is successful. To verify if the instrumentation is successful, see the deployment spec.

Options for Naming the AppDynamics Application

There are three application naming strategies available to name an application in the Controller's Application Dashboard. Select a strategy by assigning the appNameStrategy property to one of these values:

  • manual: use the defaultAppName or appName parameters in the cluster-agent.yaml file to set the application name.

  • label: use a label from the application's deployment spec as the application name.

  • namespace: use the Kubernetes namespace as the application name.

Manual

By default, the appNameStrategy is manual, which uses the defaultAppName or appName parameter to set the application name.

  • If defaultAppName is provided, use it, unless overridden in an instrumentation rule.
  • If appName is provided in an instrumentation rule, use it.

For example, in the following spec, ECommerce is the default application name applied to the ecom and groceries namespace, and BookStore is the application name applied to the books namespace.

apiVersion: appdynamics.com/v1alpha1
kind: Clusteragent
metadata:
  name: k8s-cluster-agent
  namespace: appdynamics
spec:
  appName: "<cluster-name>"
  # ...
  # auto-instrumentation config
  instrumentationMethod: Env
  nsToInstrumentRegex: ecom|books|groceries
  appNameStrategy: manual
  defaultAppName: ECommerce
  instrumentationRules:
    - namespaceRegex: books
      appName: BookStore
YML

Label

This option uses the label parameter as the application name strategy. To use the label option, specify a value in the appNameLabel parameter. The appNameLabel value refers to a label specified in the application deployment spec.  

  • If spec.appNameLabel is provided, use it, unless overridden in an instrumentation rule.
  • If appNameLabel is provided in an instrumentation rule, use it.

For example, in the following spec, the deployment spec label appname will be used to set the application name in the ecom and groceries namespaces, and the label app will be used in the books namespace.

apiVersion: appdynamics.com/v1alpha1
kind: Clusteragent
metadata:
  name: k8s-cluster-agent
  namespace: appdynamics
spec:
  appName: "<cluster-name>"
  # ...
  # auto-instrumentation config
  instrumentationMethod: Env
  nsToInstrumentRegex: ecom|books|groceries
  appNameStrategy: label
  appNameLabel: appname
  instrumentationRules:
    - namespaceRegex: books
      appNameLabel: app
YML

For an application deployed to the ecom or groceries namespaces that sets the label appname as shown in the following deployment spec snippet, it will report to the eCommerce application in the Controller's Application Dashboard.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: ecom-app
  labels:
    appname: eCommerce
spec:
...
YML


Namespace

This option uses the namespace parameter as the application name strategy. This option allows you to use the namespace name where an application is deployed as the application name in the Controller's Application Dashboard.

In the following spec, each application in ecom, books and groceries namespace will use the application name based on the namespace it is deployed to.

apiVersion: appdynamics.com/v1alpha1
kind: Clusteragent
metadata:
  name: k8s-cluster-agent
  namespace: appdynamics
spec:
  appName: "<cluster-name>"
  # ...
  # auto-instrumentation config
  instrumentationMethod: Env
  nsToInstrumentRegex: ecom|books|groceries
  appNameStrategy: namespace
YML


Disable Auto-Instrumentation

By default, the auto-instrumentation of applications is disabled. If you have already enabled auto-instrumentation and want to disable it for a specific namespace, remove that namespace from nsToInstrumentRegex. To completely disable auto-instrumentation, set the instrumentationMethod to None.

Minimize the Impact of Pod Restarts

When auto-instrumentation is enabled using the enable steps, the related pods are restarted based on the deployment rollout strategy associated with the deployments. This restart may cause a significant impact on the cluster because the pods are deleted and recreated. To reduce the impact of restarting a large number of pods, Cluster Agent by default allows only two concurrent auto-instrumentation tasks. The subsequent deployments (resourcesToInstrument) are auto-instrumented after the rollout of instrumented deployment. However, you can configure the parameter, numberOfTaskWorkers, to specify the number of concurrent auto-instrumentation tasks based on your setup

Cluster Agent Configuration for Auto-Instrumentation

These configuration parameters are supported in the cluster-agent.yaml file for auto-instrumentation. See Configure the Cluster Agent for additional configuration parameters supported by the Cluster Agent.

Parameter Name

Default Value

Description

appNameStrategymanual

The option to specify a name for the Appdynamics application. You can specify any of the following values for this parameter:

  • manual
  • namespace
  • label

For more information about using this parameter, see Options for Naming the Appdynamics Application.

appNameLabel
The value of this label will be the AppDynamics application name. 
defaultAnalyticsHost

The hostname of the Analytics Agent.

This parameter is required if you require the Node.js Agent or the .NET Agent to send the default transaction data to the Analytics Agent.

The default value is applied to all the instrumented resources unless it is overridden by the instrumentationRules configuration.

defaultAnalyticsPort

The listening port for Analytics Agent.

For example, if the Analytics Agent is listening on port 9090, then the value of this parameter is 9090.

The default value is applied to all the instrumented resources unless it is overridden by the instrumentationRules configuration.

This parameter is required along with defaultAnalyticsHost if you require the Node.js or the .NET Agent to send the default transaction data to the Analytics Agent.

defaultAnalyticsSslEnabled

This value is based on whether the Analytics Agent port is SSL enabled or not. If the port is SSL enabled, specify the value as true, else specify as false.

This parameter is required along with defaultAnalyticsPort and defaultAnalyticsHost if you require the Node.js or the .NET Agent to send the default transaction data to the Analytics Agent.

The default value is applied to all the instrumented resources unless it is overridden by the instrumentationRules configuration.

defaultAppName

""Application name used by the agent to report to the Controller. This is required.
defaultCustomConfig

This parameter is specific to Java applications.

You can add any custom system property if your application framework requires any specific configuration for instrumentation.

This value gets appended to the env or defaultEnv variable as configured along with other Java Agent properties.

defaultContainerMatchString

This is a regex value to choose the containers to instrument. This parameter requires you to use the select option within the instrumentContainer (specified in the instrumentation rules).

When the select option is used along with this parameter, Cluster Agent instruments the containers that match the regex value.

defaultEnv

JAVA_TOOL_OPTIONS

This parameter is specific to Java applications.

Environment variable to which the -javaagent argument and App Agent system properties are added.

You can override this to use any other environment best suited for the deployment

defaultInstrumentationLabelMatch


[ ]

Specific deployment labels marked for instrumentation.

This parameter accepts a list of key-value pairs to instrument.

You must match a minimum of one label for instrumentation.

For example:

defaultInstrumentationLabelMatch:
- label1: value1

- label1: value2

- label2: value2

For example, if only label1: value2 matches, the instrumentation works as expected.

defaultInstrumentMatchString

.*

Names of deployments targeted for instrumentation.

This parameter is used as the default value for the matchstring parameter that is specified within instrumentationRules. If matchstring is not specified, then Cluster Agent uses this parameter value.

This parameter accepts deployment names as a regular expression or regex.

If there are multiple deployments to instrument, you can separate names with a '|' without spaces.

By default, this parameter instruments all deployments configured by nsToInstrumentRegex. Therefore, if there is no value specified for matchString in the instrumentation rules and if you do not specify any value for this parameter, then Cluster Agent instruments every deployment.

imageInfo

java:
  image: "docker.io/appdynamics/java-      agent:latest"
  agentMountPath: "/opt/appdynamics"
  imagePullPolicy: "IfNotPresent"
CODE 
dotnetcore:
    image: "docker.io/appdynamics/dotnet-core-agent:latest"
    agentMountPath: /opt/appdynamics
    imagePullPolicy: "IfNotPresent"
CODE 
nodejs:
 image: "docker.io/appdynamics/nodejs-agent:20.8.0-stretch-slimv14"
 agentMountPath: /opt/appdynamics
 imagePullPolicy: "IfNotPresent"
CODE

The Docker repository from where the Node.js Agent, .NET Agent for Linux, and Java Agent is pulled.

Supported values are:

  • image: Location of the agent image, along with its tag/version
  • agentMountPath: Location of image artifacts in the image file system. The default is /opt/appdynamics. 
    You must change this configuration if the path is different.
  • imagePullPolicy: The pull policy required for the agent's docker image. You can choose one of the following pull policy based on your requirement:

      • Always

      • IfNotPresent

      • Never

    This parameter is used in the init containers that are added during auto-instrumentation.

instrumentationMethod

None

The instrumentation method used for instrumenting Apps.

Supported values are:

  • None: Instrumentation is disabled
  • Env: Attach the instrumentation properties to the container environment variables. If a value is not set, the instrumentation will not start.

instrumentationRules

[ ]

This is a mandatory parameter to enable auto-instrumentation.
This includes the list of specific instrumentation rules. You can apply the rules to one or more namespaces, and can filter on deployment names and labels. Instrumentation rules are granular to support targeting specific deployments.

See Cluster Agent Configuration for Instrumentation Rules.

nsToInstrumentRegex

""

Required. If you do not specify a value, auto-instrumentation will not work.

Specify the namespaces to be instrumented as a regex.

If there are multiple namespaces to instrument, separate namespaces using "|" without spaces.

By default, namespaces are not instrumented.

numberOfTaskWorkers2

To configure the rate limit for the number of deployments that are auto-instrumented at the same time.

Increasing this value may lead to a larger number of concurrent pod restarts in the cluster.

netvizInfo

bciEnabled: true

port: 3892


To configure the Network Visibility App Agent, netviz, you must deploy a Network Agent separately (in addition to setting this parameter).
See Network Visibility with Kubernetes for steps to install the Network Agent.

By default, netviz is enabled. In the absence of a Network Agent, this property does not have any impact.
You can enable or disable the netviz Agent per your requirements.

Supported values are:

  1. bciEnabled: Boolean flag denoting whether netviz is enabled or not.
  2. port: The port the Network Agent is listening on (default is 3892). Override this value only when running the Network Agent on a port other than the default port.

runAsGroup

0

If you configured the application container as a non-root user, provide the group ID (GID) of the corresponding group.

runAsGroup is used to set the appropriate file permission on the agent artifacts.

The default runAsGroup value is applied to all the instrumented resources, unless it is overridden by the instrumentationRules configuration.

runAsUser

0

If you configured the application container as a non-root user, provide the user ID (UID) of the corresponding user.

runAsUser is used to set the appropriate file permission on the agent artifacts.

The default runAsUser value is applied to all the instrumented resources, unless it is overridden by instrumentationRules configuration.

resourcesToInstrumentDeployment

Cluster Agent instruments the resources that are listed in this parameter. The default value is Deployment. If you need to instrument StatefulSets, add StatefulSet to the list.

For example, to instrument Deployments and StatefulSets, configure as follows:

resourcesToInstrument:

- Deployment
- StatefulSet

Cluster Agent Configuration for Instrumentation Rules

To further customize your configuration for a specific namespace or deployment, you can use instrumentation rules. To create a rule, use the instrumentationRules property and child properties from this table. Use these properties to override the default instrumentation rules for specific namespaces. Additionally, you can use them to assign different Controller application names and Agent versions per namespace.

The Cluster Agent uses a combination of namespaceRegex, matchString, and labelMatch for selecting an instrumentation rule, on a first match basis. If the rules do not match, the configuration returns to the default values that were specified by these parameters:

  • nsToInstrumentRegex
  • defaultInstrumentationLabelMatch
  • defaultInstrumentMatchString

For example, instrumentation rule -matchString "<string>" is added to the Cluster Agent configuration file:

instrumentationRules:
    - matchString: "<string>"

If the name of the deployment matches this string, the remaining parameters under instrumentationRules will be applied. If the string does not match, auto-instrumentation is stopped. If the parameters are not defined within the rules then the Cluster Agent defaults to the parameters nsToInstrumentRegex, defaultInstrumentationLabelMatch, and defaultInstrumentMatchString to determine the instrumentation rules.

Parameter Name

Default Value

Description

analyticsHost

The hostname of the Analytics Agent.

This parameter is required if you require the Node.js Agent or the .NET Agent to send the default transaction data to the Analytics Agent.

analyticsPort

The listening port for Analytics Agent.

For example, if the Analytics Agent is listening on port 9090, then the value of this parameter is 9090.

This parameter is required along with defaultAnalyticsHost if you require the Node.js or the .NET Agent to send the default transaction data to the Analytics Agent.

analyticsSslEnabled

This value is based on whether the Analytics Agent port is SSL enabled or not. If the port is not SSL enabled, specify the value as false.

This parameter is required along with defaultAnalyticsPort and defaultAnalyticsHost if you require the Node.js or the .NET Agent to send the default transaction data to the Analytics Agent.

containerMatchString

This is a regex value to choose the containers with the name that satisfies the value. This parameter requires you to use the select option within defaultInstrumentContainer or instrumentContainer.

When the select option is used along with this parameter, Cluster Agent instruments the containers that match the regex value

This parameter overrides the default value specified for defaultContainerMatchString.

customAgentConfigSource

This parameter provides an option to use the custom configuration of the instrumenting agents through ConfigMaps. This parameter requires that you create the required ConfigMaps in the Cluster Agent namespace. This parameter is dynamically configurable from the Cluster Agent YAML file. The changes that you make in the YAML file are updated to all the instrumented agents without restarting the application. Similarly, the changes that you make to the configuration in the ConfigMap is updated to all the instrumented agents without restarting the application.

  • configMapName: Specify the name of the ConfigMap. This allows the agent to use the same custom ConfigMap to update all the instrumented agent namespace.
  • subDir: (required for Java Agent) Specify the relative path where the ConfigMaps are mounted.
    For example /ver20.8.0.3686/conf
    Where 20.8.0.3686 is the version of the Java Agent. This directory may differ based on the Java Agent version.
    For more details, see Example 6.
    The absolute mount path for the ConfigMap is <agent home path>/subDir
    This ConfigMap replaces any ConfigMap of the same name in the target application's namespace.

If you require to remove a ConfigMap file (used in the rules) from your deployment, then you must ensure to first remove this parameter from the Cluster Agent YAML file, and then remove the ConfigMap from the Cluster Agent's namespace.


instrumentContainer

First

This parameter provides an option to choose the container that must be instrumented. You can specify any of the following values:

  • first: This is the default value. When you specify this value, Cluster Agent instruments the first container in the pod.
  • all: When you specify this value, Cluster Agent instruments all the containers in the pod.
  • select: When you specify this value, Cluster Agent instruments only those containers with the name that matches a regex specified in the defaultContainerMatchString parameter or the containerMatchString parameter.
language

The language of the application to be instrumented.

The following languages are supported:

  • dotnetcore
  • java
  • nodejs
matchString

Regular expression to match on deployment name on which the rule applies

If you do not specify any value for this parameter, the Cluster Agent takes into account the value specified in the defaultInstrumentMatchString and instruments all the deployments that satisfy the value.

labelMatch{}A list of key-value pairs of labels to include in this rule. It is sufficient to match any one of the labels.

For example:
labelMatch:
-label1: value1
-label1: value2
-label2: value2
If only label1: value2 matches, then instrumentation works as expected.

appName<defaultAppName>

Application name used by the Java Agent to report to the Controller. This overrides defaultAppName.

If no value is provided, the configured defaultAppName is used.

appNameLabel
The value of this label will be the AppDynamics application name. 
customAgentConfig

This parameter is specific to Java applications.

You can add any custom system property if your application framework requires any specific configuration for instrumentation.
This value takes precedence over the default value specified in the defaultCustomConfig parameter.

This value gets appended to the env or defaultEnv variable as configured along with other Java Agent properties.

tierName""

Tier name used by the Java Agent to report to the Controller.

If no tier name is provided, the deployment name is used as the default.

env""

This parameter is specific to Java applications.

Environment variable to which the App Agent system properties will be added. When specified, this overrides defaultEnv for the deployments matching this instrumentation rule.

If none are provided, it defaults to the defaultEnv (if configured), or to the default env JAVA_TOOL_OPTIONS (if not configured at default cluster level).

imageInfo
image:  "docker.io/appdynamics/java-agent:latest"
agentMountPath: "/opt/appdynamics"
imagePullPolicy: "IfNotPresent"
CODE 
dotnetcore:
image: "docker.io/appdynamics/dotnet-core-agent:latest"
    agentMountPath: /opt/appdynamics
imagePullPolicy: "IfNotPresent"
CODE 
nodejs:
 image: "docker.io/appdynamics/nodejs-agent:20.8.0-stretch-slimv14"
 agentMountPath: /opt/appdynamics
imagePullPolicy: "IfNotPresent"
CODE

Location of the agent image. You can select one of these parameters:

  • image: Location of the agent image, and its tag/version.
  • agentMountPath: Location of image artifacts in the image file system. The default is /opt/appdynamics. This configuration is required only if the path differs from the default path.
  • imagePullPolicy: The pull policy required for the agent's docker image. The default is IfNotPresent. You can choose one of the following pull policy based on your requirement:
    • Always
    • IfNotPresent
    • Never
    This parameter is used in the init containers that are added during auto-instrumentation.

The default value is IfNotPresent.

For the specific language mentioned in this rule, this overrides image-info for the deployments matching this instrumentation rule.

You must configure this if you want to override the default cluster-level configuration, and use a custom agent version for this specific rule selection.

netvizInfo

bciEnabled: true

port: 3892


To configure the Network Visibility App Agent, netviz, you must deploy a Network Agent separately (in addition to setting this parameter).
See Network Visibility with Kubernetes for steps to install the Network Agent.

By default, netviz is enabled. In the absence of a Network Agent, this property does not have any impact.
You can enable or disable the netviz Agent per your requirements.

Supported values are:

  1. bciEnabled: Boolean flag denoting whether netviz is enabled or not.
  2. port: The port the Network Agent is listening on (default is 3892). Override this value only when running the Network Agent on a port other than the default port.

runAsGroup

0

If you configured the application container as a non-root user, provide the groupId of the corresponding group.

This sets the appropriate file permission on the agent artifacts.

This value is applied to all the instrumented resources.

Add this parameter, if you require to override the default value of runAsGroup that is configured for default instrumentation, or if you require a specific value for the resources that satisfy this rule.

runAsUser

0

If you configured the application container as a non-root user, it provides the userId of the corresponding user.

This sets the appropriate file permission on the agent artifacts.

This value is applied to all the instrumented resources.

Add this parameter, if you require to override the default value of runAsUser that is configured for default instrumentation, or if you require a specific value for the resources that satisfy this rule.

Configuration Examples

Example 1: Instrument all the deployments in the ecom namespace. The Java Agents running in each pod will register to the Controller with the Ecommerce application, and the tier names will default to the Kubernetes deployment names.

Example 2: Instrument only those deployments with names starting with Payment and with the label module=payment in any namespace.

Example 3: Instrument all deployments in namespaces ecom and books. For applications in the books namespace, use the BookStore application name in the Controller and a specific version of the Java Agent.

Example 4: Override the configuration in Example 3 for the groceries namespace to use a different Controller application name, and the JAVA_OPTS environment variable to inject the -javaagent Java argument.

Example 5: Instrument a Node.js application in namespace books and a .NET Core Linux application in namespace groceries. Also, the Node.js application must send the transaction data to the Analytics Agent.

Example 6: Instrument the containers with the names that start with str for the Java application in namespace ecom. Also, use the custom agent configurations in controller-info.xml and app-agent-config.xml configuration files that are present in the controllerConf ConfigMap along with the log4j2.xml file for logging settings of agent present in logConf ConfigMap. These ConfigMaps are present in the Cluster Agent's namespace.

Example 7: Instrument all the deployments in the groceries namespace and instrument only those deployments with names starting with Payment in the books and ecom namespace.

apiVersion: appdynamics.com/v1alpha1
kind: Clusteragent
metadata:
  name: k8s-cluster-agent
  namespace: appdynamics
spec:
  appName: "<app-name>"
  controllerUrl: "<protocol>://<appdynamics-controller-host>:8080"
  account: "<account-name>"
  # docker image info
  image: "<your-docker-registry>/appdynamics/cluster-agent:tag"
  nsToMonitor:
    - "default"
  # auto-instrumentation config
  instrumentationMethod: Env
  nsToInstrumentRegex: ecom
  defaultAppName: Ecommerce
  instrumentationRules:
    imageInfo:
      java:
        image: "docker.io/appdynamics/java-agent:20.3.0"
        agentMountPath: /opt/appdynamics
        imagePullPolicy: Always
YML 
apiVersion: appdynamics.com/v1alpha1
kind: Clusteragent
metadata:
  name: k8s-cluster-agent
  namespace: appdynamics
spec:
  appName: "<app-name>"
  controllerUrl: "<protocol>://<appdynamics-controller-host>:8080"
  account: "<account-name>"
  # docker image info
  image: "<your-docker-registry>/appdynamics/cluster-agent:tag"
  nsToMonitor:
    - "default"
  # auto-instrumentation config
  instrumentationMethod: Env
  nsToInstrumentRegex: .*
  defaultAppName: Ecommerce
  instrumentationRules:
  - matchString: ^Payment
    labelMatch:
    - module: payment
YML 
apiVersion: appdynamics.com/v1alpha1
kind: Clusteragent
metadata:
  name: k8s-cluster-agent
  namespace: appdynamics
spec:
  appName: "<app-name>"
  controllerUrl: "<protocol>://<appdynamics-controller-host>:8080"
  account: "<account-name>"
  # docker image info
  image: "<your-docker-registry>/appdynamics/cluster-agent:tag"
  nsToMonitor:
    - "default"
  # auto-instrumentation config
  instrumentationMethod: Env
  nsToInstrumentRegex: ecom|books
  defaultAppName: Ecommerce
  instrumentationRules:
    - namespaceRegex: books
      appName: BookStore
      imageInfo:
        image: "docker.io/appdynamics/java-agent:4.5.19"
        agentMountPath: /opt/appdynamics
        imagePullPolicy: Always
    - namespaceRegex: ecom
YML 
apiVersion: appdynamics.com/v1alpha1
kind: Clusteragent
metadata:
  name: k8s-cluster-agent
  namespace: appdynamics
spec:
  appName: "<app-name>"
  controllerUrl: "<protocol>://<appdynamics-controller-host>:8080"
  account: "<account-name>"
  # docker image info
  image: "<your-docker-registry>/appdynamics/cluster-agent:tag"
  nsToMonitor:
    - "default"
  # auto-instrumentation config
  instrumentationMethod: Env
  nsToInstrumentRegex: ecom|books|groceries
  defaultAppName: Ecommerce
  imageInfo:
    java:
      image: "docker.io/appdynamics/java-agent:latest"
      agentMountPath: /opt/appdynamics
      imagePullPolicy: Always
  instrumentationRules:
    - namespaceRegex: books
      appName: BookStore
      imageInfo:
        image: "docker.io/appdynamics/java-agent:4.5.19"
        agentMountPath: /opt/appdynamics
        imagePullPolicy: Always
    - namespaceRegex: groceries
      appName: Groceries
      env: JAVA_OPTS
    - namespaceRegex: ecom
      #no appName and matchstring for this rule so it will take default appName and default matchstring which is .*
YML 
apiVersion: appdynamics.com/v1alpha1
kind: Clusteragent
metadata:
  name: k8s-cluster-agent
  namespace: appdynamics
spec:
  appName: "<app-name>"
  controllerUrl: "<protocol>://<appdynamics-controller-host>:8080"
  account: "<account-name>"
  # docker image info
  image: "<your-docker-registry>/appdynamics/cluster-agent:tag"
  nsToMonitor:
    - "default"
  # auto-instrumentation config
  instrumentationMethod: Env
  nsToInstrumentRegex: ecom|books|groceries
  defaultAppName: Ecommerce
  appNameStrategy: namespace
  imageInfo:
    java:
      image: "docker.io/appdynamics/java-agent:latest"
      agentMountPath: /opt/appdynamics
      imagePullPolicy: Always
  instrumentationRules:
    - namespaceRegex: groceries
      language: dotnetcore
      imageInfo:
        image: "docker.io/appdynamics/dotnet-core-agent:latest"
        agentMountPath: /opt/appdynamics
        imagePullPolicy: Always
    - namespaceRegex: books
      matchString: openmct
      language: nodejs
      imageInfo:
        image: "docker.io/appdynamics/nodejs:20.6.0"
        agentMountPath: /opt/appdynamics
        imagePullPolicy: Always
      analyticsHost: <hostname of the Analytics Agent>
      analyticsPort: 443
      analyticsSslEnabled: true
YML 
apiVersion: appdynamics.com/v1alpha1
kind: Clusteragent
metadata:
  name: k8s-cluster-agent
  namespace: appdynamics
spec:
  appName: "<app-name>"
  controllerUrl: "<protocol>://<appdynamics-controller-host>:8080"
  account: "<account-name>"
  # docker image info
  image: "<your-docker-registry>/appdynamics/cluster-agent:tag"
  nsToMonitor:
    - "default"
  # auto-instrumentation config
  instrumentationMethod: Env
  nsToInstrumentRegex: ecom
  defaultAppName: Ecommerce
  instrumentationRules:
    - namespaceRegex: ecom
      matchString: ^Payment
      appName: <application-name>
      language: <language>
      customAgentConfigSource:
       - configMapName: controllerConf
         subDir: /ver20.8.0.3686/conf/
       - configMapName: logConf
         subDir: /ver20.8.0.3686/conf/logging
      instrumentContainer: select
      containerMatchString: ^str
      imageInfo:
        image: <image-repo>
        imagePullPolicy: IfNotPresent
YML 
apiVersion: appdynamics.com/v1alpha1
kind: Clusteragent
metadata:
  name: k8s-cluster-agent
  namespace: appdynamics
spec:
  appName: "<app-name>"
  controllerUrl: "<protocol>://<appdynamics-controller-host>:8080"
  account: "<account-name>"
  # docker image info
  image: "<your-docker-registry>/appdynamics/cluster-agent:tag"
  nsToMonitor:
    - "default"
  # auto-instrumentation config
  instrumentationMethod: Env
  nsToInstrumentRegex: ecom|books|groceries
  defaultAppName: Ecommerce
  appNameStrategy: namespace
  defaultMatchString: ^payment
  imageInfo:
    java:
      image: "docker.io/appdynamics/java-agent:latest"
      agentMountPath: /opt/appdynamics
      imagePullPolicy: Always
  instrumentationRules:
    - namespaceRegex: groceries
      matchString: .*
    - namespaceRegex: ecom|books
      #no matchstring so it will take default matchstring which is ^payment
YML