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.
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
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:
|
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
|
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 |
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
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:
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/'
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
Variable | Description | Required | Default |
---|---|---|---|
app_user
| User that runs this application. It must be provided, so write permissions are given to the java-agent logs directory | Y | jboss |
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 service | N | no |
backup
| Whether original config file should be backed up before any changes | N | False |
jboss_config
| Jboss/Wildfly config to instrument. Provide a path to jboss standalone.sh | Y | /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
Variable | Description | Required | Default |
---|---|---|---|
app_user
| The user that runs this application. It must be provided, so write permissions are given to the java-agent logs directory | Y | tomcat |
tomcat_service
| Systemd service that should be restated if restart_app is set
to 'yes' | N | |
add_service_override
|
If enabled, adds systemd | N | yes |
restart_app
| Set to 'yes' to automatically restart instrumented service | N | no |
backup
| Whether the original config file should be backed up before any changes | N | no |
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
Variable | Description | Possible Values | Required | Default |
---|---|---|---|---|
iib_log_dir
| Path to the directory containing the IIB agent log files. | directory path | Optional |
/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, 1 | Optional |
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
|
For IIB Agent configurations, see Install the IIB Agent.
- Note: Set the necessary variable for Controller in the
controller-info.xml
file. See Common Role Variables.
Custom Proxy Configuration Variables
Variable | Description | Possible Values | Required | Default |
---|---|---|---|---|
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
|
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
Machine Agent Variables
Variable | Description |
---|---|
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 |
Ansible Configuration for .Net Agent MSI
The following sections provide the example use cases for the .Net Agent MSI Ansible role.
-
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.
-
.Net Agent MSI rollback is not supported in the following scenarios:
-
If .Net Agent MSI was never installed on the machine or the previous .Net Agent MSI installation is not managed by this role.
-
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.
---
- 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.
---
- 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
Variable | Description | Possible Values | Required | Default |
---|---|---|---|---|
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 path | N | |
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 path | N | |
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. | N | iis_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
|
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.
Ansible Configuration for Node.js Agent
-
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
Variable | Description | Default | Possible Values | Required |
---|---|---|---|---|
agent_version
| Node.js agent version to be installed. | latest | latest, [agent version in x.x.x.x format] | No |
node_agent_enableGraphQL
| Use this if your application uses graphql. | false | true, false | No |
node_agent_debug_logging
| To run the application with debug logging enabled. | false | true, false | No |
npm_registry
| To run the application in debug mode. | https://registry.npmjs.org | No |
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
Variable | Description | Possible Values | Required | Default |
---|---|---|---|---|
custom_agent_ini_file
| Set the absolute path of the appdynamics_agent.ini
file. | <custom path> By default, it takes the default | 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
|
- 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 usinglinux_custom_agent_install_path
. - 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
Variable | Description | Possible Values | Required | Default |
---|---|---|---|---|
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
|
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.