Adaptive Baselining

Why should I use Adaptive Baselining?

There are several good reasons for using Adaptive Baselining. To comprehend the background better, the following sections describe some of the facts regards to the static and Adaptive Baselining:

Static Thresholds Shortcomings

Configuring thresholds for all business applications within your organization is a huge task. Every application must be analyzed individually to determine the performance level.

In this task lies also the comparison between location related differences in performance as the network latency caused by the physical distance to the server can have a severe impact on the performance experienced by the end-user.

Important

Example: If you set a threshold at a low value, you may get events and alerts in a situation where e.g. response times are slow due to heavy load on the system. A good example is the response times on Domain Controllers, which may be slower than normal in the hour between 08.00 and 09.00 where people get to work and log into their computers. After 09.00, there is not the same load on Domain Controllers and thus the response times are faster. If the threshold is set low, a lot of events and subsequently alerts are triggered in PG, causing IT operation to get false negative reports. This will over time lead to IT operation ignoring alerts as the alert situation becomes ‘normal’ - this then leads to ignoring alerts even when they are actually caused by a problem. In the opposite situation the threshold can be set high enough to not trigger events and alerts in the morning but as the value is static, problems outside this busy hour must be really bad before IT operation is notified.

Adaptive Baselining Benefits

How do you tackle the situation in above mentioned example? The answer is that you need a baseline that compares the actual value to the expected value. A baseline that is automatically determined by PerformanceGuard without user interaction.

For most systems, the performance of the system is closely related to the load from the end users – heavy load causes decreased performance resulting in longer response times. Fortunately, the load as well as the performance of a system can most often be predicted by analyzing data collected over time. This allows you to let PerformanceGuard determines if the current performance level is within the expected range and inform you if it is not.

How do we calculate Adaptive Baselining?

Adaptive Baselining Setup

PerformanceGuard analyzes data that it collects from the agents and compares the response times to the calculated value for that specific hour of the day and that specific day of the week. The values are continuously being updated to ensure that the calculation is based on the previous 4 weeks i.e. the current week will have similar pattern as the average of the previous 4 weeks, next week will have similar pattern of the current week and the previous 3 weeks and so on.

The calculated value is the average for the same hour on the same weekday in the previous 4 weeks. A margin is defined as a percentage above the calculated value for each application and if the response times for a computer is higher than this margin, an event will be triggered.

Caution

The Adaptive Baselining is not in effect (active) until the day after the first setup i.e. if you have enabled Adaptive Baselining on a Thursday, you will receive events and see Adaptive Baselining on your graph from Friday. The Lower Threshold in this case is not a Static Threshold but an extra security measure for Adaptive Baselining and therefore, you will not see this in effect until the same Friday.

Important

Example: 
Click thumbnail to view image in full size.

In this example, you can clearly see that on Wednesday 26th of September, response time suddenly rose around 10:00 until around 10:10. The effect is that adaptive baseline adjusts to the situation and calculates a threshold from 10:00 to 11:00 for the next Wednesday 3rd of October. The Event rule has defined Adaptive Baselining Margin of 20%, which is added to the above-calculated threshold, giving a threshold value of 125 ms - without a margin it would have been around 105 ms. Even though there was no traffic before 10:00 or after 10:10, the threshold value is 50 ms due to the event rule’s defined Lower Threshold.

Important

The Adaptive Baselining works together with the value defined in Lower Threshold in the way that both values must be exceeded for an event to be triggered. This means that if your normal response times are in the range 5-10 ms and you don’t consider response times to be bad until they reach 25 ms, you can configure the lower threshold to 25 ms and only when exceeding this value as well as the Adaptive Baselining will events be triggered.

Resetting calculations

In the event that a change to your environment has caused a major change in the response time level, you have the option to reset the calculation of the Adaptive Baselining values. You simply add a date to the field Adaptive Baselining Reset Date.

Caution

Please be aware that if you save the event rule with a reset date, this cannot be undone. The only option for changing this date after saving the event rule is to enter a date that comes after the previous date.

To view these Adaptive Baselining on Application Chart Widget you have to simply do the following:

For Client/Server Application

Caution

You can only do this if you’re a PerformanceGuard administrator.

1. [[Define an application]].
2. Manage Thresholds and Events.

Tip

You must define Event Rules such as IP Service - Response Time or Availability in Manage Thresholds and Events before you can view these Adaptive Baselining on your Widget.

Tip

You must use the same Server Group / Port Group used in setting up an application when creating new Event rules.

• Set the Lower Threshold (only for IP Service - Response time) to 1.0 ms.
• Make sure that you have enabled Adaptive Baselining box.
• Set the Adaptive Baselining Margin to 10.0%.

View the Adaptive Baselining on your Widget.

For Web Application

Caution

You can only do this if you’re a PerformanceGuard administrator.

1. [[Define an application]].
2. Add the filter (same Web application that you have just created) to Agent Configuration Group Settings.

Caution

You have to ensure that PerformanceGuard Agents has confirmed the configuration and have collected the data. Only then you can select that specific Transaction filter when creating an event rule.

3. Manage Thresholds and Events.

Tip

You must define Event Rules such as Transaction - Response Time or Availability in Manage Thresholds and Events before you can view these Adaptive Baselining on your Widget.

Tip

You must use the same Transaction Filter used in setting up an application when creating new Event rules.

• Set the Lower Threshold (only for Transaction - Response time) to 1.0 ms.
• Make sure that you have enabled Adaptive Baselining box.
• Set the Adaptive Baselining Margin to 10.0%.

View the Adaptive Baselining on your Widget.

Important

Can I still use static thresholds?

For each application you can select to use either Static or Adaptive Baselining. If you have disabled Adaptive Baselining then the lower threshold works as Static Threshold. If you are setting value to Lower Threshold and enabling Adaptive Baselining in an event rule then the lower threshold works as an extra security measure for Adaptive Baselining and both threshold must be exceeded before events are triggered.