Share via

Defining Reactive Rules

  • Article
Retired Content

This content and the technology described is outdated and is no longer being maintained. For more information, see Transient Fault Handling.

patterns & practices Developer Center

On this page:
Specifying Conditions | Comparison Operator Elements | The all Element | The any Element | The not Element | Specifying Comparison Values | Expression Syntax Rules | Defining Operands

Reactive rules allow you to adjust the number of instances of a target based on aggregate values derived from data points collected from your Microsoft Azure environment or application. A reactive rule consists of a target that identifies the role or scale group to scale, an action that specifies the scaling action to perform, and a Boolean expression that determines whether the rule should perform the action.

If two or more reactive rules suggest conflicting scaling actions for the same target, the Autoscaling Application Block uses the rule with the highest rank. However, constraint rules always override reactive rules, regardless of the rank.

The following snippet shows an example of a simple reactive rule.

<rule name="Example Scaling Rule" rank="100">
  <when>
    <greater operand="CPU_RoleA" than="80"/>
  </when>
  <actions>
    <scale target="WorkerRoleA" by="2"/>
  </actions>
</rule>

This rule is designed to add two new instances of a target named WorkerRoleA when the value of the operand named CPU_RoleA is greater than 80. You can find the definition of the target in the service information configuration data. Reactive rules, just like constraint rules, have ranks to determine precedence if two or more reactive rules conflict. However, a reactive rule can never override a constraint rule.

Note

If there is no constraint rule specified for the target of a reactive rule, then the block logs an error and does not perform any scaling actions on the target.

The following snippet shows how the operand is defined.

<performanceCounter alias="CPU_RoleA" source="WorkerRoleA" 
   performanceCounterName="\Processor(_Total)\% Processor Time" 
   timespan="00:45:00" aggregate="Average"/>

This example shows how you can use performance counter data in your reactive rules. The alias attribute links the definition to the operand in the rule. The source indicates where to collect the data from, in this example a worker role. The performanceCounterName attribute identifies the performance counter to use. The aggregate and timespan attributes describe how to perform the calculation. This example will average the percent processor time for worker role A over the last 45 minutes.

Note

The source of the performance counter data does not have to be the same as the target for the rule.

The https://schemas.microsoft.com/practices/2011/entlib/autoscaling/rules namespace defines the rule and timetable elements. See the topic "Rules Schema Description" for more information.

Note

If you have installed the Autoscaling Application Block in your Visual Studio project by using NuGet, you can find the AutoscalingRules.xsd schema file in the root folder of the project. You can use this schema file with many XML editors to provide IntelliSense and automatic validation.

The Autoscaling Application Block loads reactive rules and operand definitions from an XML file stored in the location specified by the block's configuration. See the topic "Entering Configuration Information" for more details.

Specifying Conditions

You can specify more complex conditions in the when element that determine whether to perform the action. The following sections describe how you can define these conditions.

Comparison Operator Elements

The following snippet shows an example of a rule that uses the greater operator element inside the when element. The rule performs the scaling action if the expression inside the when element evaluates to true. In this example, the when element evaluates to true if the value supplied by the operand named CPU_RoleA is greater than 80.

<rule name="Example Scaling Rule" rank="100">
  <when>
    <greater operand="CPU_RoleA" than="80"/>
  </when>
  <actions>
    ...
  </actions>
</rule>

The following table lists all of the comparison operator elements you can use inside the when element.

Operator element

Description

greater

Returns true if the value supplied by the operand is greater than the value of the than attribute.

greaterOrEqual

Returns true if the value supplied by the operand is greater than or equal to the value of the than attribute.

less

Returns true if the value supplied by the operand is less than the value of the than attribute.

lessOrEqual

Returns true if the value supplied by the operand is less than or equal to the value of the than attribute.

equals

Returns true if the value supplied by the operand is equal to the value of the to attribute.

all

Returns true if all of the nested elements return true.

any

Returns true if any of the nested elements return true.

not

Returns true if the nested element returns false.

The all Element

The following snippet shows an example of a rule that uses the all element.

<rule name="Example Scaling Rule" rank="100">
  <when>
    <all>
      <greater operand="CPU_RoleA" than="80"/>
      <greater operand="CPU_RoleB" than="80"/>
    </all>
  </when>
  <actions>
    ...
  </actions>
</rule>

The all element has one or more child elements. The child elements could be one of the following: all, any, not, greater, greaterOrEqual, less, lessOrEqual, equals. The rule performs the action when all of the child elements evaluate to true.

In the example above, the rule performs the action when the value of the CPU_RoleA operand is greater than 80 and the value of the CPU_RoleB operand is greater than 80.

The any Element

The following snippet shows an example of a rule that uses the any element.

<rule name="Example Scaling Rule" rank="100">
  <when>
    <any>
      <greater operand="CPU_RoleA" than="80"/>
      <greater operand="CPU_RoleB" than="80"/>
    </any>
  </when>
  <actions>
    ...
  </actions>
</rule>

The any element has one or more child elements. The child elements could be one of the following: all, any, not, greater, greaterOrEqual, less, lessOrEqual, equals. The rule performs the action when any of the child elements evaluate to true.

In the example above, the rule performs the action either when the value of the CPU_RoleA operand is greater than 80 or the value of the CPU_RoleB operand is greater than 80.

The not Element

The following snippet shows an example of a rule that uses the not element.

<rule name="Example Scaling Rule" rank="100">
  <when>
    <not>
      <any>
        <greater operand="CPU_RoleA" than="30"/>
        <greater operand="CPU_RoleB" than="30"/>
      </any>
    </not>
  </when>
  <actions>
    ...
  </actions>
</rule>

The not element has one child element. The child elements could be one of the following: all, any, not, greater, greaterOrEqual, less, lessOrEqual, equals. The rule performs the action if the child element evaluates to false.

In the example above, the rule performs the action if the value of the CPU_RoleA operand is less than 30 and the value of the CPU_RoleB operand is less than 30.

Note

This example also shows how you can nest conditions in an expression.

Specifying Comparison Values

The comparison operator elements (greater, greaterOrEqual, less, lessOrEqual, equals) compare the value supplied by the operand with the value specified by the than or to attribute. The block allows you to use simple expressions when you define comparisons. The following snippet shows examples of the simple expressions that you can use.

<greaterOrEqual operand="LowPriorityQueue" than="0.5 * HighPriorityQueue"/>
<greaterOrEqual operand="5 * LowPriorityQueue" than="HighPriorityQueue"/>
<greaterOrEqual operand="LowPriorityQueue" than="HighPriorityQueue / 2"/>

Expression Syntax Rules

The following list summarizes the syntax rules of the operand, than, and to attributes.

  • The supported operators are multiply (*) and divide (/).
  • Parentheses are not supported.
  • Expressions are evaluated left to right.
  • Expressions can include integers and floating-point numbers.
  • Expressions can include zero or more operand aliases.
  • Operand aliases are case-sensitive and must match their definition in the operands section of the XML rules file.

Defining Operands

The Autoscaling Application Block loads reactive rules and operand definitions from an XML file stored in the location specified by the block's configuration. See the topic "Entering Configuration Information" for more details. This topic describes how to define the operands that the reactive rules use.

The following snippet shows an example of defining three operands.

<operands>
  <performanceCounter alias="CPU_45_RoleA" source="WorkerRoleA" 
    performanceCounterName="\Processor(_Total)\% Processor Time" 
    timespan="00:45:00" aggregate="Average"/>
  <performanceCounter alias="CPU_45_RoleBC" source="ScaleGroupB" 
    performanceCounterName="\Processor(_Total)\% Processor Time" 
    timespan="00:45:00" aggregate="Max"/>
  <queueLength alias="Length_10_QueueC" queue="QueueC"
    timespan="00:10:00" aggregate="Growth"/>
</operands>

The Autoscaling Application Block provides two standard types of operand: performance counters and queue length.

The alias attribute defines the name of the attribute that is used in the rule definition. You should not include spaces in the alias name.

In the example above, the first performanceCounter element defines a value calculated by taking the average value of the "\Processor(_Total)\% Processor Time" performance counter over the last 45 minutes from the running instances of a worker role.

The second performanceCounter element defines a value calculated by taking the maximum value of the "\Processor(_Total)\% Processor Time" performance counter over the last 45 minutes from all the role instances in a scale group.

The queueLength element calculates the rate of growth of the length of an Azure queue over the last 10 minutes. The Growth aggregate uses simple linear regression to measure the growth of a counter value over time.

The following table lists the aggregate functions you can use in an operand definition.

Name

Description

Notes

Max

The maximum value of the data points during the time period.

For a value to be returned, there must be at least two data points in the time period, one in the first 2/5 of the time period and one during the last 2/5 of the time period.

Min

The minimum value of the data points during the time period.

For a value to be returned, there must be at least two data points in the time period, one in the first 2/5 of the time period and one during the last 2/5 of the time period.

Growth

The rate of growth of the data points during the time period. This is calculated using simple linear regression. A positive number implies growth.

For a value to be returned, there must be at least two data points in the time period, one in the first 2/5 of the time period and one during the last 2/5 of the time period.

Average

The mean value of the data points during the time period.

For a value to be returned, there must be at least two data points in the time period, one in the first 2/5 of the time period and one during the last 2/5 of the time period.

Last

The last recorded data point value in the time period.

For a value to be returned, there must be at least one data point in the time period.

Note

For a better indication of the load on your application, you should use longer timespans, such as 30 or 60 minutes. Longer timespans will also help to smooth out any variations in the data when you are using the average or growth aggregate types.
The block samples data points every two minutes, so to ensure that you have at least two data points for the aggregate calculation you should set a timespan of at least 5 minutes.

To enable custom performance counters, see the topic "Collecting Performance Counter Data."

To create custom operands, see the topic "Creating a Custom Operand."

Next Topic | Previous Topic | Home

Last built: June 7, 2012