Default configuration of the Mobile SDK enables____and_____ . (Choose the two correct options to
complete the sentence.)
AC
Explanation:
The default configuration of the Mobile SDK enables crash reports and network requests12
.
Crash
reports capture and report any unhandled exceptions or signals that cause the app to terminate
abnormally1
.
Network requests monitor the performance and errors of HTTP and HTTPS requests
made by the app2
.
These features are enabled by default and do not require any additional code or
configuration to work12
. Reference:
Crash Reports
,
Network Requests
What are two valid reasons for using the REST API to retrieve health rule violations? (Choose two.)
BC
Explanation:
According to the Cisco AppDynamics Professional Implementer (CAPI) documents, the REST API for
health rule violations allows you to retrieve information about the health rule violations that
occurred in a specified time range for a given application1
. You can use the REST API for health rule
violations for the following valid reasons:
For determining which actions have been executed (B): The REST API response includes the details of
the actions that were triggered by the health rule violation, such as email, SMS, HTTP request, or
custom action1
. You can use this information to verify if the actions were executed successfully, or to
troubleshoot any issues with the action execution.
When searching for historical events ©: The REST API allows you to specify a custom time range for
retrieving the health rule violations, such as BEFORE_TIME, AFTER_TIME, BETWEEN_TIMES, or
BEFORE_NOW1
. You can use this feature to search for historical events that occurred in the past, or
to analyze the trends and patterns of the health rule violations over time.
The incorrect options are:
For updating an AppDynamics dashboard (A): This is not a valid reason for using the REST API for
health rule violations, because the AppDynamics dashboards already display the health rule
violations that occurred in the selected time frame, along with the severity, status, affected entities,
and actions2
. You do not need to use the REST API to update the dashboard, as the dashboard is
automatically refreshed with the latest data from the Controller.
For sending emails (D): This is not a valid reason for using the REST API for health rule violations,
because the REST API does not send emails directly. The REST API only returns the information about
the health rule violations, and the actions that were triggered by them.
If you want to send emails
based on the health rule violations, you need to configure an email action in the health rule
configuration, or use a custom action that invokes an external email service3
.
When pushing events to the Event Management System is NOT possible (E): This is not a valid reason
for using the REST API for health rule violations, because the REST API does not push events to the
Event Management System. The REST API only returns the information about the health rule
violations, and the actions that were triggered by them.
If you want to push events to the Event
Management System, you need to configure an HTTP request action in the health rule configuration,
or use a custom action that invokes an external API3
.
Reference:
: Health Rule Violations API - AppDynamics
: Health Rule Violations - AppDynamics
: Actions - AppDynamics
Which AppDynamics Controller port(s) does the EUM Server require access to in a configuration
where the EUM Server and Controller are on separate hosts (split-host configuration)?
D
Explanation:
In a split-host configuration, where the EUM Server and Controller are on separate hosts, the EUM
Server requires access to the Controller primary HTTP(s) port. This is because the EUM Server needs
to communicate with the Controller API server to send data and receive configuration
information.
The default primary HTTP port for the Controller is 8090 and the default primary HTTPS
port is 81811
.
The dedicated EUM HTTP(s) ports are used by the EUM agents to send data to the
EUM Server, not by the EUM Server to access the Controller2
.
The GlassFish administration port is
used to access the Controller Admin Console, not by the EUM Server3
.
The Controller database port
is used by the Controller to connect to the MySQL database, not by the EUM
Server4
. Reference:
Controller Port Settings
,
Configure the Port for the EUM Agent
,
Access the
Administration Console
,
Controller System Requirements
Which two preparatory tasks are required prior to installing an AppDynamics Controller on Linux?
(Choose two.)
DE
Explanation:
Before installing an AppDynamics Controller on Linux, you need to perform some preparatory tasks
to ensure the system meets the requirements and the installation runs smoothly. Two of these tasks
are:
Install libaio on the host machine if it does not already have it installed. This library facilitates
asynchronous I/O operations on the system, which are required by the Controller. You can use the
package manager of your Linux distribution to install libaio, such as yum or apt-get.
For example, on
CentOS, you can run yum install libaio1
.
Verify that you have enough temporary (tmp) space available on the system, at least 1 GB. The
Controller installation uses the tmp space to extract and install the software components.
You can
check the tmp space by running df -h /tmp2
.
If the tmp space is insufficient, you can either free up
some space by deleting unnecessary files, or specify a different temporary directory for the
installation by passing the -Djava.io.tmpdir parameter to the installer3
.
Other preparatory tasks include verifying the user account permissions, configuring the virus
scanners, installing the netstat network utility, and setting the file descriptor
limit2
. Reference:
Prepare Linux for the Controller
,
Install the Controller on Linux
, and [Controller
System Requirements] in the AppDynamics documentation.
The AppDynamics Controller is instrumented by an internal, out-of-the-box, AppDynamics Java
agent. Which account and user name are used to connect to the Controller to view the information
provided by the internal AppDynamics agent?
C
Explanation:
The AppDynamics Controller is instrumented by an internal, out-of-the-box, AppDynamics Java agent
that monitors the performance and health of the Controller itself1
.
To access the information
provided by the internal agent, you need to log in to the Controller UI with the following
credentials2
:
Account = system
Username = root
Password = <root_user_password>
The system account is a special account that is used only for internal monitoring and troubleshooting
purposes.
It is not visible in the normal Controller UI and requires a special URL to access it2
.
The
root user is the default administrator user for the system account and has the same password as the
admin user for the customer1 account3
. Reference:
Controller Self-Monitoring
,
Monitoring a
Controller Using the Internal Monitoring Agent
,
Controller Accounts
What is the correct method to perform a NET Agent upgrade?
A
Explanation:
According to the Cisco AppDynamics Professional Implementer (CAPI) documents, the correct
method to perform a NET Agent upgrade is to perform the agent upgrade on the application server
host by running the MSI Installer Package12
. This method will install updated agent files and
maintain legacy configurations. You do not need to uninstall the old agent first when you upgrade
from the NET Agent >= 3.9, except for patch releases. You need to stop IIS, instrumented Windows
services, and instrumented standalone applications before running the MSI Installer Package. You
also need to launch an elevated command prompt with full administrator privileges and specify your
account access key for single-tenant Controller accounts. After the installation, you need to restart
Windows services and standalone applications.
The incorrect options are:
Perform the agent upgrade on a remote server host by using the AppDynamics Controller REST API.
(B) This is not a valid method for upgrading the NET Agent, because the AppDynamics Controller
REST API does not provide any endpoint for agent installation or upgrade.
The REST API is mainly
used for retrieving or updating configuration data, metrics, events, snapshots, and other information
from the Controller3
.
Perform the agent upgrade on the application server host by running the Agent Configuration Utility.
© This is not a valid method for upgrading the NET Agent, because the Agent Configuration Utility is
a tool for modifying the agent configuration after installation, not for installing or upgrading the
agent.
The Agent Configuration Utility allows you to change the Controller connection settings, the
agent logging level, the proxy settings, and other advanced options4
.
Perform the agent upgrade via the AppDynamics Controller UI. (D) This is not a valid method for
upgrading the NET Agent, because the AppDynamics Controller UI does not provide any feature for
agent installation or upgrade.
The Controller UI is mainly used for monitoring, analyzing, and
troubleshooting the performance of the applications, business transactions, tiers, nodes, and other
entities that are instrumented by the agents5
.
Reference:
: Upgrade the .NET Agent for Windows - AppDynamics
: Release Upgrade Checklist for .NET Agents - AppDynamics
: REST API - AppDynamics
: Configure the .NET Agent - AppDynamics
: AppDynamics Application Performance Monitoring Platform - AppDynamics
Which directory should an administrator back up if the goal is to back up the EUM Server?
A
Explanation:
The <eum_server_home> directory contains the EUM Server installation files, configuration files, and
data files. It is recommended to back up this directory as a precaution before upgrading or migrating
the EUM Server. The default location of this directory is <installDir>/AppDynamics/EUM, where
<installDir> is the directory where you installed the Controller.
You can also use the backup-eum.sh
script to back up the EUM Server data12
. Reference:
Upgrade the Production EUM Server
,
Configure
the EUM Server
Which framework would require the implementation of custom correlation?
A
Explanation:
Custom correlation is needed when the default detection mechanisms of AppDynamics are not
capable of auto-correlating transactions across tiers or across parent-child threads in complex
multithreaded applications. Custom correlation enables the user to configure AppDynamics to
propagate a unique correlation key by using the extension points of the distributed protocol or by
decorating the payload. Among the four options, a custom TCP concurrent server is the most likely to
require the implementation of custom correlation, as it is an unsupported framework and protocol
that may not have easily-defined method calls or payload objects to configure as exit points or entry
points. The other options, such as SOAP, JMS, and WCF, are supported by AppDynamics and can be
automatically
correlated
by
the
agents
without
the
need
for
custom
configuration. Reference:
Custom Correlation for Java Applications
and
Configure Custom Correlation
for .NET Applications
in the AppDynamics community.
Which two statements are true regarding the AppDynamics REST API for retrieving metrics? (Choose
two.)
AE
Explanation:
The AppDynamics REST API for retrieving metrics allows you to get values generated for metrics by
specifying the path of the metric and the time frame for the data1
.
The following statements are true
regarding this API12
:
Metrics can be retrieved for a fixed time range. You can use the time-range-type parameter to
specify a fixed time range such as BEFORE_NOW, AFTER_TIME, or BETWEEN_TIMES. You can also use
the duration-in-mins parameter to specify the length of the time range in minutes.
Wildcards can be used in the REST API metric path. You can use the asterisk () character as a wildcard
to match any metric name or part of a metric name. For example, you can use the metric path
Business Transaction Performance|Business Transactions||*|Average Response Time (ms) to
retrieve the average response time for all business transactions in all tiers. Reference:
Retrieve
Metric Data
,
Retrieve Metric Hierarchy
Which two methods are available to define JVM options for an AppDynamics Controller so that the
JWM options are retained across upgrades of the Controller? (Choose two.)
AB
Explanation:
According to the Cisco AppDynamics Professional Implementer (CAPI) documents, the two methods
that are available to define JVM options for an AppDynamics Controller so that the JVM options are
retained across upgrades of the Controller are:
Use the modifyJvmOptions utility provided by AppDynamics. (A) This is a valid method because the
modifyJvmOptions utility is a script that allows you to add, remove, or list the JVM options for the
Controller without manually editing any files. The utility also validates the syntax and format of the
JVM options and creates a backup of the original configuration. The utility is located in the
<controller_home>/bin directory and can be run on Linux or Windows platforms.
The utility updates
the <controller_home>/appserver/glassfish/domains/domain1/config/domain.xml file with the
specified JVM options, which are preserved during the Controller upgrade12
.
Define JVM options on the Controller Settings page of the Enterprise Console. (B) This is a valid
method because the Controller Settings page of the Enterprise Console is a graphical user interface
that allows you to configure various settings for the Controller, including the JVM options. The
Enterprise Console is a web-based application that provides a centralized way to manage the
AppDynamics platform components, such as the Controller, the Events Service, and the EUM
Server.
The Enterprise Console also handles the Controller upgrade process and preserves the JVM
options that are defined on the Controller Settings page34
.
The incorrect options are:
Pass JVM options to the Controller via java -javaagent:“options jar”. © This is not a valid method
because the java -javaagent option is used to specify the path to the AppDynamics agent jar file, not
the JVM options for the Controller. The agent jar file is used to instrument the Java applications that
are monitored by the AppDynamics platform, not the Controller itself. The agent jar file also contains
the agent configuration properties, such as the Controller host, port, account name, access key, and
application name.
Passing JVM options to the Controller via this option will not have any effect on
the Controller performance or behavior5
.
Use the controller.sh script provided by AppDynamics. (D) This is not a valid method because the
controller.sh script is used to start, stop, or restart the Controller, not to define the JVM options for
the Controller. The controller.sh script is located in the <controller_home>/bin directory and can be
run on Linux platforms. The controller.sh script does not accept any arguments or parameters for the
JVM options, and does not update any configuration files with the JVM options.
Using this script to
define the JVM options for the Controller will not have any effect on the Controller performance or
behavior6
.
Define JVM options manually in the domain. xmi file. (E) This is not a valid method because the
domain. xmi file is not a configuration file for the JVM options for the Controller, but a configuration
file for the WebSphere Application Server. The WebSphere Application Server is a Java EE application
server that can be used to host the Java applications that are monitored by the AppDynamics
platform, not the Controller itself. The domain. xmi file contains the settings for the WebSphere
Application Server, such as the server name, port, security, data sources, and class loaders.
Defining
JVM options manually in this file will not have any effect on the Controller performance or behavior,
and may cause errors or conflicts with the WebSphere Application Server configuration7
.
Reference:
: Modify JVM Options for the Controller - AppDynamics
: Release Upgrade Checklist for Controllers - AppDynamics
: Configure the Controller Using the Enterprise Console - AppDynamics
: Upgrade the Controller Using the Enterprise Console - AppDynamics
: Install the Java Agent - AppDynamics
: Start and Stop the Controller - AppDynamics
: Configuring the WebSphere Application Server - IBM