On this page:

Related pages:

AppDynamics automatically calculates the baseline performance for your applications, that is, the prevailing performance characteristics of those applications. Once it establishes a baseline, it can detect anomalous conditions for your application.

Baselines appear in these contexts in AppDynamics:

  • Flow map colorization 
  • Transaction score dashboards
  • Metric graphs
  • Health rules 

How Baselines Work

AppDynamics calculates baselines on the fly by using the underlying hourly data. A baseline can be calculated for every metric in the controller.

Baselines have two main variables:

  • The time over which accumulated data should be considered in calculating the baseline.
  • The hourly segment for which the baseline should be calculated. It can be: 
    • Unsegmented, in which case all performance data over the time period is considered in calculating the baseline; or 
    • Segmented, in which the hour of the day, day of the week, and so on, is considered. 

Identify Trends

Performance expectations can differ between hours of the day, days of the week, or even months of the year. For example:

  • A retail application may experience heavier traffic on the weekend than the rest of the week.
  • A payroll application may experience higher load at the beginning and end of the month compared to the rest of the month.
  • A Customer Relationship Management (CRM) application may experience heavy load during business hours Monday through Friday, but relatively light traffic over the weekend.

To account for this variation, you can use a rolling time period as the baseline context. A rolling time period, or dynamic baseline, establishes the baseline against data from the current hour taken at a daily, weekly or monthly interval over the course of the time period.

For example, say you have a baseline that uses the weekly trend and with the time period configured for 90 days, one of the baselines in the default Controller configuration. 

At a given day and time, say Monday 10:30 AM, the baseline in effect is one that considers only the data accumulated on the same hour and day of the week over the last 90 days. This is illustrated by the following diagram. 

A monthly trend calculates the baseline from data accumulated at the same hour but only on the same day of the month. So, for example, on January 5th at 10:30 AM, the baseline is established based on data accumulated at the same hour on the 5th of each month for the prior year, 365 days: 

Baselines are not available immediately upon startup. It takes time and application load for the AppDynamics platform to collect data and create its initial baselines. The time depends on the type of baseline being used, whether daily, weekly, monthly, or none. None requires several hours before a baseline is available, daily takes several days, weekly takes several weeks, and so on.

Statistics are not compared against baselines in the following scenarios:

  • There are fewer than 20 calls per minute. You can configure the calls per minute threshold by setting the minimum.cpm.baseline.comparison property.
  • The time range is greater than 2 hours.

How the Standard Deviations are Calculated

A baseline deviation is the standard deviation from a baseline at a point in time, represented as an integer value. You can set health rule conditions based on baseline deviations. For example, you can configure a warning condition as 2 standard deviations from the baseline and a critical condition as four standard deviations from the baseline.

The Controller uses the following standard formula to calculate the standard deviation:

standard deviation = sqrt [(B - A^2/N)/N]

A = sum of the data values (X*W) (where X is the metric value and W is the node weight)
B = sum of the squared data values (X^2*W)
N = number of data values

The standard deviations calculations differ based on the type of metric used:

  • If the time rollup type = Sum or Average 
  • If the cluster rollup type = Individual or Collective
    The cluster roll up type is applicable only at the tier or app level (node level metrics will have the same calculations).

Based on the metric type, the following table describes how the standard deviation is calculated: 

If Time Rollup Type is ...If Cluster Rollup Type is ...How the Standard Deviation is Calculated ...
Sum (for example, number of calls)Individual (for example, CPU % busy)

Each hour bucket is one data point. The standard deviation is based on the differences between each hour bucket. To calculate the standard deviation, the sum value is divided by the # of nodes to obtain the average value of the cluster.

SumCollective (for example, number of calls)This is same as the Sum,Individual calculation above except the sum is not divided by the # of nodes because the value is the final sum value.
Average (for example, ART)Individual

All of the average values are calculated (by dividing sum by count) for each minute of data. Then, the standard deviation is computed based on those differences.
Because the minute data is purged, the X*W (where X is the metric value and W is the node weight) and X^2*W data is stored during rollups which is used to calculate the hour tables. The average across the cluster is still calculated by (sum divided by count), so you do not need to know the # of nodes.

AverageCollectiveThis is same as the Average,Individual calculation above except with cluster rollup, the sum of the average values is calculated across the cluster as one value. There is one average value per minute on the entire cluster. However since rollups are currently not calculated as such, the intermediate values stored for (X*W and X^2*W) are only accurate if the nodes are the same performance. Additionally, to adjust for evaluating individual nodes instead of the whole cluster, the variance is then multiplied by #nodes-squared.

The X^2*W value (which is value B) described in the above table is stored during rollup, but is not directly visible. Therefore, customers cannot re-calculate it themselves.

The following shows a standard deviation example using the metric types of:

  • Time rollup type = Average
  • Cluster rollup type = Collective
Metric - Calls Per Minute (Average, Collective)
(Hourly Metric Table)
Time  | Sum | Count | Weight-Value | Weight-Value-Squared
09:00 | 12 | 2 | 24 | 48
10:00 | 14 | 2 | 28 | 56
11:00 | 17 | 2 | 34 | 66

For these metric values, the baseline of type = All Data, lasts three hours (at 12:00) used the above values for calculations.

In case of daily, weekly, or monthly seasonality, the data points considered are values for the same hour for all days, same day of the week, or same day of the year, respectively.

The baseline calculations in this case would be:

Value = ((24+28+34)/3)/2 = 14.33

Standard deviation = sqrt(((48+56+66) - (24+28+34)^2/180)/180) = 0.846 (Number of data points here would be 60*3 = 180)

View Baselines

A baseline deviation is the standard deviation from a baseline at a point in time, represented as an integer value. You can set health rule conditions based on baseline deviations. For example, you can configure a warning condition as 2 standard deviations from the baseline and a critical condition as four standard deviations from the baseline. You can view built-in baselines and add new ones from the Configuration > Baselines page.

The daily trend is the default baseline. This is the baseline used by health rules if another baseline is not specified during health rule creation.

You can choose another as the default by selecting the baseline in the baseline list and choosing Set as Default. However, note that changing the default baseline changes the actual baseline for all existing health rules that rely on the default—that is, that do not specify another baseline. Be aware of your existing baselines and health rule definitions before you select this option.

Configure the Time Period

When configuring a baseline, you set the trend time period and the trend. The base time period comes in two forms: 

  • Fixed time range: from some specific date and time to a second specific date and time. For example, if you have a release cycle at a specific time you might limit your data collection to that specific time.
  • Rolling time range: in which the most recent X number of days is used. This is the more common choice.