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, 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 |
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, 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 |
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 |
Apache エージェントの Ansible 設定
以下は、Apache エージェントをインストールするための Ansible® ロールの例です。®
---
- 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 エージェントの変数
| 変数 | 説明 |
|---|---|
appdynamics_enabled |
に設定すると、Web サーバーモニタリングが有効になります。 |
appdynamics_proxy_host |
プロキシサーバーのホスト名または IP アドレス |
appdynamics_proxy_port |
プロキシ サーバ ポート(Proxy server port) |
appdynamics_launch_proxy |
ON に設定すると、エージェントは起動時に自動でプロキシを開始します。OFF にすると、プロキシを開始する必要があります。 |
appdynamics_resolve_backends |
Apache モジュールバックエンドがコントローラ UI に表示される方法を制御します。 |
appdynamics_trace_as_error |
ON にすると、トレースポイントがエラーとして Apache ログ(デフォルトでは error_log)に書き込まれます。 |
appdynamics_report_all_instrumented_modules |
OFF にすると、エージェントは Apache 要求処理の HANDLER 段階で実行されるモジュールのみを報告します。 |
appdynamics_backend_name_segments |
バックエンドの命名で表示される URL セグメントの数。 |
appdynamics_proxy_comm_dir |
エージェントが Splunk AppDynamics ノードを起動するために使用するドメイン制御ソケットを含むディレクトリへのパス。デフォルトは、<agent_install_directory>/logs/appd-sdk です。 |
appdynamics_request_cache_cleanup_interval |
要求キャッシュが Java プロキシによってクリーンアップされるまでのタイムアウト(ミリ秒)。 |
appdynamics_mask_cookie |
フィルタリングを有効にするかどうかを指定します。Cookie フィルタリングを有効にするには、ON に設定します。デフォルト値は OFF です。 |
appdynamics_mask_cookie_pattern |
一致したときにその Cookie の値をフィルタ処理するパターンを指定します。 |
appdynamics_mask_sm_user |
フィルタリングを有効にするかどうかを指定します。sm_user フィルタリングを有効にするには、ON に設定します。デフォルト値は OFF です。 |
appdynamics_delimiter |
URL セグメントのエンドポイントとして使用する文字を指定します。 |
appdynamics_segment |
エージェントがフィルタ処理するセグメントを指定するには、カンマ区切りのリストを指定します。 |
appdynamics_match_filter |
URL を NOT_EMPTY と照合するために使用されるフィルタのタイプです。 |
appdynamics_match_pattern |
照合フィルタでフィルタ処理する文字列を指定します。 |
custom_agent_config_path |
将来のアップグレードのために、エージェント構成ファイルへの絶対パスを指定します。エージェント構成ファイルのパスを ファイルに追加してください。 |
Java エージェントの Ansible 設定
次の項では、Java エージェントの Ansible ロールの使用例を示します。
Linux または Windows 上での Java エージェントのインストール
:アプリケーションのインストルメント化なしで Windows や Linux に Java エージェントをインストールする際に使用される Ansible® ロール。®
---
- 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
:Java エージェントをインストールするとともに、Java 起動スクリプトを変更し、再起動を行う際に使用される Ansible ロール。
---
- 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/'
JBoss/Wildfly のインストゥルメント化
このロールの特徴は次のとおりです。
- Linux の Java エージェントのインストール
- Jboss/Wildfly のインストゥルメント化
- アプリケーションの自動再起動(
systemdサービスが存在する場合) - Java エージェントの起動検証
例 1:Java エージェントをインストールし、1 つ以上のアプリケーションをインストルメント化します。
---
- 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
例 2:このロールがあると、インストルメント化されたすべてのアプリケーションが Java エージェントログのディレクトリにアクセスできるようになります。
場合によっては、アプリケーション PID ユーザーが Linux ホストでローカルでないことがあります。この場合、Splunk AppDynamics グループに追加できません。このような場合、代わりにアプリケーションユーザーに Java エージェントディレクトリを所有させることができます。
---
- 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 インストルメンテーションの変数
| 変数 | 説明 | 必須 | デフォルト |
|---|---|---|---|
app_user | このアプリケーションを実行するユーザー。これを指定する必要があるため、java-agent ログディレクトリへの書き込み権限が付与されます。 | Y | jboss |
jboss_service | restart_app が「yes」に設定されている場合に再起動する必要がある Systemd サービス | N | |
restart_app | インストゥルメント化されたサービスを自動的に再起動するには、'yes' に設定します。 | N | いいえ |
backup | 変更前に元の構成ファイルをバックアップするかどうかです。 | N | いいえ |
jboss_config | インストゥルメント化する Jboss/Wildfly 設定。jboss standalone.sh へのパスを指定します。 | Y | /opt/wildfly/bin/standalone.sh |
Apache Tomcatのインストゥルメント化
このロールの特徴は次のとおりです。
- Linux の Java エージェントのインストール
- Apache Tomcat のインストルメンテーション
- アプリケーションの自動再起動(
systemdサービスが存在する場合) - Java エージェントの起動検証
例 1:Java エージェントをインストールし、1 つ以上のアプリケーションをインストルメント化します。
---
- 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
例 2:インストルメント化されたすべてのアプリケーションが Java エージェントログのディレクトリにアクセスできるようになります。
場合によっては、アプリケーション PID ユーザーが Linux ホストでローカルでないことがあります。この場合、Splunk AppDynamics グループに追加できません。このような場合、代わりにアプリケーションユーザーに Java エージェントディレクトリを所有させることができます。
---
- 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 インストルメンテーションの変数
| 変数 | 説明 | 必須 | デフォルト |
|---|---|---|---|
app_user | このアプリケーションを実行するユーザー。これを指定する必要があるため、java-agent ログディレクトリへの書き込み権限が付与されます。 | Y | tomcat |
tomcat_service | restart_app が「yes」に設定されている場合に再起動する必要がある Systemd サービス | N | |
add_service_override |
有効になっている場合、systemd を追加 | N | 〇 |
restart_app | インストゥルメント化されたサービスを自動的に再起動するには、'yes' に設定します。 | N | いいえ |
backup | 変更前に元の構成ファイルをバックアップするかどうかです。 | N | いいえ |
tomcat_config | 変更する tomcat 構成ファイルを選択します。setenv.sh ファイルへのフルパスを設定する必要があります(例:<CATALINA_HOME>/bin/setenv.sh)。RHEL ディストリビューションで Tomcat が yum とともにインストールされている場合、このファイルはスタートアップスクリプトによって呼び出されません。その場合は、代わりに /etc/tomcat/conf.d/appdynamics.conf に設定できます。 | Y |
IIB エージェントの Ansible 設定
次は、AIX または Redhat ベースの Linux システムに IIB エージェントをインストールするための Ansible® ロールの例です。®
---
- 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 エージェント変数
| 変数 | 説明 | 使用可能な値 | 必須 | デフォルト |
|---|---|---|---|---|
iib_log_dir | IIB エージェントログファイルを含むディレクトリへのパス。 | ディレクトリパス | オプション | /tmp/appd |
iib_user_exit | ユーザーの exit 名。これは、mqsichangebroker コマンドの規定に従い英数字の形式にする必要があります。 | ecom | オプション | None |
iib_flow_level_visibility_enabled | 有効にするには 1、無効にするには 0 を設定します。IIB エージェントフローレベルの可視性 を参照してください。 | 0、1 | オプション | 0 |
iib_node_reuse | ノード名の再利用機能により、ユーザーは過去の VM のノード名を新しい VM に再利用できます。特にノードが異なる時間に実行される同一のプロセスである場合に、異なる名前のノードが急速に増加することがなくなります。これは、寿命の短い VM がある環境をモニターするのに役立ちます。ノード名の再利用の有効化 を参照してください。 | true または false | オプション | None |
iib_node_reuse_prefix | iib-node-reuse が true に設定されている場合に、このプロパティを使用します。このプロパティを設定しない場合、エージェントは、IBM の内部ノード名標準に従ってノード名を生成します。ノード名の再利用の有効化 を参照してください。 | ecom | オプション | None |
config_file_path | このプロパティを使用して、ノードまたはサーバーの構成ファイルのパスを設定します。複数のパスをカンマで区切って指定できます。 | /opt/node1.conf.yaml、 /opt/node2.conf.yaml | オプション | None |
iib_controller_cert_file | SSL の PEM 形式の X509 証明書へのフルパス。証明書ファイルの取得方法については、C/C++ SDK の SSL の有効化を参照してください。 | /etc/controller/iib.pem | オプション | None |
IIB エージェントの構成については、「IIB エージェントのインストール」を参照してください。
カスタムプロキシ設定の変数
| 変数 | 説明 | 使用可能な値 | 必須 | デフォルト |
|---|---|---|---|---|
controller_proxy_host | プロキシのホスト名または IP アドレス。エージェントをコントローラに接続するのに必要です。 | ecommerce.proxy.com | オプション | None |
controller_proxy_port | プロキシサーバーを通じてコントローラにデータをルーティングするためのプロキシポート。 | 8090 | オプション | None |
controller_proxy_username | プロキシサーバーホストにログインするために必要なプロキシユーザー名。 | ecommere-user | オプション | None |
controller_proxy_password | プロキシユーザーを認証するためのパスワード。 | /etc/ecommerce/passwd | オプション | None |
controller_proxy_passwordfile | プロキシユーザーの認証に使用されるパスワードを含むファイルのフルパス名。 | /etc/ecommerce/passwd | オプション | None |
マシンエージェントの Ansible 設定
以下は、Linux、Windows、Solaris、および AIX にマシンエージェントをインストールするための Ansible® ロールの例です。®
---
- 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
マシンエージェントの変数
| 変数 | 説明 |
|---|---|
java_system_properties | エージェントのプロキシ設定を設定します。 |
analytics_event_endpoint | この変数にイベントサービスの URL を指定します。 |
enable_analytics_agent | マシンエージェントの分析エージェントを有効にします。 |
sim_enabled | サーバー インフラストラクチャ モニタリングを有効にします。 |
controller_global_analytics _account_name | コントローラのグローバルアカウント名 |
.Net エージェント MSI の Ansible 設定
次の項では、.Net エージェント MSI の Ansible ロールの使用例を示します。
-
この Ansible ロールを使用したエージェントのアップグレードでは、以前の .Net エージェント MSI の設定は保持されません。ロールで指定した設定で既存の設定が上書きされます。ロールで設定の詳細が指定されていない場合、デフォルトの最小限の設定が使用されます。このロールを実行する前に、すべての重要な設定をバックアップしたことを確認してください。
-
.Net エージェント MSI のロールバックは、次のシナリオではサポートされていません。
-
.Net エージェント MSI がマシンにインストールされていないか、前の .Net エージェント MSI のインストールがこのロールによって管理されていない場合
-
ロールバックがすでに実行されている場合。1 つ前のバージョンへのロールバックのみがサポートされています
-
.Net エージェント MSI のインストール
:以下の基本機能を備えた .Net エージェント MSI のインストールに使用される Ansible® ロール:®
- 最新の .Net エージェントのインストール
- コントローラ アプリケーション名の自動生成
- すべての IIS アプリケーションのインストゥルメント化。インストール後に IIS を再起動する必要があります。
---
- 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
:以下の拡張機能を備えた .Net エージェント MSI のインストールに使用される Ansible ロール:
- .Net エージェントバージョン 22.12.0 のインストール
- 特定のコントローラ アプリケーション名の定義。設定時にロールで使用されるコントローラ アプリケーション名を指定します。
- デフォルトの階層名とノード名の有無にかかわらない、特定の IIS アプリケーションのみのインストゥルメント化。インストール後に IIS を再起動する必要があります。
- デフォルトの階層名とノード名の有無にかかわらない、スタンドアロン アプリケーションのインストゥルメント化。インストール後にスタンドアロン アプリケーションを再起動する必要があります。
---
- 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 エージェントの変数
| 変数 | 説明 | 使用可能な値 | 必須 | デフォルト |
|---|---|---|---|---|
custom_ad_setup_file | Ansible 制御ノード上のカスタムインストール構成ファイルへのローカルパスを定義します。静的ファイルまたは動的 Jinja テンプレートを使用することができます。 | システムパス | N | |
custom_config | Ansible 制御ノード上のカスタム config.xml 静的ファイルへのローカルパスを定義します。他の設定よりも優先されます。 | システムパス | N | |
enable_tls12 | コントローラ SSL TLS1.2 接続を有効にします。 | [true、false] | N | false |
iis_applications | モニターする IIS アプリケーションのリスト。これは、アプリケーションに monitor_all_IIS_apps = false またはカスタムの階層とノード名が必要な場合に役立ちます。「.NET エージェントの構成プロパティ」を参照してください。 | N | ||
iis_application.site | IIS Web サイトの名前。 | Y(iis_applications が定義されている場合は IIS アプリケーションごと) | ||
iis_application.path | IIS Web サイトに関連する IIS Web アプリケーションへのパス。パスの先頭には必ず '/' を付けます。パスがない場合、デフォルト値の '/' は、Web サイトの下のすべてのアプリケーションがインストゥルメント化されていることを示します。 | N | '/' | |
iis_application.tier_name | IIS アプリケーションのコントローラ階層名。 | N | iis_application.site/iis_application.path (パスが定義されているか、iis_application.site である場合) | |
iis_application.node_name | IIS アプリケーションのコントローラノード名。 | N | hostname-iis_application.tier_name | |
monitor_all_IIS_apps | すべての IIS アプリケーションのモニタリングを有効にします。 | [true、false] | N | true |
restart_app |
true に設定 注: エージェントの変更を有効にするには、インストゥルメンテーションで追加または削除されたすべてのアプリケーションを再起動する必要があります。
| [true、false] | N | false |
standalone_applications | モニターする .Net スタンドアロン アプリケーションのリスト。「.NET エージェントの構成プロパティ」を参照してください。 | N | ||
Standalone_application.executable | スタンドアロン アプリケーションの実行ファイルの名前(拡張子付きまたは拡張子なし)。 | Y(standalone_applications が定義されている場合はスタンドアロン アプリケーションごと) | ||
standalone_application.command_line | モニタリングをアプリケーションの特定の実行に制限する実行ファイルのコマンドライン引数。 | N | ||
standalone_application.tier_name | スタンドアロン アプリケーションのコントローラ階層名。 | N | standalone_application.executable | |
standalone_application.node_name | スタンドアロン アプリケーションのコントローラノード名。 | N | hostname-standalone_application.tier_name |
.Net エージェント MSI の環境変数の設定
ansible.windows.win_environment Ansible モジュールを使用して、.Net エージェント MSI の環境変数を設定できます。次の例では、エージェントがインストールされるシステムで APPDYNAMICS_AGENT_UNIQUE_HOST_ID 環境変数を定義します。詳細については、「Windows ホストでの環境変数の変更」を参照してください。
---
- 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
特定の階層/ノードでの .Net エージェント MSI のインストールおよびアップグレード
.Net エージェント MSI は、グローバルなマシンでのインストールを実行します。マシンに異なるバージョンのエージェントをインストールすることはできません。また、マシン上のすべてのアプリケーションは、同じバージョンのエージェントを使用してインストゥルメント化されます
特定の Windows マシンでエージェントを更新するには、Ansible インベントリファイルを作成し、目的のホストでプレイブックを実行します。詳細については、「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マシン内のインストゥルメント化されたアプリケーションのリストを更新するには、ロール設定で目的のアプリケーションを追加または削除して、プレイブックを再実行します。
Node.js エージェントの Ansible 設定
-
Node.js バージョン 14.x ~ 18.x を使用していることを確認します。
-
インストール後にエージェントを再起動してください。
以下は、Linux に Node.js エージェントをインストールするための Ansible® ロールの例です。®
---
- 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"
次のコマンドを使用して、インストール後にエージェントを再起動してください。
node -r appd-config.js app.js
Node.js エージェントの変数
| 変数 | 説明 | デフォルト | 使用可能な値 | 必須 |
|---|---|---|---|---|
agent_version | インストールする Node.js エージェントのバージョン。 | latest | latest、[x.x.x.x 形式のエージェントバージョン] | いいえ |
node_agent_enableGraphQL | アプリケーションで graphql が使用されている場合は、これを使用します。 | false | true、false | いいえ |
node_agent_debug_logging | デバッグロギングを有効にしてアプリケーションを実行します。 | false | true、false | いいえ |
npm_registry | アプリケーションをデバッグモードで実行します。 | https://registry.npmjs.org | いいえ |
PHP エージェントの Ansible 設定
次の項では、PHP エージェントの Ansible ロールの使用例を示します。
以下は、Linux に PHP エージェントをインストールするための Ansible® ロールの例です。®
---
- 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/
以下は、エージェントがすでにインストールされている Linux で PHP エージェントをアップグレードするための Ansible ロールの例です。
---
- 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 エージェントの変数
| 変数 | 説明 | 使用可能な値 | 必須 | デフォルト |
|---|---|---|---|---|
custom_agent_ini_file | appdynamics_agent.ini ファイルの絶対パスを設定します。 | <custom path> デフォルトでは、PHP 設定で設定されたデフォルトの | はい(linux_custom_agent_install_path が定義されている場合) | None |
enable_cli | CLI モードを有効にする場合は、true に設定します。 | true または false | オプション | None |
enable_cli_long_running | true に設定すると、長期実行 CLI アプリケーションで PHP を保護します。「PHP CLI アプリケーション用エージェントの構成」を参照してください。 | true または false | オプション | false |
ignore_permissions | ファイルとディレクトリの権限の問題を無視する場合は、true に設定します。 | true または false | オプション | None |
log_directory | ログディレクトリを指定します。デフォルトでは、エージェントディレクトリ内に logs フォルダが作成されます。 | <agent-directory>/logs | オプション | <agent-directory>/logs |
php_executable_path | PHP バイナリのパスを指定します。 | /usr/bin/php | オプション | global php path set |
php_ini_dir | appdynamics_agent.ini ファイルのディレクトリ。 | /etc/php/ | Ubuntu およびデフォルトの PHP CLI バイナリを特定できない場合に必要です。 | global php ini path set |
php_extension_dir | appdynamics_agent.so ファイルの拡張ディレクトリ。 | /etc/php/extensions/ | Ubuntu およびデフォルトの PHP CLI バイナリを特定できない場合に必要です。 | global php extension path set |
php_version | インストゥルメント化する PHP のバージョン。有効な形式は、1 つまたは 2 つの小数点があるバージョン番号です。たとえば、7.4 や 7.4.29 です。 | 7.4.29 | デフォルトの PHP CLI バイナリを特定できない場合、または PHP CLI バイナリがない場合に必要です。 | global php verdsion set |
zts_support | PHP ZTS エージェントをインストールするには、true に設定します。 | true または false | オプション | false |
- php -i|grep appdynamics_agent.ini コマンドを使用して、appdynamics_agent.ini パスを取得します。エージェントがデフォルトの場所にインストールされていない場合、または
linux_custom_agent_install_pathを使用している場合は、custom_agent_ini_fileを絶対ファイルパスで設定します。 - グローバルに設定されていない PHP バージョンでエージェントをインストールする場合は、以下の変数を定義する必要があります。これらは以下に示すすべての agent_action の必須変数です。
php_executable_pathphp_ini_dirphp_extension_dirphp_version
カスタムプロキシ設定の変数
| 変数 | 説明 | 使用可能な値 | 必須 | デフォルト |
|---|---|---|---|---|
proxy_host | プロキシサーバーを通じてコントローラにデータをルーティングするためのプロキシホスト。 | master.ecommerce-proxy.com | オプション | None |
proxy_port | プロキシサーバーを通じてコントローラにデータをルーティングするためのプロキシポート。 | 8090 | オプション | None |
proxy_user | プロキシサーバーホストにログインするために必要なプロキシユーザー。 | ecommere-user | オプション | None |
proxy_password_file | プロキシサーバーホストにログインするためのプロキシパスワードファイル。 | /etc/ecommerce/passwd | オプション | None |
proxy_ctrl_dir | プロキシ制御ディレクトリ。指定しない場合、インストーラは一時的なディレクトリを作成します。 | /ecommerce/proxy_dir/ | オプション | None |
Python エージェントの Ansible 設定
次の項では、Python エージェントのプレイブックの使用例を示します。
Python エージェントのインストール
:以下の機能を備えた Python エージェントのインストールに使用される Ansible® ロール:®
- Linux(Debian、Alpine、および RedHat)への Python エージェントのインストール
- 既存のインストールが検出された場合のバックアップの作成
---
- 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
:Python エージェントでサンプルアプリケーションを起動するための Ansible ロール:
---
- 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.