Playbooks

The playbooks folder in the Splunk AppDynamics Ansible Collections contains example playbooks for each agent type. You can use the example playbooks in the collection installation folder.

The playbooks/vars directories contain constant variables such as enable_ssl, controller_port, etc. You can either include YAML files in the playbook as shown in the following Java example, or overwrite the variables in the playbooks.

Note: Check the precedence rules of Ansible, before continuing the installation.

When you install the Splunk AppDynamics Collection, you can use the following agents:

Agent Type Description
sun-java7 or java7 Agent to monitor Java applications running on JRE version 1.7 and less
sun-java or java Agent to monitor Java applications running on JRE version 1.8 and above
dotnet_msi Machine global agent to monitor .Net and .Net Framework applications on Windows
machine 64-Bit Machine agent ZIP bundle with JRE for Windows and Linux
python Agent to Monitor Python applications on Linux.
php Agent to Monitor PHP applications on Linux or Red Hat-based system
node Agent to Monitor NodeJS application on Linux

Custom Agent Download Path

Note: This is not applicable to .Net Agent MSI.

If you do not want playbooks to download the agent files from the official Downloads portal, you can use the following variable in playbooks to install the agents from your preferred location.

Variable Description Applicable Agents
download_protocol

The mechanism to download the agent, example values are:

  • http - to transfer files from a file server
  • local - to transfer files from your control node
  • nfs - transfer file from a shared file system
All
download_uri The location of the agent file. It can be URL or the absolute/relative path on the local/NFS file system All
linux_install_root Use this to configure the folder where all installed agent and backup files reside. For example, for Java agent, <linux_install_root>/java-agent and <linux_install_root>/backup/java-agent is created. The default value is /opt/appdynamics for Linux. Apache, Java, Machine, .Net, Node.js, PHP, Python
windows_install_root Similar to linux_install_root , to be used on Windows hosts. The default value is C:/appdynamics . Apache, Java, Machine, .Net
linux_custom_agent_install_path Use this to specify the Agent installation path and override the default installation path which is the root directory (see linux_install_root , and windows_install_root). The agent backup resides in the root directory and is not configured by this variable. The agent files are installed in this directory. Do not specify this path to store the files oflinux_install_root. Apache, Java, Machine, .Net, Node.js, PHP, Python
windows_custom_agent_install_path Similar to linux_custom_agent_install_path , to be used on Windows hosts. Apache, Java, Machine, .Net

Common Role Variables

Description Applicable Agents
agent_action To perform an upgrade, install, rollback, or uninstall. All
agent_dir_permission.user To assign user file permissions for the Java Agent on Linux. The user and group selected must already exist on the host if create_appdynamics_user is set to No . Java
agent_dir_permission.group To assign group file permissions for the Java Agent on Linux. The user and group selected must already exist on the host if create_appdynamics_user is set to No . Java
agent_log_level The log level for the agent. The valid options are — info, trace, debug, warn, error, fatal, all, and off. This setting is applied to all the loggers named in the agent_loggers list. Java, Machine, PHP
agent_loggers To set the log level on the list of loggers. The logger names vary from agent to agent. The default is set to * , com.singularity , com . Update this variable with loggers specific to the target agent. See log4j files in the /conf/logging directory. Java, Machine
agents_to_set_loggers_for

The list of agents to apply the log-level changes. For example, to set the log level of all deployed agents to info java

Note: This variable should not be set when using the logger role as part of agent deployments. The agent_type variable will be used to determine how the log level needs to be adjusted during the installation.
Java, Machine
agent_type

The Splunk AppDynamics agent type. For example, java

All
agent_version

The Splunk AppDynamics agent version. The value can be latest

Splunk AppDynamics uses calendar versioning. For example, if a Java Agent is released in February of 2023, its version will be 23.2.0.

All
appdynamics_user

Splunk AppDynamics functional user name. The default is appdynamics.

Java, Machine
application_name The application name. This variable is mandatory for all the java roles. All
controller_account_name

The Splunk AppDynamics Controller account name.

All
controller_account_access_key The access key for the Controller account. This should be placed in the vault. All
controller_host_name

The Controller hostname. Do not include http(s)

All
controller_port The Controller port. All
create_appdynamics_user

To create Splunk AppDynamics functional user on Linux.

Java, Machine
dir The base directory for agent files. Default: /tmp/appd/ All
enable_proxy Set to true to apply agent proxy settings to the agent configuration. Assign the proxy_host and proxy_port variables. Java, .Net
enable_ssl Indicate if SSL is enabled in the Controller or not. All
init_and_validate _agent_variables This variable controls running the common role initialization (which sets download URLs and Controller parameters). When using the logger role in isolation (that is not as part of agent installation) the value should be false . Java, Machine
keep_backup Use when agent_action is uninstall . Set to true to keep the agent backup files after uninstalling. Default value is false . Apache, Java, Machine, Node.js, PHP, Python
linux_install_root Use this to configure the folder where all installed agent and backup files reside. For example, for Java agent, <linux_install_root>/java-agent and <linux_install_root>/backup/java-agent is created. The default value is /opt/appdynamics for Linux. Apache, Java, Machine, Node.js, PHP, Python
linux_custom_agent_install_path Use this to specify the Agent installation path and override the default installation path which is the root directory (see linux_install_root). The agent backup resides in the root directory and is not configured by this variable. The agent files are installed in this directory. Do not specify this path to store the files of linux_install_root. Apache, Java, Machine, Node.js, PHP
max_agent_backup_count Maximum allowed backups per agent. The default value is one. Java
node_name

The Splunk AppDynamics node name for java

Apache, Java, Machine, Node.js, PHP, Python
proxy_host Host name/IP address of the proxy to route agent data. Java, .Net
proxy_port Host port number of the proxy to route agent data. Java, .Net
tier_name

The Splunk AppDynamics tier name. This variable is mandatory for all the java

Apache, Java, Machine, Node.js, PHP, Python
windows_install_root Similar to linux_install_root , to be used on Windows hosts. The default value is C:/appdynamics . Apache, Java, Machine, Node.js, PHP, Python
windows_custom_agent_install_path Similar to linux_custom_agent_install_path , to be used on Windows hosts. Apache, Java, Machine, Node.js, PHP, Python

To get started, select your agent:

Apache Agent .Net Agent
Java Agent Node.js Agent
IIB Agent PHP Agent
Machine Agent Python Agent
Note: AnsibleĀ® is a registered trademark of Red Hat, Inc. in the United States and other countries.

Ansible Configuration for Apache Agent

The following is an example of AnsibleĀ® role to install Apache Agent:


---
- hosts: all
  tasks:
    - name: Include variables for the controller settings
      include_vars: vars/controller.yaml

    - include_role:
        name: appdynamics.agents.apache
      vars:
        agent_version: 22.12.1
        # possible value:
        #          - latest: Latest version
        #          - 22.12.1: Any Specific version number
        agent_type: apache
        agent_action: upgrade
        # possible value:
        #          - upgrade: upgrade currently installed agent to agent_version
        #          - install: install agent_version
        #          - rollback: rollback to previous backup if any
        #          - uninstall: uninstall and clean up everything

        # Apache specific Args
        #apache_conf_path:
        # possible value:
        #          - /etc/httpd/conf/httpd.conf #default path in case of RedHat
        #          - /etc/apache2/apache2.conf  #Default path in case of Debian
        #          - #any custom path where the conf file is located.

Apache Agent Variables

Note: The following variables are applicable to the appdynamics_agent.conf file. For more information, see Configure the Apache Agent.
Variable Description
appdynamics_enabled Set to ON to enable web server monitoring
appdynamics_proxy_host Proxy server hostname or IP address
appdynamics_proxy_port Proxy server port
appdynamics_launch_proxy When set to ON , the agent launches the proxy automatically when on startup. If OFF , you must launch the proxy.
appdynamics_resolve_backends Controls the way Apache module backends appear in the Controller UI.
appdynamics_trace_as_error If ON, trace points are written as errors to the Apache logs, by default error_log.
appdynamics_report_all_instrumented_modules If OFF , the agent reports only modules that occur during the HANDLER stage of Apache request processing.
appdynamics_backend_name_segments The number of URL segments that are displayed in the backend naming.
appdynamics_proxy_comm_dir

Path to the directory containing the domain control socket which the agent uses to start an Splunk AppDynamics node. The default value is <agent_install_directory>/logs/appd-sdk.

appdynamics_request_cache_cleanup_interval Timeout in milliseconds after which the request cache is cleaned up by Java proxy.
appdynamics_mask_cookie Specify if filtering is enabled or not. Set it ON for cookie filtering to be enabled. The default value is OFF.
appdynamics_mask_cookie_pattern Specify the pattern that when matched, filters the value of that cookie.
appdynamics_mask_sm_user Specify if filtering is enabled or not. Set it ON for sm_user filtering to be enabled. The default value is OFF.
appdynamics_delimiter Specify the character that you want to use as URL segment endpoints.
appdynamics_segment Specify a comma-separated list to indicate the segments that you want the agent to filter
appdynamics_match_filter The type of filter to be used to match the URL amongst the following: NOT_EMPTY
appdynamics_match_pattern Specify the string that you want to be filtered with the match-filter
custom_agent_config_path Specify the absolute path to the agent configuration file for future upgrades. Make sure that you add the agent configuration file path to the apache.conf file.

Ansible Configuration for Java Agent

The following sections provide the example use cases for the Java Agent Ansible roles:

Note: Ansible is supported on Windows only if the Controller is Linux and the nodes are Windows.

Install Java Agent on Linux or Windows

Example 1: AnsibleĀ® role used to install Java Agent on Windows or Linux without any application instrumentation:

---
- hosts: all
  tasks:
    - name: Include variables for the controller settings
      # Include all yaml files under the vars directory
      include_vars:
        dir: vars
        extensions:
          - 'yaml'
          - 'yml'
    - include_role:
        name: appdynamics.agents.java
      vars:
        agent_version: 21.1.0
        agent_type: java
        agent_action: upgrade # can be upgrade/install/rollback/uninstall, defaults to upgrade when unspecified
        application_name: "IoT_API" # agent default application
        tier_name: "java_tier" # agent default tier

Example 2: Ansible role for installing Java Agent with changing Java startup script and performing restart:

---
- hosts: single-java-host
  tasks:
    - name: Include variables for the controller settings
      # Include all yaml files under the vars directory
      include_vars:
        dir: vars
        extensions:
          - 'yaml'
          - 'yml'
    - import_role:
        name: appdynamics.agents.java
        public: yes
      vars:
        agent_version: 21.1.0
        agent_type: java
        application_name: "BIGFLY" # agent default application
        tier_name: "java_tier" # agent default tier
    - name: Edit startup script with new java startup variables
      lineinfile:
        path: /opt/application/startAll.sh
        # Line to Search/Match against
        regexp: '^(.*)(-jar.*$)'
        # Line to Replace with
        line: '\1 -javaagent:{{ java_agent_dest_folder_linux }}/javaagent.jar -Dappdynamics.agent.nodeName=application-1 \2'
        backup: yes
        backrefs: yes
        state: present
      notify: RestartingApp
    - name: Allow appuser write to appd logs folder
      user:
        name: appuser
        groups:
        - appdynamics
        append: yes
      become: yes
  handlers:
    - name: RestartingApp
      command: '/opt/application/stopAll.sh && /opt/application/startAll.sh'
      args: 
        chdir: '/opt/application/'
Note: AnsibleĀ® is a registered trademark of Red Hat, Inc. in the United States and other countries.

Instrument JBoss/Wildfly

The features of this role are:

  • Java Agent installation for Linux
  • Instrument Jboss/Wildfly
  • Automatic applications restart (if systemd service is present)
  • Java Agent start verification

Example 1: Install Java Agent and instrument one or more applications.

---
- hosts: all
tasks:
- name: Include variables for the controller settings
# Include all yaml files under the vars directory
include_vars:
dir: vars
extensions:
- 'yaml'
- 'yml'
- include_role:
name: appdynamics.agents.java
# use java role variables in the following instrumentation tasks when public: yes
public: yes
vars:
agent_version: 21.1.0
agent_type: java
- include_role:
name: appdynamics.agents.instrument_jboss
vars:
# instrument jboss:
application_name: "IoT_API2"
tier_name: "Jboss"
jboss_service: wildfly
app_user: wildfly
restart_app: yes
jboss_config: /opt/wildfly/bin/standalone.sh

Example 2: This role ensures that all instrumented applications have access to the Java Agent logs directory.

In some cases, when the application PID user is not local on the Linux host, it cannot be added to the Splunk AppDynamics group. In such a case, you can let the application user own the Java Agent directory instead.

---
- hosts: all
tasks:
- name: Include variables for the controller settings
# Include all yaml files under the vars directory
include_vars:
dir: vars
extensions:
- 'yaml'
- 'yml'
- include_role:
name: appdynamics.agents.java
# use java role variables in the following instrumentation tasks when public: yes
public: yes
vars:
agent_version: 21.1.0
agent_type: java
# single app mode: Can skip user creation and own java-agent directory by app user (wildfly in this case)
create_appdynamics_user: no
agent_dir_permission:
user:  wildfly
group: wildfly
- include_role:
name: appdynamics.agents.instrument_jboss
vars:
# instrument jboss:
application_name: "IoT_API2"
tier_name: "Jboss"
jboss_service: wildfly
app_user: wildfly
restart_app: yes
jboss_config: /opt/wildfly/bin/standalone.sh

JBoss Instrumentation Variables

VariableDescriptionRequiredDefault
app_user User that runs this application. It must be provided, so write permissions are given to the java-agent logs directoryYjboss
jboss_service Systemd service that should be restarted if restart_app is set to 'yes'N
restart_app Set to 'yes' to automatically restart instrumented serviceNno
backup Whether original config file should be backed up before any changesNFalse
jboss_config Jboss/Wildfly config to instrument. Provide a path to jboss standalone.shY/opt/wildfly/bin/standalone.sh

Instrument Apache Tomcat

The features of this role are:

  • Java Agent installation for Linux
  • Instrumentation of Apache Tomcat
  • Automatic applications restart (if systemd service is present)
  • Java Agent start verification

Example 1: Install Java Agent and instrument one or more applications.

---
- hosts: all
tasks:
- name: Include variables for the controller settings
# Include all yaml files under the vars directory
include_vars:
dir: vars
extensions:
- 'yaml'
- 'yml'
- include_role:
name: appdynamics.agents.java
# use java role variables in the following instrumentation tasks when public: yes
public: yes
vars:
agent_version: 21.1.0
agent_type: java
- include_role:
name: appdynamics.agents.instrument_tomcat
vars:
# instrument tomcat:
tomcat_service: tomcat9
application_name: "IoT_API22"
tier_name: "Tomcat"
app_user: tomcat
restart_app: yes
tomcat_config: /usr/share/tomcat9/bin/setenv.sh

Example 2: To ensure all instrumented applications have access to the Java Agent logs directory.

In some cases, when the application PID user is not local on the Linux host, it cannot be added to the Splunk AppDynamics group. In such a case, you can let the application user own the Java Agent directory instead.

---
- hosts: all
tasks:
- name: Include variables for the controller settings
# Include all yaml files under the vars directory
include_vars:
dir: vars
extensions:
- 'yaml'
- 'yml'
- include_role:
name: appdynamics.agents.java
# use java role variables in the following instrumentation tasks when public: yes
public: yes
vars:
agent_version: 21.1.0
agent_type: java
# single app mode: Can skip appdynamics user creation and own java-agent directory by app user (tomcat in this case)
create_appdynamics_user: no
agent_dir_permission:
user:  tomcat
group: tomcat
- include_role:
name: appdynamics.agents.instrument_tomcat
vars:
# instrument tomcat:
tomcat_service: tomcat9
application_name: "IoT_API22"
tier_name: "Tomcat"
app_user: tomcat
restart_app: yes
tomcat_config: /usr/share/tomcat9/bin/setenv.sh

Tomcat Instrumentation Variables

VariableDescriptionRequiredDefault
app_user The user that runs this application. It must be provided, so write permissions are given to the java-agent logs directoryYtomcat
tomcat_service Systemd service that should be restated if restart_app is set to 'yes'N
add_service_override

If enabled, adds systemd

Nyes
restart_app Set to 'yes' to automatically restart instrumented serviceNno
backup Whether the original config file should be backed up before any changesNno
tomcat_config Choose which tomcat configuration file to modify. You must set the full path to the setenv.sh file, for example, <CATALINA_HOME>/bin/setenv.sh . If Tomcat is installed with yum on RHEL distributions, this file is not invoked by the startup script. In that case, it can be set to /etc/tomcat/conf.d/appdynamics.conf instead.Y

Ansible Configuration for IIB Agent

The following is an example of AnsibleĀ® role to install IIB Agent on AIX or Red Hat-based Linux system.

---
- hosts: all
tasks:
- name: Include variables for the controller settings
include_vars:
# Include all yaml files under the vars directory
dir: vars
extensions:
- 'yaml'
- 'yml'
- include_role:
name: appdynamics.agents.iib
vars:
agent_version: latest
# possible value:
#          - latest: Latest version
#          - 22.10.0.5500.0: Any Specific version number
agent_type: iib
agent_action: upgrade
# possible value:
#          - upgrade: upgrade currently installed agent to  agent_version
#          - install: install agent_version
#          - rollback: rollback to previous backup if any

IIB Agent Variables

VariableDescriptionPossible ValuesRequiredDefault
iib_log_dir Path to the directory containing the IIB agent log files.directory pathOptional /tmp/appd
iib_user_exit The exit name of the user. This must be in the alphanumeric format, as provided in the mqsichangebroker command. ecom Optional None
iib_flow_level_visibility_enabled Set 1 to enable, and 0 to disable. See IIB Agent Flow Level Visibility.0, 1Optional 0
iib_node_reuse The node name reuse function enables users to reuse the node names of historical VMs for new VMs. It prevents the rapid increase of differently named nodes, especially when the nodes are identical processes that run over different times. This helps you monitor environments with short-life VMs. See Enable the Node Name Reuse.true or false Optional None
iib_node_reuse_prefix Use this property when iib-node-reuse is set to true . If you do not set this property, the agent generates node names as per the internal node name standards of IBM. See Enable the Node Name Reuse. ecom Optional None
config_file_path Use this property to set the path for node or server configuration files. You can specify multiple paths separated by a comma./opt/node1.conf.yaml, /opt/node2.conf.yaml Optional None
iib_controller_cert_file Full path to the PEM format X509 certificate for SSL. See Enable SSL for C/C++ SDK for more information on how to obtain the certificate file. /etc/controller/iib.pem Optional None
Note:

Custom Proxy Configuration Variables

VariableDescriptionPossible ValuesRequiredDefault
controller_proxy_host Host name or IP address of the proxy. It is required to connect the agent to the Controller. ecommerce.proxy.com Optional None
controller_proxy_port Proxy port to route data to the Controller through a proxy server. 8090 Optional None
controller_proxy_username Proxy username required to log in to proxy server host. ecommere-user Optional None
controller_proxy_password The password for authenticating the proxy user. /etc/ecommerce/passwd Optional None
controller_proxy_passwordfile The full path name of a file containing the password to authenticate the proxy user. /etc/ecommerce/passwd Optional None
Note: AnsibleĀ® is a registered trademark of Red Hat, Inc. in the United States and other countries.

Ansible Configuration for Machine Agent

The following is an example of AnsibleĀ® role to install Machine Agent on Linux, Windows, Solaris, and AIX:

---
- hosts: all
tasks:
- include_role:
name: appdynamics.agents.machine
vars:
# Define Agent Type and Version
agent_version: 20.9.0
agent_type: machine
machine_hierarchy: "AppName|Owners|Environment|" # Make sure it ends with a |
sim_enabled: "true"
# Analytics settings
analytics_event_endpoint: "https://fra-ana-api.saas.appdynamics.com:443"
enable_analytics_agent: "true"
# Your controller details
controller_account_access_key: "123key" # Please add this to your Vault
controller_host_name: "fieldlab.saas.appdynamics.com" # Your Splunk AppDynamics controller
controller_account_name: "customer1" # Please add this to your Vault
enable_ssl: "false"
controller_port: "8090"
controller_global_analytics_account_name: 'customer1_e52eb4e7-25d2-41c4-a5bc-9685502317f2' # Please add this to your Vault
# config properties docs - https://docs.appdynamics.com/display/latest/Machine+Agent+Configuration+Properties
# Can be used to configure the proxy for the agent
java_system_properties: "-Dappdynamics.http.proxyHost=10.0.4.2 -Dappdynamics.http.proxyPort=9090" # mind the space between each property
Note: In Linux and Windows, the Ansible role starts and runs the Machine agent as a service during installation, upgrade, and rollback. In Solaris and AIX, the Ansible role will install, upgrade, and roll back the machine agent. However, you must start the Machine agent manually.

Machine Agent Variables

VariableDescription
java_system_properties To configure proxy settings for agents
analytics_event_endpoint Specify Events Service URL in this variable
enable_analytics_agent To enable Analytics Agent for the Machine Agent
sim_enabled Enable server infrastructure monitoring
controller_global_analytics _account_name Global account name of the Controller
Note: AnsibleĀ® is a registered trademark of Red Hat, Inc. in the United States and other countries.

Ansible Configuration for .Net Agent MSI

Note: This document contains references to the AnsibleĀ® documentation. Splunk AppDynamics does not own any rights and assumes no responsibility for the accuracy or completeness of such third-party documentation.

The following sections provide the example use cases for the .Net Agent MSI Ansible role.

Note:
  1. Agent upgrade using this Ansible role does not retain the previous .Net Agent MSI configurations. It overrides the existing configuration with the configuration you specify in the role. If configuration details are not specified in the role, a default minimal configuration is used. Ensure that you back up all important configurations before running this role.

  2. .Net Agent MSI rollback is not supported in the following scenarios:

    1. If .Net Agent MSI was never installed on the machine or the previous .Net Agent MSI installation is not managed by this role.

    2. If the rollback is already performed. Rollback to only one previous version is supported.

Install .Net Agent MSI

Example 1: AnsibleĀ® role used to install .Net Agent MSI with the following basic features:

  • Installs the latest .Net Agent
  • Auto generates the Controller application name
  • Instruments all IIS applications. You must restart IIS after installation.
Note: In this playbook, the parameters to communicate with the Controller are included from vars/args.yaml.
---
- name: .Net Agent MSI Minimal Configuration
hosts: windows
tasks:
- name: Include variables for the controller settings
# Include all yaml files under the vars directory
ansible.builtin.include_vars:
dir: vars
extensions:
- 'yaml'
- 'yml'
- ansible.builtin.include_role:
name: appdynamics.agents.dotnet_msi

Example 2: Ansible role used to install .Net Agent MSI with the following extended features:

  • Installs the .Net Agent version 22.12.0.
  • Defines a specific Controller application name. You specify a controller application name that the role utilizes during configuration.
  • Instruments only specific IIS applications with or without default tier and node names. You must restart IIS after installation.
  • Instrument standalone applications with or without default tier and node names. You must restart the standalone applications after installation.
Note: In the below playbooks, the parameters to communicate with the controller are defined in the playbook.
---
- name: .Net Agent MSI Extended Configuration
hosts: windows
tasks:
- ansible.builtin.include_role:
name: appdynamics.agents.dotnet_msi
vars:
agent_version: '22.12.0'
# Your controller details
controller_host_name: 'something.saas.appdynamics.com'
controller_port: '443'
enable_ssl: 'true'
controller_account_name: 'customer1'
controller_account_access_key: '123456'
application_name: 'DotNetAgent_Application'
monitor_all_IIS_apps: 'false'
iis_applications:
# instrument a web application 'PaymentService' under a web site 'Default Web Site'
- site: 'Default Web Site'
path: '/PaymentService'
# default tier: 'site/path'
# default node: 'host-tier'
# instrument an entire web site 'BillingWebSite'
- site: 'BillingWebSite'
tier_name: 'BillingWebSiteTier'
node_name: 'BillingWebSiteNode'
standalone_applications:
# instrument any execution of a standalone aplication 'login.exe'
- executable: 'login.exe'
# default tier: 'executable'
# default node: 'host-tier'
# instrument a standalone aplication 'checker.exe' with a specific set of command line arguments
- executable: 'checker.exe'
command_line: '-arg1 value1 -flag1'
tier_name: 'CheckerTier'
node_name: 'CheckedNode'

.Net Agent Variables

VariableDescriptionPossible ValuesRequiredDefault
custom_ad_setup_file Defines a local path to the custom installation configuration file on the Ansible control node. It can be a static file or a dynamic Jinja template.System pathN
custom_config Defines a local path to the custom config.xml static file on the Ansible controlling node. It takes precedence over other configuration settings.System pathN
enable_tls12 Enable Controller SSL TLS1.2 connection.[true, false]N false
iis_applications List of IIS applications to monitor. It can be useful if monitor_all_IIS_apps = false or custom tier and node names are required for an application. See .NET Agent Configuration Properties.N
iis_application.site Name of the IIS website.Y (for each IIS application if iis_applications is defined)
iis_application.path Path to the IIS web application relative to the IIS website. The path must begin with '/'. If the path is missing the default value '/' indicates that all applications under the website are instrumented.N'/'
iis_application.tier_name Controller Tier Name for the IIS application.Niis_application.site/iis_application.path (if the path is defined or iis_application.site
iis_application.node_name Controller Node Name for the IIS application.N hostname-iis_application.tier_name
monitor_all_IIS_apps Enable monitoring of all IIS applications.[true, false]N true
restart_app

Set to true

Note: All the applications added or removed from instrumentation must be restarted for agent changes to take effect.
[true, false]N false
standalone_applications List of .Net standalone applications to monitor. See .NET Agent Configuration Properties.N
standalone_application.executable Name of the executable file for the standalone application (with or without extension).Y (for each standalone application if standalone_applications is defined)
standalone_application.command_line Command line arguments for the executable to limit the monitoring to a specific execution of the application.N
standalone_application.tier_name Controller Tier Name for standalone application.N standalone_application.executable
standalone_application.node_name Controller Node Name for standalone application.N hostname-standalone_application.tier_name
Note: This document contains references to the Ansible documentation. Splunk AppDynamics does not own any rights and assumes no responsibility for the accuracy or completeness of such third-party documentation.

Set .Net Agent MSI Environment Variables

You can use the ansible.windows.win_environment Ansible module to set .Net Agent MSI environment variables. The following example defines the APPDYNAMICS_AGENT_UNIQUE_HOST_ID environment variable on the system where the Agent will be installed. For more information, see Modify environment variables on Windows hosts.

---
- name: .Net Agent MSI Test Play
hosts: windows
tasks:
- name: Include variables for the controller settings
# Include all yaml files under the vars directory
ansible.builtin.include_vars:
dir: vars
extensions:
- 'yaml'
- 'yml'
- ansible.windows.win_environment:
state: present
name: 'APPDYNAMICS_AGENT_UNIQUE_HOST_ID'
value: '{{ ansible_hostname }}' # can be jinja template like in this example or a static `value` if needed
level: machine
- ansible.builtin.include_role:
name: appdynamics.agents.dotnet_msi

Install and Upgrade .Net Agent MSI on a Certain Tier/Node

.Net Agent MSI performs a global machine-wise installation. You can not install different versions of the agent on the machine. Also, all applications on a machine are instrumented using the same version of the agent

To update the Agent on a specific Windows machine, create the Ansible inventory file and run the playbook on the desired hosts. For more information, see How to build your inventory.

---
      # updating agent version on certain windows machines only
      - name: .Net Agent MSI Test Play
      hosts: windows_region_1 # a group 'windows_region_1' should be defined in ansible inventory and lisy all desired machines
      tasks:
      - ansible.builtin.include_role:
      name: appdynamics.agents.dotnet_msi
      vars:
      agent_version: '22.12.0' # or providing custom_config or any other changes to the configuration

To update the list of instrumented applications within a machine, add or remove the desired application from the role configuration and rerun the playbook.

Note: AnsibleĀ® is a registered trademark of Red Hat, Inc. in the United States and other countries.

Ansible Configuration for Node.js Agent

Note:
  • Ensure that you are using Node.js version 14.x-18.x.

  • Ensure that you restart the agent after installation.

The following is an example of an AnsibleĀ® role to install Node.js Agent on Linux:

---
- hosts: linux
tasks:
- include_role:
name: appdynamics.agents.node
vars:
agent_version: latest # [latest or provide the specific agent version]
agent_type: node
agent_action: upgrade # can be upgrade/install/rollback, default upgrade when unspecified
controller_account_access_key: "123key" # Please add this to your Vault
controller_host_name: "fieldlab.saas.appdynamics.com" # Your Splunk AppDynamics controller
controller_account_name: "customer1" # Please add this to your Vault
enable_ssl: "false"
controller_port: "8090"

Ensure that you restart the agent after installation using the following command:

node -r appd-config.js app.js

Node.js Agent Variables

VariableDescriptionDefaultPossible ValuesRequired
agent_version Node.js agent version to be installed.latestlatest, [agent version in x.x.x.x format]No
node_agent_enableGraphQL Use this if your application uses graphql.falsetrue, falseNo
node_agent_debug_logging To run the application with debug logging enabled.falsetrue, falseNo
npm_registry To run the application in debug mode. https://registry.npmjs.org No
Note: AnsibleĀ® is a registered trademark of Red Hat, Inc. in the United States and other countries.

Ansible Configuration for PHP Agent

The following sections provide the example use cases for the PHP Agent Ansible Role:

Example 1: The following is an example of AnsibleĀ® role to install PHP Agent on Linux:

---
- hosts: all
tasks:
- include_role:
name: appdynamics.agents.php
vars:
agent_version: latest
agent_type: php
agent_action: upgrade
application_name: e-commerce
controller_account_access_key: "123key"
controller_host_name: "fieldlab.saas.appdynamics.com"
controller_account_name: "customer1"
enable_ssl: false
controller_port: 8090
tier_name: tier1
node_name: node1
log_directory: "/opt/appdynamics/php-agent/ecommerce_logs"
zts_support: false
# proxy configs
proxy_host: master.ecommerce-proxy.com
proxy_port: 8080
proxy_user: ecommerce-user
proxy_password_file: /etc/ecommerce/passwd
proxy_ctrl_dir: /ecommerce/proxy_dir/

Example 2: The following is an example of Ansible role to upgrade PHP Agent on Linux where agent is already installed:

---
- hosts: all
tasks:
- include_role:
name: appdynamics.agents.php
vars:
agent_version: latest
agent_type: php
agent_action: upgrade
application_name: e-commerce
controller_account_access_key: "123key"
controller_host_name: "fieldlab.saas.appdynamics.com"
controller_account_name: "customer1"
enable_ssl: false
controller_port: 8090
tier_name: tier1
node_name: node1
log_directory: "/opt/appdynamics/php-agent/ecommerce_logs"
zts_support: false
linux_custom_agent_install_path: "/home/ubuntu/ecommerce_agent/" #this path should contain the agent files (eg: install.sh ,php etc)
custom_agent_ini_file: "/etc/php/7.4/cli/conf.d/appdynamics_agent.ini" #this file should contain your agent controller details

PHP Agent Variables

VariableDescriptionPossible ValuesRequiredDefault
custom_agent_ini_file Set the absolute path of the appdynamics_agent.ini file.<custom path>

By default, it takes the default .ini file path set in PHP settings

Yes, if linux_custom_agent_install_path is defined None
enable_cli Set to true if you want to enable the CLI mode.true or false Optional None
enable_cli_long_running Set to true to defend PHP in long-running CLI applications. See Configure the Agent for PHP CLI Applications.true or false Optional false
ignore_permissions Set to true if you want to ignore file and directory permission issues.true or false Optional None
log_directory Specify your logs directory. By default, logs folder is created inside agent directory. <agent-directory>/logs Optional <agent-directory>/logs
php_executable_path Specify the path for the PHP binary. /usr/bin/php Optional global php path set
php_ini_dir Directory for the appdynamics_agent.ini file. /etc/php/ Required on Ubuntu and when the default PHP CLI binary cannot be determined. global php ini path set
php_extension_dir Extensions directory for the appdynamics_agent.so file. /etc/php/extensions/ Required on Ubuntu and when the default PHP CLI binary cannot be determined. global php extension path set
php_version Version of PHP that you are instrumenting. Valid formats are version numbers to one or two decimal positions, for example, 7.4 and 7.4.29. 7.4.29 Required when the default PHP CLI binary cannot be determined or there is no PHP CLI binary. global php verdsion set
zts_support Set to true to install PHP ZTS agent.true or false Optional false
Note:
  1. Use the php -i|grep appdynamics_agent.ini command to get the appdynamics_agent.ini path. Set the custom_agent_ini_file with the absolute file path if your agent in not installed in default location or if you are using linux_custom_agent_install_path.
  2. If you want to install agent in PHP version which is not set globally, you must define the following variables. These are mandatory variables for all agent_action:
    • php_executable_path
    • php_ini_dir
    • php_extension_dir
    • php_version

Custom Proxy Configuration Variables

VariableDescriptionPossible ValuesRequiredDefault
proxy_host Proxy host to route data to the Controller through a proxy server. master.ecommerce-proxy.com Optional None
proxy_port Proxy port to route data to the Controller through a proxy server. 8090 Optional None
proxy_user Proxy user required to log in to proxy server host. ecommere-user Optional None
proxy_password_file Proxy password file to log in to proxy server host. /etc/ecommerce/passwd Optional None
proxy_ctrl_dir The proxy control directory. If not specified, the installer creates a temporary directory. /ecommerce/proxy_dir/ Optional None
Note: AnsibleĀ® is a registered trademark of Red Hat, Inc. in the United States and other countries.

Ansible Configuration for Python Agent

The following sections provide the example use cases for the Python Agent Playbook:

Install Python Agent

Example 1: AnsibleĀ® role used to install Python Agent with the following features:

  • Installs Python Agent on Linux (Debian, Alpine, and RedHat).
  • Creates a backup if existing installation is detected.
---
- hosts: all
tasks:
- name: Include variables for the controller settings
# Include all yaml files under the vars directory
include_vars:
dir: vars
extensions:
- 'yaml'
- 'yml'
- include_role:
name: appdynamics.agents.python
vars:
agent_version: 22.10.0.5500.0
# possible value:
#          - latest: Latest version
#          - 22.10.0.5500.0: Any Specific version number
agent_type: python
agent_action: upgrade
# possible value:
#          - upgrade: upgrade currently installed agent to agent_version
#          - install: install agent_version
#          - rollback: rollback to previous backup if any
#          - uninstall: uninstall agent
# Python specific Args
install_env: default # [default - (main python path taken automatically), virtualenv - (virtualenv path need to be provided)]
# possible value:
#          - default: install agent in global python
#          - virtualenv: install agent  to specific virtualenv
virtualenv_path: /home/ansible/venv
# possible value:
#          - /home/ansible/venv: virtualenv path
#          - None
install_agent_from: appd-portal
# possible value:
#          - pypi: Downlaod agent from PYPI
#          - appd-portal: Download agent from AppD portal

Example 2: Ansible role to start a sample application with Python Agent:

---
- hosts: all
tasks:
- name: Include variables for the controller settings
# Include all yaml files under the vars directory
include_vars:
dir: vars
extensions:
- 'yaml'
- 'yml'
- include_role:
name: appdynamics.agents.python
- name: Start Sample Python app
shell: "nohup pyagent run -c /opt/appdynamics/python-agent/appd.cfg python3 /home/ubuntu/app.py &"
async: 100
poll: 0
register: status
failed_when: "'FAILED' in status.stdout"
Config path and the application path has to be changed accordingly.