This section explains how to use the AppDynamics monitor. The AppDynamics monitor provides information on the availability and performance of software applications and the impact on user experience measured by the AppDynamics Platform, an application performance monitoring tool.
Set up the AppDynamics monitor
For the supported version of the integration, see the Integrations section of the System Requirements.
For task details, see Create and configure monitor profiles.
Specify which resources you want to measure
Choose the relevant measurements that you want to monitor from the list of measurements that have been defined on the AppDynamics application.
You can get all types of metrics including application, user experience, database, and server metrics.
Note: Log details are available in Debug mode only. "Connection with AppDynamics" in logs is an 'Info' entry rather than 'Debug'.
For more information on AppDynamics , refer to the AppDynamics documentation.
Configure additional AppDynamics monitor settings
You can make additional changes to the monitor’s behavior (on a per-machine basis) by editing the following settings in the AppDynamicsConfiguration.xml file (located in the <PC Host install path>\dat\monitors directory):
HttpTimeout. Defines the timeout period, in milliseconds, for the HttpWebRequests. The default value is 15000.
MetricPollInterval. Defines the polling rate, in seconds, of the AppDynamics Controller. The default value is 60.
ValidateServerCertificate. Defines whether the SSL certificates on the host machine should be validated when using HTTPS. The default value is 0 for ease of use and broader compatibility. If you want stricter security control, change this value to 1. This requires you to install the AppDynamics certificates on the host machine.
Notes and limitations
AppDynamics measurements appear in the Performance Center Run screen after a short delay. This is due to the way AppDynamics reports timestamps back to Controller, which are a few minutes behind the current time on the AppDynamics Controller machine. When the test is started, the first timestamp and data-point reported are a couple of minutes old. As a result, it takes a few minutes of running before the Controller receives data-points that have timestamps which are valid for the test in progress.